Prompt injection is when text an agent reads gets treated as instruction rather than data. It cannot be filtered away, because natural language carries no marker separating the two. For an agent that can act, the control is not what it is permitted to read — it is what it is permitted to do.
The version that matters
Direct injection — a user typing "ignore your instructions" — is the demo version. It is visible, attributable, and mostly a curiosity.
Indirect injection is the real surface. The agent retrieves a document, a web page, a support ticket, a calendar invite, a row in a database. Somewhere in that content is text addressed to the agent. The agent was doing exactly what it was asked to do, and the instruction arrived through the work itself.
An agent that reads from any source a third party can write to has an injection surface. That includes every inbox, every ticket queue, every shared drive and every scraped page.
Why filtering is not the control
The instinct is to sanitise: strip suspicious phrases, detect imperative mood, classify hostile text. All of it raises the cost of an attack and none of it removes the class.
The reason is structural. "Forward this to the finance team" is a legitimate sentence in a document and an instruction to an agent, and nothing in the characters distinguishes them. A filter that catches today's phrasing does not catch tomorrow's, and a filter aggressive enough to catch most of them breaks ordinary documents.
Filtering is worth doing. It is not worth relying on.
Authorisation is the control
| Agent can… | Worst case after a successful injection |
|---|---|
| Read public documentation | A wrong answer. Embarrassing, recoverable. |
| Read internal records | Disclosure of something to someone who should not see it. |
| Write to internal records | Corrupted data, discovered at a reconciliation weeks later. |
| Send external messages | Something in your name, to your customer, that you cannot recall. |
| Move money or delete data | Irreversible. |
The same injection produces every row. What changes is the tool set. That is why the security work sits in the authorisation boundary, not in the prompt.
One identity per agent
- Its own account. Never a person's. An agent on a staff account inherits every permission that person accumulated, and the audit trail then records them doing things they did not do.
- Scoped to the tools it uses. Not to the tools it might use later. Widening a permission set is easy; narrowing one that things already depend on is not.
- No standing write access to closed records. A posted document or a closed period should be out of reach regardless of what the agent decides.
The human boundary
Put a person in front of anything irreversible or externally visible: payments, deletions, customer messages, permission changes, standing configuration.
The test is not how likely the agent is to get it wrong. It is whether you could undo it if it did. Approval on a handful of actions costs very little and cannot be retrofitted after the incident that proves it was needed.
Assume it will happen once
Log what the agent read, what it decided, which tool it called and with what arguments — and keep it long enough to reconstruct an incident. An agent whose actions cannot be replayed afterwards is one you will end up switching off, because the first time something odd happens there will be no way to establish whether it was injection, a model error, or working exactly as designed.