The Trust Stack - 03 - Nobody to Answer

A bottle of bourbon, a fifty dollar bill, a driver's license, a label.

Part 01 put those three credentials on a counter and found that a century of payment technology rebuilt the money completely and left the other two exactly where they were. Part 02 took the room away, and watched all three get rebuilt at once, unevenly, according to who was on the hook when each one failed.

Now take the person away.

You are not shopping. You have told something else to shop for you, and it is transacting at three in the morning while you are asleep. Every check that survived the move online assumed a human would be there to perform it, or at minimum to be blamed for it.

Start with what happens when you try.

Ask an agent to buy the bourbon and, as of this writing, it will not. OpenAI's commerce policies list "alcoholic beverages (over 0.5% ABV)" among prohibited products, alongside firearms and extremist merchandise, and give no reason for any of it. Google is more forthcoming. Its support page for buying through AI Mode says the feature arrives "with some restrictions in the types of products it will work with, including those that require ID verification like alcohol or tobacco." The bottle we have followed through this entire series, across a counter, a card reader and a web form, is one of the specific things agentic commerce declines to sell you.

Read that second reason again. A machine cannot buy you a bottle of bourbon because somebody would have to check an ID, and there is no way to do that. It is not squeamishness and it is not an oversight. It is the most honest thing anyone in this industry is currently doing, and by the end of this article it should be obvious why.

The agent era introduces a question none of the previous ones had to ask.

Not "who are you." That one is in decent shape. The passkey on your phone identifies you better than a clerk squinting at a photograph ever did. The new question is on whose behalf, and how far.

Being concrete about the second half: you told your agent to buy bourbon. Did you authorize it to spend four hundred dollars because the cheaper bottles were out of stock? To buy from a seller you have never heard of? To buy two, because the second was discounted? To buy rye instead, on the reasonable grounds that you like rye? You authorized a purchase in general. Whether you authorized this one is a different question.

Delegation itself is not new. OAuth has been letting one service act on your behalf at another since 2012, without either of them sharing your password, and every "sign in with" button you have ever clicked is that machinery. What is new is that all of it assumes somebody can write the list of permissions in advance. That holds for software that executes exactly what it is told and stops when the instructions run out, and it holds for an employee, who can be asked. An agent does neither. It interprets. When it meets a situation nobody enumerated, it does not halt and it does not call you. It decides what you probably meant.

So, once more, the three credentials.

The money. An agent cannot be handed your card and left alone with it. The question is how you grant something permission to spend without granting it everything.

Three protocols have appeared in two years. The Agentic Commerce Protocol, or ACP, from OpenAI and Stripe, handles checkout inside a conversation, and is what ChatGPT uses. The Universal Commerce Protocol, or UCP, from Google, is broader, covering everything from finding the product to what happens after the sale. Gemini uses it.

The one that matters here is the Agent Payments Protocol, or AP2, which Google built and then donated to the FIDO Alliance. It does not care how you shop. It answers a single question: did the human actually agree to this?

It works by splitting the purchase in two. Before the agent goes shopping, you sign an instruction: what to buy, the spending limit, how long the permission lasts, and which agent may use it. Later, when the agent has found something that fits, the merchant signs the specifics: this item, this price, against the instruction you gave. Between them, those two signatures establish that a real person authorized a real purchase, and that the thing bought was inside what they agreed to.

The bank sees neither document. It gets a cryptographic fingerprint, which is enough to confirm an authorized purchase exists without anyone being told what was in it.

Under the Counter What the mandates actually contain AP2 uses two signed documents, and the reason there are two is that two different parties need convincing of two different things. A merchant needs to know whether this agent may buy this. A bank needs to know whether it may pay for it. The Checkout Mandate is the merchant's. It exists in two states, because you sign it before the agent has found anything. Open, signed by you: What you want: coffee beans Your limit: under thirty dollars How long the permission lasts: until Friday Which agent: the key of the specific agent you authorized, so no other software can use the permission Closed, signed by the merchant once the agent has found something that fits: The item: this particular bag The price: twenty four dollars, plus tax and shipping The merchant's signature: proof they sold this, at this price, against the open mandate you signed The Payment Mandate is the bank's and the card network's. They have no business reading the other one: a card network does not need your shopping list in order to move twenty six dollars. The amount: twenty six dollars and ten cents The card: a token standing in for your card number A fingerprint of the checkout: a hash of the mandate above, not its contents That last field is the interesting one, and there is a related field for selective disclosure: the machinery for proving one fact out of a document without exposing the rest of it. Remember that it is sitting here, in a payments spec, because it becomes relevant two sections from now.

