How to stop AI agents from acting without customer approval

The problem: actions nobody approved

An AI agent acting for a customer can search, compare, fill carts, book travel and, increasingly, pay. That is useful until the agent does something the customer did not ask for: a different fare, a larger quantity, a new payee, an upgrade with a longer contract. The cause may be a misread instruction, a stale price, or a web page that quietly told the agent what to do.

When that happens, the customer disputes the charge and the business absorbs the cost and the support burden. Banks face the sharpest version of the problem, because a transfer to the wrong payee is hard to reverse. The underlying question is the same everywhere: did the customer actually approve exactly this action?

Regulators are asking it too. Federal Reserve Governor Christopher Waller named authentication, liability and fraud as the barriers to scaling agentic commerce, asking “Who is on the hook if an agent makes the wrong purchase?” (Federal Reserve, Sep 2026). Akamai reports attackers already hijacking legitimate AI assistants to abuse stored payment credentials (Akamai via GlobeNewswire, Jul 2026).

Why bot detection alone cannot solve it

Most businesses first reach for bot detection. It helps, but it cannot carry the whole load, for three reasons.

• Many agents never run your page code. Agents that call APIs or fetch pages directly never execute a browser script, so a script cannot see or stop them.
• Some agents look exactly like your customer. An agent working inside a customer’s own logged-in browser shares their cookies, device and network. No detector can reliably tell them apart.
• Detection is a probability, not a permission. A confident bot score says nothing about what the customer wanted. Treating it as authorization blocks good customers and still misses careful automation.

Detection is a useful signal for routing and rate limiting. It is the wrong tool for deciding whether a purchase or transfer should happen.

Protect the actions, not only the pages

The durable answer is to make every consequential action prove four separate things, in code the agent cannot bypass:

1. Who the agent is. The agent signs its requests, for example with HTTP Message Signatures (RFC 9421) or the emerging IETF Web Bot Auth approach, and the signature is checked for freshness and replay. That charter explicitly leaves authenticating the end user out of scope, so identity is only the first proof.
2. What the customer delegated. A finite, revocable grant lists the allowed actions, limits and expiry. Identity alone grants nothing.
3. What your rules allow right now. Your current policy and service status decide, not a cached answer from yesterday.
4. That the customer approved exactly this. The customer approves the exact item, price and terms, on a page the agent cannot fill in. If anything material changes, they approve again.

With these checks in place, even an agent you never detected cannot complete a purchase or transfer on its own. It can ask; only the customer can say yes.

Give agents an official route

Blocking every agent pushes legitimate shoppers away and leaves you blind to demand. A better pattern is to give agents one official, governed way in, for example agent.yourstore.com, and enforce it where requests actually arrive:

• Discovery. An entry script, robots.txt and well-known discovery documents tell cooperating agents where the official route is.
• Server and edge enforcement. A gate at your CDN or origin releases protected data only for signed, short-lived grants, and redirects or blocks requests without them.
• Backend enforcement. Holds, orders, transfers and account changes require delegation and exact approval in your own systems.

Keep payment credentials away from agents

An agent should never read, type, store or relay a card number or a one-time passcode. Payment belongs on a hosted page for the human customer. A browser returning to a success page is not proof of payment; only the verified outcome from the payment provider is.

A checklist for merchants and banks

• Separate agent identity, customer delegation, approval, payment and commit into distinct checks.
• Bind approval to the exact terms, and require a fresh approval when material terms change.
• Enforce protected data at your server or CDN edge, not only in browser code.
• Use bot and automation signals to route and rate-limit, never to authorize.
• Keep payment on a human-only page, and trust only verified payment outcomes.
• Make every effect idempotent, so retries never double-charge or double-book.
• Record each step so disputes can be resolved with evidence rather than guesswork.

How TrueSession helps

TrueSession packages these controls into one trust layer: an official agent endpoint, a verified handshake, your access rules, exact customer approval and a human-only payment step, with a console to see and manage it all. The core flows run in our laboratory today, and we are preparing the first pilots. See how it works or read the security model.