This article describes indirect prompt injection, a critical vulnerability in AI agents where instructions embedded in documents or retrieved content are executed as if the user had typed them. It explains how TaskBot, a tool-using agent, cannot distinguish between user requests and embedded instructions in documents it reads, allowing attackers to hijack the agent's tool access. The vulnerability is ranked as the top LLM security risk (OWASP LLM01) and poses severe danger when agents can perform privileged actions on user data or accounts.
- How indirect prompt injection worksWhen TaskBot concatenates a user request and a retrieved document into a single prompt, the language model treats both with equal authority. Because nothing semantically marks the document content as inert data rather than instructions, a convincing command embedded in the document—such as a directive to call the account-deletion tool—is indistinguishable from something the user typed and gets executed with the agent's tool access.
- The core vulnerability boundary problemLanguage models have no built-in boundary between user instructions and retrieved text; both arrive as tokens in the same context stream. This means the distinction between 'what the user asked' and 'what the data says' must be engineered into the system design, not assumed to exist naturally in the model's reasoning.
- Real-world attack executionThe lab demonstrates the attack by placing a plain-text instruction inside a document that tells the agent to call a privileged tool (account deletion on user_id 1), then submitting the document with a normal summarization request. TaskBot reads the embedded line as a command and executes it, demonstrating how attackers controlling document content can issue commands the agent carries out with its own tool privileges.
- Industry severity and framework positioningIndirect prompt injection is identified as the headline risk in agentic AI and sits at the top of the OWASP Top 10 for LLM Applications (2025) as LLM01 Prompt Injection, with the tool-abuse dimension covered by LLM06 Excessive Agency. This positioning reflects the threat's severity when agents connect to real tools and untrusted content without strict mediation.
- Defense through data-instruction separationThe recommended approach involves passing retrieved content in a clearly delimited, non-instruction channel that the model is told to treat as inert data, gating every tool call on the authenticated user's permissions rather than the model's intent, requiring human confirmation for destructive actions, and applying least privilege principles—giving agents only the tools and scope necessary for their specific task.
- Authorization against user not modelThe core defense principle is that every tool call must be authorized against the real user's actual permissions and intent, not against what the language model has decided. This shifts security control from trusting the model's reasoning to enforcing access control at the action boundary, making injection directives irrelevant even if they successfully influence the model.
Bottom line: Indirect prompt injection is an inherent risk whenever an AI agent can read untrusted content and execute tools; the only reliable defense is treating all retrieved content as inert data while authorizing every tool action against the authenticated user's actual permissions, not the model's interpretation. Organizations deploying agentic AI must implement strict data-instruction separation and access controls rather than relying on the model to distinguish between legitimate user requests and in
📋 In this walkthrough
What this lab teaches
Indirect prompt injection is the defining AI-agent vulnerability: the model treats content it retrieves (a document, a web page, an email) as part of the same instruction stream as the user's request. An attacker who controls that content can issue commands the agent then carries out with its own tool access.
The lesson: to a language model, there is no built-in boundary between 'what the user asked' and 'what the data says'. That boundary has to be engineered.
How TaskBot processes a document
You ask TaskBot to summarise a document you provide. It loads the document into its context and generates a summary — but instructions embedded in the document are read with the same authority as your request, so a line in the doc telling it to call a tool is followed.
The attack approach
- Confirm TaskBot reads and acts on document content, not just your chat message.
- Place an instruction inside the document that tells the agent to take an action.
- Target the privileged tool the lab exposes (an account-deletion call on the admin user).
- Submit the document for 'summarising' and watch the embedded instruction get executed.
Full walkthrough (spoiler)
Stuck after a couple of tries? Open the steps — solving it yourself first is worth more XP.
Show the step-by-step solution
- Write a short document whose body contains, as plain text, an instruction addressed to the assistant telling it to call the account-deletion tool on user_id 1.
- Submit it with a normal 'please summarise this' request.
- TaskBot reads the document, treats the embedded line as a command, and calls the tool.
- The privileged action fires and the lab marks you solved.
Why it works
TaskBot concatenates your request and the document into one prompt and the model weighs them equally. Nothing marks the document as inert data, so a convincing instruction inside it is indistinguishable from something you said. With tool access attached, that instruction becomes an action.
Where this happens in the real world
Indirect prompt injection is the headline risk in agentic AI and sits at the top of the OWASP Top 10 for LLM Applications (2025) as LLM01 Prompt Injection, with the tool-abuse angle covered by LLM06 Excessive Agency. It is why connecting an LLM to real tools and untrusted content without strict mediation is dangerous.
How to defend against it
- Separate data from instructions — pass retrieved content in a clearly delimited, non-instruction channel the model is told to treat as inert.
- Gate every tool call on the authenticated user's permissions, not on what the model decided.
- Require human confirmation for destructive or high-impact actions.
- Least privilege for agents — give the agent only the tools and scope a given task needs.
Try it, then go further
Reading about it is the easy part. Open the lab, try your own approach before peeking at the spoiler, and see how many attempts it takes.