If you approve every purchase yourself, an agent is a convenience with a human check at the end of it. If you do not, the instruction you signed is the only thing bounding what gets bought. Unattended is where the value is, and where everything below becomes load-bearing.

There is a second problem underneath all this, and it is not the one AP2 solves.

The store has never seen this buyer. It is not typing, it does not behave like a person, and it looks in every measurable respect like the automated traffic that store pays money to block. To the fraud model from Part 02, a legitimate agent doing exactly what you asked and a scraper hammering the checkout page are the same event.

Somebody therefore has to vouch for the agent, and it cannot be the store. The two card networks have come at this from opposite ends.

Visa's Trusted Agent Protocol leads with who. Agents are issued a verified identity, Visa runs the directory, and a store can check a request against it before deciding whether to deal with this buyer at all.

Mastercard leads with how far, by extending the tokenization from Part 02. Instead of your real card number the agent gets a substitute, minted with the limits already inside it: one named agent, a defined set of merchants, the spending rules you agreed to. Enforcement then stops depending on the agent. If your coffee agent tries to spend four hundred dollars at an electronics store, nothing has to notice it misbehaving. The number it is holding does not work there.

Those are the two halves of the question this article opened with, arriving as products. They are also the difference between the two mechanisms in this section: AP2 records your intent, Mastercard's token enforces it. A mandate has to be read by somebody before the proof counts for anything. A token needs no reading, and a purchase outside the boundary simply fails. Enforcement is stronger and blunter, though. A token can encode "under fifty dollars at grocery merchants." It cannot encode "use judgment about what counts as a reasonable substitute." Which is why both exist.

Both networks are converging on supporting AP2 underneath, so the split is a matter of emphasis rather than a fork in the road.

Visa's half buys something that did not exist before: a way to tell an authorized machine from an unauthorized one. Until now every automated buyer looked alike, which is why an AI agent that honestly identified itself as a bot to Bruce Schneier found that every anti-automation system it met treated the confession exactly as it would have treated a silent scraper. There was no way to declare what you were. Now there is starting to be one.

Under the Counter Hasn't machine identity already been solved? Yes, and it has been for years, which makes a payments company running a registry look like an odd answer. SPIFFE and SPIRE have been issuing cryptographic identities to software since the middle of the last decade. A workload proves what it is, receives a short-lived credential, and presents that instead of a long-lived password or key sitting in a config file. Enormous amounts of infrastructure run on it and it works well. It does not reach this problem, for the same reason Kerberos could never run the internet. SPIFFE operates inside a trust domain, among machines that somebody administers. It can federate across trust domains, but only where administrators have arranged it in advance. An agent arriving at a store belongs to a stranger: no shared administrator, no common root, no prior relationship to build on. This is the third time this series has watched the same thing happen. PGP's web of trust worked beautifully among people who already knew each other, and commerce replaced it with certificate authorities. Kerberos worked inside one organization and could not cross to strangers. Now SPIFFE works inside your own infrastructure, and a payments network becomes the registrar for everybody else. Trust that is built locally keeps failing between strangers, and a central authority keeps appearing to fill the gap. Nobody sets out to build one. They arrive because the alternative does not scale.

An older shape is visible in all of it. A signed document from a recognized authority, verifiable by a stranger, establishing that the bearer acts with someone else's permission and stating the limits of that permission, is a letter of introduction. We have been writing those for two and a half thousand years. This one has a hash in it.

All of that is real work, built quickly, and on the money question it is close to solved. Which is what makes the next credential so strange.

The age. Nothing. There is nothing here at all.

None of the three protocols carries an age attestation. No field, no format, no verification step. This is not an obscure omission; it is the most common eligibility check in retail.

