nestonexStart a project How do you stop prompt injection from making an AI agent do something expensive?
Make sure the model cannot perform the action at all. If it can only produce a typed proposal, and that proposal passes schema validation, policy limits and an approval gate before anything executes, a successful injection produces a rejected request rather than a loss.
Because a model has no reliable way to tell its instructions apart from the data it is processing. Both arrive as text in the same context window, and the distinction you perceive between them is a convention, not a boundary the model enforces.
So any defence phrased as an instruction is competing with the attacker's instruction on equal terms. You can make injection harder with careful prompting and you cannot make it impossible, which means a system whose safety depends on the prompt holding is a system whose safety is probabilistic.
Separate proposing from deciding. The model reads the request and emits a typed object describing what it believes the user wants: an action, an amount, a destination. It does not call anything.
That object is then validated against a strict schema, checked against policy, and gated on approval before execution. Every one of those steps is ordinary code with no model involved, which is exactly why they cannot be talked out of their job.
The framing is older than agents. It is the same reason a server never trusts a browser: the client proposes, the server decides.
It must not consult the model. The moment a language model is asked whether an action is safe, you have reintroduced the thing you were defending against, because that judgement can be influenced by the same injected text.
It must fail closed. Anything it cannot parse or does not recognise gets rejected rather than passed through with a best guess.
And its rules have to be narrow enough to be meaningful. A token allowlist, a slippage cap and a per-action limit are checkable. A rule saying 'only do reasonable things' is not.
Anywhere the output has consequences. Sending email on someone's behalf, changing a booking, issuing a refund, deleting records, posting publicly. The stakes differ, the structure does not.
The question to ask of any agent feature is simple: if the model were adversarial rather than merely wrong, what is the worst it could cause? If the answer is anything you would not accept, the decision is in the wrong place.
Axon Wallet lets someone operate a multi-chain wallet in plain language. The intent planner turns a request into a typed intent and nothing else; that intent runs the same schema validation as any other API payload, then policy limits, then a two-factor gate before signing.
The result is that a malicious instruction buried in text can at most produce an intent, and an intent still has to survive every layer above. A successful injection ends as a failed request.
The injection itself cannot, because a model cannot reliably separate instructions from data. What you can prevent is the consequence, by making sure the model's output has to pass validation and approval it cannot influence before anything happens.
It is necessary but not sufficient. Forcing a typed schema stops free text reaching an executor, but an injection can still produce a perfectly well-formed intent asking for something harmful. The schema constrains shape; policy limits and approval constrain meaning.
No. Keys and tokens should sit behind the validation layer, reachable only by code the model cannot address. If an agent can present a credential, then anything that can influence the agent can spend it.
When the malicious instruction arrives in content the model was asked to process rather than typed by the user, such as a web page, a document or an email. It is the more dangerous form, because the user never sees the instruction and has no reason to suspect anything.