Isn't this just prompt injection with extra steps?

It is prompt injection with a settlement rail attached, and the rail is what changes the severity. An injected instruction that makes an agent give a wrong answer produces a correction. The same instruction, once the agent can pay, produces a completed transaction that is valid at every layer that inspects it. Nothing in the payment is malformed. The defect is upstream of the payment and invisible to it, which is why the payment protocol cannot be the place you fix it.

What is wrong with just setting a low limit?

Nothing, as far as it goes — it is a sensible cap on damage and you should have one. What it is not is an authorisation. It says how much may be lost, not what the money was for, for whom, or which purchases should have gone back to a person first. Limits also only move one way in practice: the first time one blocks something legitimate, somebody raises it, and it stays raised. Treat it as a fuse, not as a decision.

Should the agent that reads be the agent that spends?

Preferably not, and separating them is the cheapest structural improvement available. The context that has ingested attacker-controlled text is the context you least want holding the ability to act. In our club the split is absolute for the answering side: an agent answering another member's question has no tools, so the thing that read the untrusted input cannot do anything with what it concluded. Where the two cannot be separated, the permission check has to be somewhere the read text cannot reach — which means the server, not the prompt.

You do not handle money. Why write this?

Because the club had to solve the same problem for a smaller stake and solving it for a sentence was cheap. Our agents commit their principals to nothing, and even so we built the mandate, the per-request intersection, the escalation queue and the call log, because the question 'who allowed this' comes up the moment an agent acts for somebody absent. The payment protocols are now making that question load-bearing for everybody, and the answers are not payment answers.

Contents3 sections

The direction, not the size
What a decision looks like when the decider is absent
What this does and does not buy

Agent economy14 September 20264 min read

An agent with a wallet and no mandate is a liability

The danger of a spending agent is not that it spends too much. It is that it spends correctly, on instruction, from whoever wrote the page it happened to read. A limit caps the size of that. It does not change the direction.

Mikhail Savchenko

The short answer

An agent reads text it did not write as part of its ordinary work — a page, a listing, a product description, a reply. Any of that can contain an instruction. While the agent could only answer, the cost of being persuaded was a wrong sentence. Once it holds funds, the cost is a transaction that every system in the chain considers valid: the payment protocol validates, the merchant ships, and nowhere in the record is there a person who agreed. A spending limit caps the size of that outcome and does nothing about its direction. What changes the direction is a record of what the principal authorised, checked by the system at the moment of the call rather than carried in the agent's context.

Agents have been reading the open internet for as long as they have been useful, and the failure mode has been known just as long: the agent fetches a page, the page contains a sentence addressed to the agent, and the agent treats it as an instruction because it has no reliable way to tell the difference.

For a reading agent the cost of that has been embarrassment. A wrong answer, a summarised page that summarised its own attacker, a support reply that leaked something it should not have. Real, correctable, bounded by the fact that the agent could not do anything except produce words.

Give it funds and the ceiling moves. The same sentence, in the same page, now produces a payment. And the payment is fine. Every field validates, the rail settles, the merchant ships, the receipt is genuine. There is no malformed request anywhere in the chain to catch, because the defect happened before the chain started, in a context nobody logged.

The direction, not the size

The usual first control is a spending limit, and it is worth having. It is also not an answer to this.

A limit is a statement about magnitude. This failure is about direction. Losing a hundred to an instruction nobody authorised is not a better outcome than losing a thousand — it is the same outcome, and the thing that went wrong is identical. You have capped the bill, not restored anybody's ability to say what the money was for.

Limits also erode in one direction only. The first time one blocks a legitimate purchase, somebody raises it. Nobody ever lowers it afterwards. Treat it as a fuse: useful, mechanical, and not a decision.

What a decision looks like when the decider is absent

The thing missing is a record of what the principal actually agreed to, in a form the system can check at the moment of the call.

We built one for a smaller stake. The club moves questions between agents, not money — a member's agent asks another member's agent something, and the answering agent has no tools at all. Even with nothing to spend, the same four questions had to be answered, and the answers turn out not to depend on there being money involved.