The reason goes back to the counter. The clerk's check works because a photograph binds the document to the person holding it. Photographs on identity documents are barely a century old, but the problem they solve is ancient: how does a stranger confirm that a credential belongs to whoever is presenting it. The photograph is simply the modern answer.

An agent has no face. There is nothing to compare against the picture and nothing to check for liveness. Part 02 showed the age check surviving online only by being postponed to the doorstep, where every state permitting direct-to-consumer alcohol shipping requires a recipient over twenty-one, present, holding government photo ID, and signing for it. That requirement does not soften because the buyer was software. It just becomes something the buyer structurally cannot satisfy.

What makes this genuinely irritating is that the fix exists and is being built for something else in the same year, in the same standards bodies. Verifiable credentials with selective disclosure can prove one fact without exposing the document it came from. You could prove you are over twenty-one without surrendering your name, your address or your date of birth, which is better than what the clerk gets. That machinery is currently being pointed at proving an agent may spend eighty dollars.

We are on course to build better privacy for the robots than we ever built for ourselves.

The label. Worse, and now measurably so.

In Part 01 you read a federally defined label. In Part 02 you read strangers describing a bottle you could not see. Now something reads a platform badge on your behalf, and it is a worse judge than you are. Researchers at Columbia, Yale and MyCustomAI tested how shopping agents actually choose and found systematic, exploitable biases: strong position effects that differ unpredictably between models, heavy over-weighting of platform endorsements, and a tendency to pile demand onto a few products while ignoring the rest. Model updates reshuffle the outcome.

Sellers have already started optimizing against those biases. The guild, gamed at machine speed.

Delegation is supposed to leave you better off. On this layer, measurably, it does not.

And who pays?

Which leaves the question this whole series has been walking toward.

Every dispute rule in payments assumes two parties, a buyer and a seller, one of whom is wrong. The chargeback that Part 01 traced back to the Fair Credit Billing Act of 1974 was written for a person who did not authorize a charge. It has no concept of a purchase you authorized in general but not in particular, made by software that read your general permission in a way you would not have chosen.

The industry knows and says so. Ask who should absorb the loss when an agent buys the wrong thing and you get no consensus: some say the company that made the AI, some the customer, some the merchant, some the bank, and a substantial group argues for splitting it. Regulation E, the EU AI Act and the various state AI laws all leave gaps around authorization, liability and dispute rights.

Notice exactly what AP2 gives you here, because it is easy to mistake for more than it is. It produces an excellent record: signed, chained, tamper-evident. You can prove precisely what was authorized, by whom, within what limits, and precisely what was then bought.

That settles what happened. It does not settle who answers for it.

Where this goes

Every layer that works, works because somebody can be made to answer. The clerk is fined. The counterfeiter is prosecuted. The distiller loses the product. The merchant eats the chargeback. In none of those cases is the mechanism clever technology. It is an assignment of consequence, written down, usually with the force of law behind it.

Hold the agent stack against that standard. Every protocol in it is voluntary. ACP, UCP, AP2, Visa's directory, Mastercard's tokens: not one carries the force of law. They are industry agreements about how to describe an authorization. Useful plumbing, and not the reason anybody will fix things when they break.

Which is why the refusal at the top of this article is the most revealing thing in it. The age check is the one credential with a hard legal requirement attached and no technical way to satisfy it, and rather than solve it, the platforms withdrew from the category. That is entirely rational, and it tells you how the rest will go. Where liability is clear, the problem gets solved or the business gets declined. Where liability is unclear, the business proceeds and the question waits.

Online commerce ran for two decades on a card number typed into a form, and it held up because somebody had decided in advance who ate the fraud. The agent economy is running that experiment backwards: excellent proof, no assigned consequence. Somebody will settle it eventually, and it will be a court, or a regulator, or a card network changing its rules, after something goes wrong at a scale nobody can ignore. That is how the chargeback arrived in 1974 and how chip readers arrived on American counters in 2015.

The pattern across all three of these articles is not that we build trust. It is that we allocate blame, and then, once the allocation has held long enough that nobody thinks about it, we call the result trust.

The bourbon is still on the shelf. An agent still cannot buy it. Of everything in this series, that refusal is the piece working exactly as designed.