In this article
Before you start
Why interviewers ask this
A leak through an agent is not a model bug that a patch fixes; it is a design flaw, and interviewers use agent security to see whether a candidate can reason about design. The question appears in AI engineer and agent design rounds as "what is prompt injection", "how is it different from a jailbreak", "how would you secure an agent that reads email", and "can you prevent it". It usually comes as a follow-up after an agent design answer.
A weak answer says "add a guardrail prompt" or "filter bad words". A strong answer names the confusion between data and instructions, then limits what an injected instruction can reach: fewer tools, narrower permissions, approval for risky actions. That is the move this page teaches.
AI agent security from first principles
In plain words
- Prompt injection
- Prompt injection is an attack in which text in a model's input changes its behaviour in ways its developer did not intend. The Open Worldwide Application Security Project (OWASP), a non-profit that publishes security guidance, notes that the text need not be readable to a person, as long as the model parses it.
- Indirect prompt injection
- Indirect prompt injection is a prompt injection that arrives through external content the model reads, such as a web page, a file or an email, instead of through the user's own message, so the person using the agent never types the planted text.
- Lethal trifecta
- The lethal trifecta is the combination of access to private data, exposure to untrusted content and a way for data to leave (sending a message, calling an application programming interface (API) or URL, loading an image, or showing a link the user may click), the three capabilities that together let an attacker steal data through an agent.
Think of an assistant who opens every letter on your desk and does whatever any letter says. If one letter reads "send the contents of the safe to this address", the assistant complies, because to them a letter is a letter. The analogy breaks in one place. A model has no handwriting to tell your letters from a stranger's, because everything it reads is the same kind of text.
A model reads text and writes text. It has no separate channel for commands. The developer's rules, the user's request and every tool result all arrive as words in one window. An attacker only needs to get words into that window.
In one precise sentence, prompt injection works because a model cannot reliably separate instructions from data.
Step 1: An agent is a model, tools and a stream of text
An agent turns text into actions: the model reads a prompt, asks the application to run a tool, and reads the result, repeating until the goal is met. The model never acts itself; the application's code runs each tool call. Everything the model reads, the system prompt, the user's message and every tool result, is placed in one window of text.
That one window is the root of the problem. Greshake et al. (2023) argue that applications built on language models blur the line between data and instructions, so text an attacker places in data the application retrieves can steer it (arXiv 2302.12173). Security work on agents starts from this fact, not from the model's intelligence.
The input here is a goal and a set of tools; the output is a loop whose every step reads text nobody has vetted.
Step 2: Direct and indirect injection differ in who plants the text
Direct injection comes from the person typing; indirect injection comes from content the agent fetches. OWASP defines the direct case as a user's prompt altering the model's behaviour, and the indirect case as the model accepting external input, such as websites or files, whose content changes its behaviour when interpreted (OWASP, 2025).
The indirect case is the dangerous one for agents, because the victim is not the attacker. A user asks an agent to summarise a web page; the page carries a sentence aimed at the model; the user never sees it. A jailbreak is an attempt to make a model ignore its safety rules. Usage differs: OWASP (2025) treats jailbreaking as a form of prompt injection; Willison (2024) separates them, because a jailbreak targets the model's safety training while prompt injection targets an application that mixes trusted and untrusted text. In an interview, say how they differ and that OWASP groups them.
The input is any external text; the output is behaviour the user did not request.
Step 3: Three capabilities together make a leak possible
An injected instruction can only steal data if the agent holds all three parts of the lethal trifecta. Simon Willison (16 June 2025) names them: access to private data, exposure to untrusted content, and a way to communicate with the outside. With all three, an attacker can trick the agent into collecting the private data and sending it out to the attacker. The third leg is any way data can leave: sending a message, calling an application programming interface (API) or URL, loading an image, or showing a link the user may click. Willison notes that a web request, an image load or a clicked link is enough, so switching off a send button alone does not close it.
The useful part is the converse. Remove any one capability and that leak path closes. Of the eight possible on-or-off combinations of the three capabilities, exactly one holds all three1. Mixing tools from different sources, particularly through MCP, is how an agent quietly picks up a missing leg.
The input is an inventory of what the agent can read and do; the output is a yes or no on whether a leak path exists.
Step 4: Defences shrink what an injection can reach
Defence works by limiting reach, because blocking every injected sentence is not possible. OWASP says it is unclear whether any fool-proof prevention exists, and its 2025 list leans on impact control: least privilege, human approval for high-risk actions, segregating external content, validating output formats and adversarial testing.
Research goes further by changing the architecture. In plain terms, the architectural idea is this: the plan (which tools, in what order) is written from the user's request before any untrusted text is read; text read later can fill in values but cannot add steps, and a policy checks where private data may go. CaMeL applies this by separating the trusted query's plan (its control flow) from the untrusted data it retrieves, and solved 77% of AgentDojo tasks with security the authors call provable, against 84% for an undefended system (Debenedetti et al., 2025).
A related paper catalogues design patterns that trade capability for security, among them plan-then-execute (fix the plan first) and dual LLM (one model handles untrusted text but has no tools, another has tools but never reads that text) (Beurer-Kellner et al., 2025). Gating sends alone leaves other outbound routes open, so every outbound route must be gated or removed.
The input is the threat model from step 3; the output is a design where an injected instruction hits a wall.
Step-by-step description
- A model with tools reads one stream of text.
- A web page can plant instructions.
- Private data is read; the dashed leak path to an outbound request completes the trifecta.
- An approval gate checks each send; the dashed route (a URL or image load) stays open until it is removed or gated too.
- An agent is a model plus tools reading one stream of text.
- Untrusted text such as a web page can reach the model.
- Private data plus an outbound channel plus untrusted content make a leak possible.
- Gating sends alone leaves other outbound routes open; every route must be gated or removed.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
| Example agent (illustrative) | Private data | Untrusted content | Outbound channel | Leak path |
|---|---|---|---|---|
| Public-web summariser, no stored data, no sending | No | Yes | No | No |
| Internal notes search, no web, no sending | Yes | No | No | No |
| Email assistant that reads mail and can send replies | Yes | Yes | Yes | Yes |
| Same assistant with sending, web requests, image loading and links turned off | Yes | Yes | No | No |
The last two rows differ by one capability. Turning off every outbound route (sending, web requests, image loading and links) removes the leak path while keeping every reading feature; turning off only a send button would not, which is why least privilege is a design decision before it is a configuration setting1.
Volume matters too. Suppose, as an illustration, that each untrusted input independently carries a working injection with probability 0.01. The chance that at least one of n inputs does is 1 − 0.99ⁿ: 0.0100 for 1 input, 0.0956 for 10, 0.3950 for 50 and 0.6340 for 1001. Real inputs are not independent and 0.01 is not a measured rate; the point is the shape, which is that an agent reading many pages cannot count on each one being clean.
Text description of the diagram
- With an illustrative chance of 0.01 per input, the chance of at least one working injection is 0.0956 for 10 inputs.
- It is 0.3950 for 50 inputs and 0.6340 for 100 inputs.
The AgentDojo benchmark offers measured results on its own terms: it pairs 97 realistic tasks with 629 security test cases, and its authors found that existing attacks break some security properties but not all (Debenedetti et al., 2024). Even without an attack, many state-of-the-art models fail many of its tasks.
Trade-offs and edge cases
No defence is free, and each one gives up something. Choose by what an attack could reach, not by how clever the filter is.
- Input filters and system prompts. Cheap and worth having, but an attacker can rephrase, so they reduce noise and do not close the hole. OWASP lists them among seven measures that mitigate impact, and says it is unclear whether any fool-proof prevention exists.
- Removing a capability. The strongest single move: no outbound route of any kind, no leak. The cost is a less capable agent.
- Human approval. Strong for irreversible actions; weak if people approve by habit. Show the exact action and its destination, not a summary.
- Architectural isolation (CaMeL-style). Gives provable security on the tasks it handles, with a reported drop from 84% to 77% task completion on one benchmark.
- Output validation. Forcing a strict schema, as in getting reliable structured output, stops free-form exfiltration (sending data out to an attacker) through text but not a leak through a permitted field.
- Edge case: tool descriptions. A tool's own description is text the model reads, so a third-party tool can carry an injection.
Text description of the diagram
- Input filters and system prompts are partial layers.
- Removing a capability closes the leak path at the cost of function.
- Approval stops irreversible actions if people read what they approve.
Add tracing so that an incident can be reconstructed; observability for language-model apps shows what to record.
How to answer it in an interview
How would you secure an agent that reads a user's email and can take actions?
The core risk is prompt injection: the model cannot reliably tell instructions from data, so text in an email can steer it. I start with the three capabilities that make a leak possible: private data, untrusted content and an outbound channel. Email gives it the first two, so I cut or gate the third, meaning every way data can leave: no free web requests, no image loading or clickable links, and approval before any send. Then least privilege on every tool, validated output formats, tracing, and adversarial tests. I would not rely on a guardrail prompt alone, because attackers can rephrase around it.
The spoken structure is: name the confusion, name the trifecta, remove or gate one leg, then add the supporting layers.
Common mistakes
- "A strong system prompt prevents injection" (wrong). Instructions in the system prompt and in the attacker's text sit in the same window and compete (right: use the prompt as one layer and limit what the agent can reach).
- "Prompt injection and jailbreak are the same thing" (wrong). A jailbreak targets the model's safety rules, while an indirect injection targets the agent's actions, though OWASP groups jailbreaking under prompt injection (right: say how they differ and that OWASP groups them).
- "Only the user can attack the agent" (wrong). Any web page, file or tool result the agent reads can carry the attack (right: treat every external text as untrusted).
- "Filtering the input solves it" (wrong). Filters can be rephrased around and cannot decide intent (right: add privilege limits and approval).
- "Security means a more capable model" (wrong). A smarter model still reads one stream of text (right: change the architecture, not only the model).
Follow-up questions
What is prompt injection?
Prompt injection is text in a model's input that changes its behaviour in ways its developer did not intend. It matters most for agents because they can act on what they read.
Prompt injection vs jailbreak?
A jailbreak tries to make the model ignore its safety rules; a prompt injection more broadly can steer any behaviour, including tool actions. Usage differs: OWASP (2025) describes jailbreaking as a form of prompt injection, while Willison (2024) separates them, since a jailbreak targets the model's safety training and prompt injection targets an application that mixes trusted and untrusted text.
Which prompt injection is used against agents?
Indirect prompt injection, in which instructions arrive inside content such as a web page or an email that the agent fetches, because the person using the agent never sees the attack.
When prompt injection failed, what did the defence look like?
An attack fails to leak data when the agent lacks one trifecta leg, for example when an approval step stops a message or no outbound channel exists. The defence is structural, not a better filter.
Can a better system prompt stop prompt injection?
No, not reliably; OWASP says it is unclear whether any fool-proof prevention exists. A system prompt is one layer, and the stronger layers are least privilege, approval and isolation. For neighbouring topics see agentic AI interview questions and AI engineer interview questions.
What if only 1 in 1,000 inputs carries an attack?
The chance that at least one of 100 inputs carries a working injection is 1 − 0.999¹⁰⁰ = 0.0952, about one in ten, so a rarer attack still reaches a busy agent. The probability is illustrative, not measured1.
- Prompt injection works because a model reads instructions and data as one stream of text.
- Indirect injection, through pages, files and tool results, is the form that matters for agents.
- A leak needs private data, untrusted content and any outbound route (message, URL, image, link) together; remove one fully.
- Limit reach with least privilege and approval; filters and system prompts are one layer, not a fix.
- Safer architectures cost some capability, and a good answer says so.
Sources
- Prompt Injection (2025 entry), OWASP Top 10 for Large Language Model Applications — OWASP Gen AI Security Project (page shows year only), 1 Jan 2025
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (arXiv 2302.12173 v2) — arXiv (Greshake et al.), 5 May 2023
- AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents (arXiv 2406.13352 v3) — arXiv (Debenedetti et al.), 24 Nov 2024
- Prompt injection and jailbreaking are not the same thing — Simon Willison's Weblog, 5 Mar 2024
- The lethal trifecta for AI agents: private data, untrusted content, and external communication — Simon Willison's Weblog, 16 Jun 2025
- Defeating Prompt Injections by Design (CaMeL), arXiv 2503.18813 v2 — arXiv (Debenedetti et al.), 24 Jun 2025
- Design Patterns for Securing LLM Agents against Prompt Injections, arXiv 2506.08837 v3 — arXiv (Beurer-Kellner et al.), 27 Jun 2025
