The fastest way to let an AI agent buy something for you is to give it your login. It is also the worst way. A password says "this is me." It does not say what the agent may do, for how long, with how much money, or how you take it back. When something goes wrong, the merchant sees you, not the agent, and nobody can prove what you actually agreed to.
Payments has spent about fifty years on a version of this problem: letting one party act with someone else's authority, safely. Every answer it found comes down to four questions.
The four questions
- Scope. What exactly may the agent do? Which merchant, how much, until when?
- Revocation. How does the person take that authority back, quickly and for certain?
- Attribution. After the fact, can the merchant, the network, and the issuer prove who did what, and that the person approved it?
- Rollback. When the agent is wrong, what happens: dispute, refund, and who carries the liability?
A shared password fails all four. Delegated authority is the design that passes them.
I've lived the code version of this
At Visa I led the program that put AI agents into everyday engineering work. The hard part was never the model. It was authority. Three rules made it safe enough for a payments company:
- The ceiling rule. An agent signs in as its person and inherits only that person's permissions on each system. Whatever you can read, your agent can read. Nothing more. An agent that sees more than its person is a security incident.
- No self-approval. Agents write code on a branch and open a pull request. A human merges every one. An agent that approves its own action is a control failure.
- Narrow scope beats broad trust. To let non-engineers in, I negotiated with security to allow the regular corporate ID, scoped to exactly one repository: the knowledge base the model reads from. No path to source code, the build system, or production. Security said yes because the blast radius was small and every edit was tied to a real person.
Swap "merge a pull request" for "pay a merchant" and you have agentic commerce.
How the new protocols split the job
No single protocol covers the whole trip. Reading the public specs, I see layers that stack rather than compete:
- MCP (an open standard from Anthropic) is how an agent reaches tools and data. It answers "what can this agent call," and done well, the agent gets its person's permissions and no more.
- TAP, Visa's Trusted Agent Protocol, helps a merchant tell a trusted agent with real shopping intent from a bot. The agent signs each request using standard HTTP Message Signatures, with a short expiry and a one-time nonce, and the merchant checks the signature against published keys. Linked, signed objects can carry who the agent is shopping for and the payment details.
- AP2, the Agent Payments Protocol from Google and partners, proves the person authorized the purchase. It uses signed mandates: an open mandate carries limits like a budget, and a closed mandate binds to one specific checkout.
- ACP, the Agentic Commerce Protocol from OpenAI and Stripe, runs checkout inside a chat. Payment is delegated through a token scoped to one merchant and a maximum amount, so card details never reach the agent.
- UCP, the Universal Commerce Protocol from Google and partners, standardizes the journey from discovery to checkout to orders, and is designed to carry AP2 for the payment step.
Map them back to the four questions and the shape is clear. Scope lives in mandates and scoped tokens. Attribution lives in signatures. Revocation and rollback are where I would push hardest, because they are where real customers get hurt.
Where this comes from
This is my point of view, not a description of work I delivered. Everything above comes from public specifications, not internal material, and the summaries are mine.
What I would test before an agent pays for anyone
The same thing I test before an agent touches production: evals before exposure. I'm building an eval plan for a shopping agent's checkout now: 50 scenarios, a pass/fail rubric, and red-team cases for prompt injection, over-spend, and the wrong merchant. The first gate is simple. If the agent would ever spend outside its mandate, it does not ship.
Give agents authority you can scope, revoke, attribute, and roll back. Never your password.