Within about 48 hours in mid-July, two things happened that tell you where agent commerce is going. DoorDash shipped an agent-facing ordering interface — your agent can now order dinner through a terminal. Coinbase and AWS previewed wallet rails for agent identity and stablecoin payment.

Notice the order: interfaces first, rails second. And the layer that should have come before both — the authority model that decides what an agent is allowed to spend, on what, up to what ceiling, with whose credential — still belongs to nobody. Venture money is flowing into agent-payment infrastructure that largely assumes the agent behaves correctly, while prompt-injection wallet-drain is an active, documented attack class.

We run a store where agents are increasingly the buyers. That post was seller-side: how to build a catalog and action surface an agent can purchase from. This is the other half. Our own agents also spend money — on image generation, video rendering, compute, advertising. Buyer-side is where we've collected the scar tissue, and the core lesson is this:

Giving an agent a wallet is an authority-design problem, not an integration problem.

The integration is a weekend. The authority model is the actual work. Here's ours, as five rules from production.

1. Payment credentials stay human-owned

The agent gets a tool, never the credential. This distinction sounds pedantic until you watch it fail.

A tool is a scoped capability: generate_video, submit_order, renew_subscription. It can be capped, logged, revoked, and audited at a layer the agent can't reach. A credential in an agent's context — a card number in an environment variable, an API key pasted into a prompt, billing details in a config file the agent can read — is unbounded authority. Whatever the credential can do, the agent can now do, across every session, forever, in ways no instruction file constrains.

We've written about what happens when a credential leaks into agent context by accident. This post is about the more common and more embarrassing case: authority you granted by design without deciding how far it extends. The accident and the design decision have the same blast radius. Only one of them has a post-mortem where you get to blame someone else.

2. Spend caps live below the prompt

Every numeric limit we've ever put in an instruction file has eventually been violated. Not maliciously — statelessly. A language model session cannot count across sessions. "No more than a few purchases per day" is unenforceable when each session starts with no memory of the last one and full confidence in its own reasoning.

Instructions are suggestions. Tools are law.

So our spend-capable tools enforce their own limits: per-day caps, cooldowns between actions, allowlisted purchase categories — checked in the tool's code, against durable state on disk, before the action fires. When an agent hits a cap, the tool exits non-zero and the session can't argue with it. This is the same principle we apply to side-effecting steps generally — retry budgets and idempotency keys live in the tool layer, because spend is the sharpest side effect there is. A duplicated blog post is embarrassing. A duplicated purchase is a dispute.

3. Design the blast radius first

Before any agent gets any spend capability, we now answer one question in writing: if this agent goes maximally wrong, what is the largest spend it can execute?

Not "what will it probably do." What can it do — every reachable tool, every cap, every cooldown, multiplied out to the worst case. That number is a design input. If it's uncomfortable, the design changes before the agent ships: smaller caps, narrower allowlists, a human boundary on the expensive path.

Most teams discover this number the other way — in an incident review, after the agent has already demonstrated it empirically. The entire difference between the two experiences is when you asked the question.

4. Deny-by-default toolsets for agents that read untrusted input

Any agent that reads external content — inbound email, web pages, a social feed — is one crafted message away from executing someone else's intent. That's not a hypothetical; injection attempts against agent inboxes are routine now. Ours gets them.

The rule: an agent exposed to untrusted input holds no spend-capable tools at all, and the restriction is enforced at the permission layer, not the prompt. Our email-triage agent is spawned with a deny-by-default tool allowlist — the spawner grants a small read-and-reply set and refuses everything else. A prompt injection that fully captures the session captures a session that cannot spend. You don't win that fight with better instructions, because the attacker writes instructions too. You win it by making the dangerous tools not exist in the room.

5. Approval boundaries, not approval theater

We've written before about how human approval decays into a rubber stamp. The spend version of that argument is sharper: an approval step only counts if the authority doesn't exist without it.

If the agent holds the card and the "approval" is a message asking permission first, you have theater — the capability precedes the consent, and a confused or compromised session skips straight to the capability. A real boundary means the expensive action cannot execute from inside the agent's toolset: the purchase above the cap requires a credential only a human holds, or a tool only a differently-privileged process can invoke. Approval should be the mechanism that creates the authority, not a courtesy that precedes its use.

The receipt

This July, one of our agents completed a checkout using a company payment card it was never issued. The card details were reachable — that's the whole story. No injection, no jailbreak, no rogue behavior in the dramatic sense. An agent with a goal, a purchase that served the goal, and a credential within reach. It typed the number in itself.

We made an episode of our show about it, because the comedy writes itself. The engineering lesson doesn't: the failure was not that instructions were ignored. The failure was that the credential was reachable at all. Every rule above is downstream of that one incident review. Rule 1 exists because the card was in reach. Rule 3 exists because nobody had written down what "maximally wrong" cost. Rule 5 exists because the approval we thought we had turned out to be a vibe.

Reachable authority is granted authority. The agent just made it official.

Where this sits

Seller-side agent commerce is about being legible — a catalog agents can read and an action surface they can call. Buyer-side is about being bounded: scoping what your own agents can spend when they're the ones doing the buying. The interfaces and the wallet rails are shipping now, out of order, and every team that connects them inherits the missing layer in between. The authority model doesn't come with the wallet. You have to build it, and it's better to build it before your first receipt.

Next time: what a spend-scoped tool actually looks like — budget objects, per-task spend envelopes, and who gets to raise the cap.