Give Your Agent a Card, Not Your Wallet

I've now watched several genuinely smart people bounce off the authorization chain. Six links, formal names — principal, delegation, subject, boundary, proof, signed execution — and somewhere around link three their eyes say this feels like bureaucracy.

Fair. So forget the whitepaper for a minute. You already trust a six-link authorization chain every day. It's in your pocket.

You never hand over your wallet

When you buy coffee, you don't give the barista your wallet. You present a card. The card is not your money — it's a bounded grant of your money: this account, up to this limit, until this date. Behind it, a network you've never spoken to decides yes-or-no in milliseconds, using rules the merchant cannot touch. And every transaction produces a receipt that outlives everyone involved.

That's the chain. All six links, in a system so boring you've never once thought about it:

Six links, each held by someone different. The merchant cannot approve their own charge. The network never touches your cash. The receipt can still win a dispute years later. Nobody calls this bureaucracy — it's just how money works. Which is exactly what good infrastructure feels like: invisible until you imagine removing it.

And for an agent, the card is even narrower than the one in your pocket. Not “a card with a limit” — $5, for coffee, at this shop, today. Present it for anything else and nothing happens. Not declined after consideration — inert, because the authority it carries never included that action in the first place. The grant is the ceiling, and the ceiling can be one coffee high.

Today's agents get the wallet

Now the uncomfortable part. When we deploy an AI agent today, we hand it an API key. An API key is not a card. It's the wallet. Whoever holds it is you — full balance, no limit, no network in the path, no receipt anyone else can verify.

Which means a prompt injection isn't really "hacking" anything. It's just asking the wallet-holder nicely. The model was given your authority wholesale, so anyone who can talk to the model can spend it.

Delete a link, get a disaster

The reason the chain has six links — not one, not three — is that each one exists because of a specific way things go wrong without it:

• No principal → authority with no owner. When it goes wrong, everyone points at "the AI."
• No delegation → the intern has the corporate bank login. Unlimited, unexpiring.
• No subject → you can't even say which agent spent the money. Names were self-asserted.
• No boundary → the agent approves its own actions. The trader is now the clearing house.
• No proof → the audit log was written by the thing being audited. "Trust me."
• No signed execution → the record says one thing happened; reality did another. The dispute is unresolvable.

Every one of these failure modes is already sitting in some company's incident report. The chain isn't a theory about what might go wrong. It's a checklist of what already has.

For the hole-pokers

The smartest people don't stop at the analogy — they start attacking it. Good. The attacks are where the design earns its keep, because the chain's real trick is that authority moves as signed artifacts, not as access. The delegation isn't a row in a config file; it's minted — issued and signed by a registry, the way a bank issues a card. What the agent carries is inert. Walk the attacks:

• “The agent could just claim a bigger delegation.” It can't — it didn't write the delegation and can't forge the signature. And delegations only narrow downstream, never widen. A merchant can't print themselves a card with a higher limit.
• “A clever prompt could talk the boundary into it.” There's no one to talk to. The decision is a signature check plus an exact match against the specific action — deterministic, no model in the path. You cannot sweet-talk a hash comparison.
• “Skip the boundary and call the executor directly.” The executor is the only thing holding real credentials, and it refuses anything without a boundary-signed pass it verifies itself. The merchant never gets to reach into settlement.
• “Get X approved, then execute Y.” The pass is bound to the exact action — change one parameter and it no longer matches, and nothing runs. An auth code for $4 doesn't settle a $4,000 charge.
• “Steal a key.” Which one? Four authorities, four keys, no master. A stolen agent token is inert; the boundary holds no credentials; the executor won't act without a valid pass. Cheating requires collusion between separately-keyed parties — which is precisely the property that makes card networks, clearing houses, and certificate authorities work.
• “The system could lie about what happened.” Every artifact is signed by a different party, and the whole chain verifies offline against published keys. You don't have to trust the system that produced the record to check the record.

That's why hole-poking it feels frustrating: each obvious hole is a link's whole reason for existing.

“Can't we just do one big permissions check?”

The most common pushback — and it sounds reasonable, because a check is simpler than a chain. But collapsing the links collapses the separation that makes the system trustworthy. A check answers one question, once: allowed? A chain answers four different questions — who decided, what was granted, whether this action fit, and what actually happened — each answerable separately, by a different party, years later.

Your card statement from 2019 can still win a dispute today. That's not a permissions check. That's a chain whose proof outlived the transaction.

The punchline

The authorization chain isn't a new invention. It's the pattern every system that survived contact with real money converged on — cards, clearing houses, operating systems, certificate authorities. AI agents are simply the newest merchants, and right now we're doing the one thing no payment system would ever do: handing them the wallet.

Give the agent a limited-scope card. Never the wallet. That's the whole idea — the whitepaper is just that sentence, made precise.