The authorization layer for autonomous agents

Sixteen months ago AI agent authorization was a slide. As of this month it is a set of shipped frameworks, each with a name, a launch date and a partner list. If you are building in this category, the first useful thing you can do is read what the five largest players actually wrote, because the gap that survives their announcements is much smaller and much sharper than the one the marketing describes.

What shipped, in order, from the primary sources

• Visa Intelligent Commerce, April 2025. Agent specific pass through tokens, payment instructions set by the consumer, and validation that the authorisation request matches the original authenticated instruction. Visa's own line: only the consumer can instruct the agent on what to do and when to activate a payment credential.
• Mastercard Agent Pay, April 2025, and Agent Pay for Machines, June 2026. Every agent is credentialed, authorization rules and spending limits are programmatically enforced, participants transact across providers, and settlement spans cards, accounts and stablecoins.
• Google's Agent Payments Protocol, September 2025, donated to the FIDO Alliance in April 2026. Mandates are cryptographically signed proof of a user's instructions, shared with the credential provider, the networks and the merchant payment processor, and explicitly payment agnostic.
• OpenAI's Agentic Commerce Protocol, September 2025, built with Stripe. Open sourced, with the merchant accepting or declining the order and processing payment through its existing provider.
• Stripe's Agentic Commerce Suite, December 2025. Shared Payment Tokens, where the credential is bound to a mandate rather than to a card number, plus a single integration for merchants reachable by many agents.

Read that list as an engineer and one thing stands out. Every one of these is an excellent answer to the question inside its own boundary. Visa's control plane matches a transaction against an instruction inside Visa's rails. Mastercard's permissioning is enforced by Mastercard. Stripe makes one integration reach many agents, and the authority still lives in Stripe's token. Google's mandate is the most portable object in the list, and it is a specification that the industry agreed to standardise, which is not the same thing as a merchant, an issuer and a processor accepting it in production with the loss allocated when it goes wrong.

The narrower claim that still holds

I had to cut a sentence from my own writing last month because it had stopped being true. The version I can defend is this: no one currently accepts a signed authority object at production scale, outside a pilot, when the rail changes and the parties do not share a balance sheet, with the question of who pays for a mistake written down in advance. That is the claim I will put in front of anyone. It is smaller than the one I started with, and it is the one that survives a payments lawyer reading it.

It also happens to be the only version that matters commercially. The hard part of agent commerce is not getting one network to recognise an agent. Five companies solved that, and they solved it well. The hard part is a boundary that means the same thing to a merchant, an issuer, a processor and a regulator who are not on the same infrastructure, at the moment a purchase is disputed.

What an authorization layer has to do, in three jobs

• Say who is acting. Not a key, not a session, not a card number. An identity for the agent, owned by a person or a company, with a history attached.
• Say what it is allowed to do. A boundary written before the run, in the form of scoped capabilities that expire, evaluated on every proposed action with an answer of allow, deny or escalate.
• Say what happened. A record that a third party who was not present can read, and that recomputes the decision it describes.

Notice that none of the three is a checkout. This is where most of the category accidentally converges, including people with good intentions. Making an agent able to pay is a different problem from making it authorised to pay, and the first one is much easier, which is why there is so much of it. Google's own buying surface shows the split cleanly. The protocol unifies the cart across merchants, and then the checkout still resolves per shop, per merchant of record, per integration. The cart is portable. The authority is not.

Why this is worth building as its own layer

It is worth being precise about what portability would have to mean, because the word is doing a lot of work in the pitch decks. A portable authority object is not a file. It has to be accepted by four parties who do not share infrastructure: the agent has to present it, the merchant has to be able to read it without an integration, the issuer has to be able to honour it inside a network it controls, and whoever adjudicates a failure has to be able to say, from the object alone, what was permitted. Every one of those four is a separate negotiation. The specifications that exist today solve the first one and the technical half of the second.

The reason is mechanical rather than strategic. The moment authority is tied to the rail that supplied the credential, every new rail is a new integration, a new boundary and a new dispute process. Companies in this category already describe the consequence. Stripe's own launch post says that while the protocol provides shared technical language, real world fragmentation remains, because every agent has its own integration requirements and onboarding flows. That is the merchant side of fragmentation. The authority side is worse, because it is invisible until something goes wrong.

I am not arguing that networks should not do this. They should, and the version where the credential never leaves the network is genuinely safer than the version where it does. I am arguing that a boundary which only exists inside one operator's system is a permission, not an authorization layer. The difference is what happens on the day two of them disagree about the same purchase.

I am building that layer at Noesia, and the argument it serves is the money layer for AI agents. The two pieces that go deeper into the mechanics are why there should be no LLM in the authorization path and what an agent authorization record should contain. If you have read these five frameworks and reached the opposite conclusion, I would like to read your version of it. The short version of the same argument is the agentic economy is a trust problem.