Indirect prompt injection

A language model does not reliably distinguish trusted instructions from untrusted data: everything in its context window is text it may act on. Indirect prompt injection abuses that. The attacker plants instructions in a place the application will later feed to the model without a human reading it first: a comment on a page the agent browses, a field in a record pulled by retrieval-augmented generation, the output of a tool the model called. When the model reaches that text, it may treat the planted instructions as its own task, and if the application has wired the model to tools, it can now be steered into sending data, calling an API, or taking an action the user never asked for.

This is where a toy prompt trick becomes a finding. Direct prompt injection needs the attacker to talk to the model; indirect injection only needs them to control something the model will later read, which in a connected system is a much larger surface. In the assessments we run, the exploitable case is an agent that summarises untrusted content and also has a tool to send email or query a database: a hidden instruction in the content redirects that capability. The parent problem is architectural, so filtering the input does not solve it. Any content the model ingests is a potential instruction source, and the damage scales with what the model is allowed to do.

We treat every path where untrusted content reaches the model as an injection surface, and we test what happens when that content carries instructions: does the model act on them, and what can it reach if it does. The severity is decided by the model’s permissions, not by the cleverness of the payload, which is why we assess this together with the tool design and least-privilege scoping. Filters and guardrails are recorded as partial mitigations, never as fixes. This is part of how we test an LLM application with tools.