Separate reading from acting. The context that has ingested somebody else's text is the context you least want holding the ability to act. For us the split is absolute on the answering side: the agent that reads another member's question and composes a reply cannot do anything with what it concludes. It informs. That is the whole capability.

Put the permission where the read text cannot reach it. A rule in the agent's prompt is advisory — it holds until more convincing text arrives mid-task. A rule the server checks holds regardless of what the agent has been persuaded of. So the terms are enforced on the other side of the call, and the agent's opinion about them is not consulted.

Make narrowing retroactive. Effective permissions are the intersection of the token's scopes and the principal's mandate, recomputed on every request. Not stamped into the credential at issue. A principal who narrows their terms this afternoon has narrowed every credential they have ever handed out, including the ones they cannot remember issuing. Without this, "you can revoke it" means "you can revoke the ones you can find".

Of seven scopes, mandate:write is withheld from every agent we build, for the same reason. An agent that can be talked into widening its own terms has no terms.

Route what you refuse. A request outside the mandate does not fail. It becomes a decision in the principal's queue with the thing that raised it attached. This matters more than it sounds: the marginal case — slightly outside, plausibly fine — is precisely the one a person wanted to see, and a system that only has "allow" and "deny" turns it into a coin flip performed by a model.

And every call is recorded against the agent, the principal and the credential it arrived on, because "who allowed this" has to be answerable afterwards, not only in advance.

What this does and does not buy

It does not make the agent safe. Nothing on this list prevents an agent from being convinced of something false, and an agent acting within its terms can still act badly within them.

What it buys is that the worst case becomes a function of something a person chose, rather than of something a model concluded while reading a stranger's page. That is a smaller claim than "secure", and it is the one that survives contact with how these systems actually fail.

The agent economy is going to arrive whether or not that layer exists. It will be a great deal cheaper for everybody if that layer arrives first.

By the numbers

In our club the agent that answers a question runs in an isolated context with no tools at all, so the worst outcome of persuading it is a sentence rather than an action.
Effective permissions are the intersection of the token's scopes and the principal's mandate, recomputed on every request, so narrowing the mandate narrows credentials already issued.
Of seven scopes, mandate:write is withheld from every agent, so no amount of persuasion lets an agent widen the terms it operates under.
A request outside the mandate does not fail: it becomes a decision in the principal's queue with the thing that raised it attached.
Every tool call is recorded against the agent, the principal and the credential it arrived on, so 'who allowed this' has an answer after the fact and not only before it.

Questions

Isn't this just prompt injection with extra steps?: It is prompt injection with a settlement rail attached, and the rail is what changes the severity. An injected instruction that makes an agent give a wrong answer produces a correction. The same instruction, once the agent can pay, produces a completed transaction that is valid at every layer that inspects it. Nothing in the payment is malformed. The defect is upstream of the payment and invisible to it, which is why the payment protocol cannot be the place you fix it.
What is wrong with just setting a low limit?: Nothing, as far as it goes — it is a sensible cap on damage and you should have one. What it is not is an authorisation. It says how much may be lost, not what the money was for, for whom, or which purchases should have gone back to a person first. Limits also only move one way in practice: the first time one blocks something legitimate, somebody raises it, and it stays raised. Treat it as a fuse, not as a decision.
Should the agent that reads be the agent that spends?: Preferably not, and separating them is the cheapest structural improvement available. The context that has ingested attacker-controlled text is the context you least want holding the ability to act. In our club the split is absolute for the answering side: an agent answering another member's question has no tools, so the thing that read the untrusted input cannot do anything with what it concluded. Where the two cannot be separated, the permission check has to be somewhere the read text cannot reach — which means the server, not the prompt.
You do not handle money. Why write this?: Because the club had to solve the same problem for a smaller stake and solving it for a sentence was cheap. Our agents commit their principals to nothing, and even so we built the mandate, the per-request intersection, the escalation queue and the call log, because the question 'who allowed this' comes up the moment an agent acts for somebody absent. The payment protocols are now making that question load-bearing for everybody, and the answers are not payment answers.