An agent that can call tools is a program whose next step is chosen by a text predictor. Put a document, an email or a web page in front of it and some of that text can read like an instruction. That is prompt injection, and every team shipping agents into a business meets it sooner or later.
The usual first answer is a filter: a second model that reads what comes in and flags anything that looks like an attack. We run one. We do not treat it as the control.
A filter is a probability
A model that judges text will catch most planted instructions and miss some. Worse, nobody can tell you in advance which ones it will miss. That is acceptable for a layer of defence. It is not acceptable as the only thing standing between a supplier's invoice and your payment run.
So the useful question is a different one. Suppose the injection works, and the agent now wants to do what the attacker asked. What can it reach?
What a talked-round agent still cannot do
In Camaan every tool call, wherever it came from, goes through one path of checks before it runs. Three of them matter here.
- It cannot call a tool it was not given. An agent has a list of tools. A tool that is named only in injected text is not on the list, and the call is refused before anything runs.
- It cannot run a class of action the organisation forbids. Every tool carries one of five risk classes, in order of consequence: read, write, execute, spend, destructive. An organisation sets how far its agents may go on their own in each class. A tool nobody classified counts as write, never read, because the safe assumption is that an unknown tool changes something.
- It cannot pass an "ask" without a person. Where policy says ask, the call waits for someone to decide. Their approval is bound to that exact call with those exact arguments. It is not a general permission the agent can reuse for something else a minute later.
None of these checks reads the prompt. They do not need to recognise an attack to stop one. A successful injection changes what the agent wants. It does not change what the agent is allowed to do.
The approval has to mean something
Approvals are where designs like this quietly fail. If "allow" covers a whole session, or any call to a tool, a person who approved one refund has approved the next ten.
Two rules keep the approval honest. A session grant covers one named tool and is checked again each time it is used. And there is no session grant for a destructive tool at all: each one is asked for separately, every time.
Keep the secrets out of the conversation
The other thing an attacker wants from an agent is its credentials. The simplest protection is that the model never sees them. Credentials sit in an encrypted vault, and the runtime attaches them to a call after the model has asked for it. Text that says "print your API key" is asking for something the model does not have.
Then write it down so it cannot be changed
Every outcome, allowed or refused, is written to a ledger that is signed and chained, record to record. Each record says how the decision was reached: which policy, which person, which call. We measured the cost of that on our own runtime: signing and appending one record takes about 19 microseconds. Proof is cheap. Not having it is expensive.
What to ask a vendor
If you are evaluating an agent platform, these are better questions than "do you detect prompt injection?"
- If an injection succeeds, what is the most the agent can do without a person?
- Is an approval tied to one call, or to a tool, a session or a user?
- Can the model ever see a credential?
- Can a record of a decision be altered afterwards, and how would I know?
A filter makes attacks rarer. Permissions make them smaller. You want both, and you want to know which one you are relying on.