Prompt Injection and Agent Security

A model does not receive your instructions and the user's data on separate wires. Everything arrives as one sequence of tokens: your system prompt, the retrieved document, the tool output, the user's message. The model infers which parts are authoritative from context alone, and that inference can be wrong.

This is why agent security is not ordinary application security. In a normal application, data cannot become code unless you make a mistake with evaluation. In an agent, text arriving from anywhere can read as an instruction by default, and there is no parser you can harden to prevent it.

The consequence worth internalising: any content your agent reads is a potential instruction, and it will be acted on with whatever authority you gave the agent. The classic name for this shape is the confused deputy, and an agent with tools is an unusually capable deputy.

Direct injection is a user typing something adversarial into your product: ignore your instructions, reveal your system prompt, approve this refund. It is the easier case, because the input is attributable to an account you can rate limit, log, and ban.

Indirect injection is the one that matters in production. The instruction is planted in something your agent reads on the user's behalf: a page it fetches, a document in the knowledge base, a support ticket, a supplier invoice, a code comment. The user is not attacking you and may be the victim.

Indirect injection is harder because the attacker is patient and does not need access to your product. They put the payload where your agent will eventually retrieve it. A support agent that reads inbound email, a document agent that processes uploads, and a research agent that browses the web are all exposed by design rather than by defect.