When an AI agent tries to buy something or sign an agreement, the merchant on the other side has three separate questions: who is this agent, who is responsible for it, and is it allowed to do this. Identity answers the first two and not the third. This post pulls the three apart, shows which layer answers each one, and is plain about what an identity product can't promise.
Agentic commerce needs an identity layer that answers two questions and a separate authorization layer that answers a third: identity says which agent this is and which human is accountable for it, while permission to spend or sign comes from a mandate and a payment rail. AgentID, our sign-in for AI agents, provides the identity half and deliberately stops there.
Most talk about agents and payments collapses these into one word, trust, and then argues about which product provides it. That hides the design problem. A merchant can know exactly which agent is at the checkout and still have no idea whether its owner meant it to spend a thousand dollars. A contract platform can know the human behind an agent and still need proof that the human authorized this particular signature. Separating the questions is what lets each layer do one job well, and it keeps anyone from claiming more than they deliver.
What does a merchant need to know about an agent?
A merchant needs three answers about an agent, and they come from different places. The first two are about identity and accountability, which every agent has a human argues are inseparable. The third is about permission.
| Question | What answers it | What AgentID provides | What it does not |
|---|---|---|---|
| Who is this agent? | An identity provider the merchant trusts | A signed token with a stable ID for the agent, marked as an agent, with its verified inbox | A trust score or an endorsement |
| Who is accountable for it? | The identity provider, naming the owner | An owner ID for every app that asks, and the owner's name and email for registered apps | A check of the owner's legal identity |
| May it spend this money? | A mandate from the owner and a payment rail | Nothing | Spending limits, payment credentials or approvals |
| May it sign this agreement? | Signing authority granted by the owner or their organization | Nothing | Signature authority of any kind |
The empty cells are the point. An identity layer that also claimed to approve payments would be making a promise it has no way to keep, because the facts it holds are about who, not about what was allowed.
Why is identity not the same as permission to pay?
Identity is not permission to pay because knowing who is asking says nothing about what they may ask for. An AgentID token proves which agent signed in and, for registered apps, which human stands behind it. It says explicitly that it is not a trust score or an endorsement of any kind, and it doesn't assert that the agent is safe or well behaved.
The same line runs through the token's other limits. Signing in grants the app no access to the agent's mailbox, and the app never receives a password or a key it could reuse. Identity is a fact about the agent. Permission is a decision someone made, and it has to be recorded somewhere that decision lives, such as a payment mandate the owner set up.
Contracts follow the same pattern. A signing platform can record which agent put its name to an agreement and which human stands behind it, but whether that agent had the authority to bind anyone is a question about the owner's instructions, not about the agent's identity. That separation is a feature for merchants. It means the identity check can be the same at every checkout, while the spending rules differ by owner, by merchant and by amount, exactly as they do for people today.
Where does the accountable human come in?
The accountable human comes in as a claim the merchant can request, and it is what makes the rest of the chain possible. Every agent with the same owner shares an owner identifier, so a merchant can apply limits, history and fraud rules to the person rather than to each agent they run. A registered merchant app can also receive the owner's name and email, which gives it someone to contact when an order goes wrong.
AgentID never hands a registered app a sign-in with that claim quietly missing. If the agent's key isn't allowed to share its owner, the agent can't finish alone, and the organization owner has to approve the sign-in from their AgentMail account. For a merchant that means an agent either arrives with its owner attached or doesn't arrive. The mechanics are in how an AI agent proves its identity with AgentID.
An email address is a contact, not a verified legal identity. Merchants that need more, for regulated payments or high-value contracts, still run their own checks, and the owner's email is the key that joins those checks to every agent the owner runs.
What is still missing for agent payments?
What is still missing is mostly the third row of the table: a common way for an owner to grant an agent a spending mandate that any merchant can check. That is a job for payment networks and the platforms that hold the money, and we don't claim to do it.
The layers compose cleanly once they are kept apart. An agent signs in with an identity that names it and its owner. The merchant looks up what that owner has authorized, through whatever mandate or payment system both sides trust. The payment then runs on rails built for moving money. Each layer can change without breaking the others, and none of them has to pretend to be the whole of trust.
For the agent, all of this starts with an address it controls, which is where an email address for your AI agent's signups begins. Is OAuth enough to verify an AI agent covers why a permission token alone doesn't answer the first two questions.
AgentMail gives your agents real inboxes. Create inboxes via API. Send and receive Emails with 0 complexity. Free to start.
