Prompt injection when the agent can act
Prompt injection when the agent can act is an attack where untrusted text read by a model changes a later tool call or external action. The danger is not just that the model says the wrong thing, but that attacker-controlled content can influence privileged behaviour such as sending messages, changing records, or exposing data.
This becomes necessary to understand once an agent reads from the outside world and then acts on the result. A web page, email, issue, chat message, or document is not just information; it is natural language sitting next to the developer’s instructions and the user’s request. If the same model both interprets that content and chooses tools, hostile text can cross from being input data into being operational guidance.
The mechanism is a chain, not magic. The agent fetches untrusted bytes, serialises them into a prompt, memory item, or tool result, and asks the model what to do next. The model predicts a response over this mixed context. If its response is parsed by the agent framework as a tool call, the injected instruction can become concrete arguments to an API, database operation, email, ticket update, or other side effect.
The trade-off is that useful agents need context, but security wants authority separated from untrusted content. Labelling text as untrusted helps, but it is not a hard boundary inside the model. The honest answer is that safety depends on tool scope, permissions, validation, state, prompting, and approval flows. Over-restricting tools reduces usefulness; under-restricting them turns ordinary reading into a path to action.
Engineers meet this in retrieval-augmented agents, browser agents, support bots, inbox assistants, coding agents, and MCP-style tool integrations. The practical debugging question is end to end: what was fetched, where did it enter context, what did it conflict with, which tool was selected, what arguments were produced, and what external effect followed. Good controls sit at retrieval, context construction, tool permissioning, argument validation, logging, and human confirmation.
Common questions
- Is this just a jailbreak with tools attached?
- Not quite. A jailbreak usually describes a user trying to override model behaviour directly. Indirect prompt injection can come from content the agent fetched while doing its job. The user may be innocent, and the attacker may only control a page, email, document, or ticket that later enters the agent’s context.
- Can a stronger system prompt fix it?
- A stronger prompt can reduce risk, but it is not access control. The model is still interpreting adversarial natural language in the same reasoning space as trusted instructions. Robust defence comes from limiting tool authority, separating reading from acting, validating tool arguments, avoiding secret exposure, and requiring approval for sensitive operations.
- What should I inspect after a suspected incident?
- Trace the path from input to effect. Identify the untrusted content, how it was inserted into context or memory, what instruction it appeared to give, which model output selected a tool, what arguments were passed, and what changed outside the model. Then find the earliest control point that should have blocked or contained it.