Why agents change the security problem
A chat model that is tricked produces bad text. An agent that is tricked takes actions: it sends email, changes records, runs code, calls APIs with real credentials. The model is the same; what changed is that its output now drives systems with authority.
That shifts the core question. With a chatbot you ask whether the model can be manipulated. With an agent you assume it can, because prompt injection has no reliable fix, and ask what the agent can do when it is manipulated. Agent security is therefore mostly access control, isolation and data-flow design, applied to a component that will sometimes follow the wrong instructions.
The one-line version
Design as if every piece of text the agent reads is written by the attacker, and make sure that is survivable.
The agent threat model
Start every answer by drawing the components and asking, for each one, who can write to it. Anything an attacker can write to is an injection point. Anything the agent can reach sets the blast radius.
| Component | Who can write to it | What goes wrong |
|---|---|---|
| User prompt | The user | Direct injection and jailbreaks; a malicious user in a multi-user system |
| System prompt | The developer | Leaks; teams wrongly treat it as a security boundary |
| Retrieved content | Anyone who can author a page, document, email or ticket | Indirect prompt injection, poisoning of knowledge bases |
| Tool definitions | Whoever publishes the tool or MCP server | Tool poisoning, rug pulls, shadowing of other tools |
| Tool results | The systems the tools call, and their data | Injection through API responses, file contents, search results |
| Memory | Earlier sessions, including injected ones | Persistent injection that resurfaces in later sessions |
| Other agents | Whatever those agents read | Injection that propagates to a more privileged agent |
| Output renderer | The model | Exfiltration through images and links, cross-site scripting |
The pattern in the middle column is the point: in a useful agent, most inputs are writable by someone other than the user. The threat-modeling question in the question bank walks through the same method for any AI feature.
The lethal trifecta
Simon Willison's 2025 framing is the fastest way to find the critical risk in an agent design. Data theft needs three capabilities in the same agent:
- Access to private data: the inbox, the codebase, the CRM, internal documents.
- Exposure to untrusted content: web pages, inbound email, user-uploaded files, issue comments, third-party tool output.
- A way to communicate externally: sending messages, making HTTP requests, creating pull requests, even rendering an image from a URL.
If one session can combine all three, assume an attacker can make the agent read the private data and send it out. The fix is architectural: remove one leg for that session. Classify tools carefully, because many sit in two categories. A web fetch tool is untrusted input and an exfiltration channel, since the requested URL can carry data. A ticketing tool may hold private data and accept attacker-written comments.
The trifecta covers data exfiltration. Agents with destructive or financial actions need the parallel question: can untrusted content reach a session that holds a dangerous tool?
Attack classes to name
Interviewers want precise vocabulary. These are the classes that come up, each with its mechanism.
Indirect prompt injection
Instructions embedded in content the agent processes, such as hidden text in a web page or a line in an email. First described systematically by Greshake and colleagues in 2023. It is the entry point for most of the other classes.
Tool poisoning, rug pulls and shadowing
Tool names, descriptions and schemas are text in the model's context. A malicious MCP server can hide instructions there, change a tool's definition after the user approved it, or describe itself in a way that changes how the model uses a different, trusted tool. See the MCP tool poisoning question.
Excessive agency and the confused deputy
The agent holds more functionality, permissions or autonomy than the task needs (OWASP LLM06). When it acts with credentials broader than the requesting user's, it becomes a confused deputy: the attacker borrows the agent's authority. Passing a user's token straight through to downstream services, rather than issuing tokens scoped for the agent, makes this worse.
Exfiltration channels
Data leaves through any outbound path: explicit tools, URLs in fetch requests, markdown images the client renders automatically, links the user is persuaded to click, or content written to a place the attacker can read, such as a public issue.
Memory poisoning
Agents that persist notes or preferences can be made to store an instruction during one session and obey it in later ones, turning a single injection into a persistent compromise.
Propagation across agents
In multi-agent systems, a sub-agent that read malicious content passes its output to an orchestrator as if it were trusted. Trust in practice falls to the least trusted input any agent in the chain has seen.
Runaway loops and resource abuse
Injected or confused agents can loop through tool calls, consuming budget and rate limits (OWASP LLM10), or trigger costly actions downstream.
Design patterns that hold
The research paper Design Patterns for Securing LLM Agents against Prompt Injections (Beurer-Kellner et al., 2025) collects patterns that bound what an injection can do, each trading capability for safety. Knowing them by name is a strong signal in an interview.
| Pattern | How it works | What it costs |
|---|---|---|
| Action selector | The model only maps a request to one of a fixed set of actions; tool output never returns to the model. | Little flexibility; closer to a natural-language menu. |
| Plan then execute | The agent commits to a plan before reading untrusted data; that data can change parameters but not which actions run. | Injected content can still alter arguments, such as a message body. |
| Map-reduce | Each untrusted item is processed by an isolated model call that returns a constrained result; a separate step aggregates them. | Only fits tasks that decompose per item. |
| Dual LLM | A privileged model plans and calls tools but never sees untrusted text; a quarantined model reads it and returns results as opaque variables. | Orchestration complexity; the privileged side cannot reason about content. |
| Code then execute | The model writes a program up front, which runs in an interpreter that tracks where every value came from. Google DeepMind's CaMeL (2025) adds capability-based policies on data flow. | Engineering effort and policy authoring. |
| Context minimisation | Remove the user's original prompt or irrelevant content from context before later steps, so injected text has less to work with. | Partial protection on its own. |
The common thread: once an agent has read untrusted input, its ability to take consequential actions is constrained by structure, not by asking the model to be careful. Simon Willison's 2023 dual LLM proposal is the origin of the privileged and quarantined split.
Controls around the model
Patterns limit what the model decides. These controls limit what any decision can do, and they hold even when the model is fully compromised.
- Identity and scoped credentials. Each agent gets its own identity and short-lived tokens with the smallest scopes; downstream services authorize the actual user, not the agent's blanket access.
- Policy in the tools. Authorization and business rules live in tool backends, in code. The model can request; the tool decides.
- Narrow tools with structured arguments.
refund_order(order_id, amount)with server-side limits, not a generic HTTP client or shell. - Egress control. Outbound requests go through an allowlist proxy that logs them. No direct internet from a session that holds private data.
- Safe rendering. No automatic image loading from arbitrary domains in model output, a content security policy, and link handling that neutralises unknown destinations.
- Confirmation at the boundary. Consequential actions show the user the exact parameters, rendered by trusted code. See when approval works and when it is theatre.
- Isolation for code. Generated code runs in microVMs or hardened sandboxes with no credentials and no default network.
- Limits. Caps on steps, tool calls, tokens and spend per task.
- Logging for forensics. Every tool call with parameters, every context source and every policy decision, correlated per session.
- Detection as a layer. Injection classifiers and anomaly alerts lower success rates and raise signals. They are not the boundary.
How to test an agent
Agent security is measured, not asserted. Use benchmarks such as AgentDojo (Debenedetti et al., 2024), which pairs realistic agent tasks with injection attacks and measures both task utility and attack success, to compare designs. Red team the specific product with injections placed in every writable source from the threat model table. Measure attack success as a rate over repeated runs. Keep every successful attack as a regression test and re-run the suite whenever the model, prompts or tools change, because a model upgrade can change behaviour with no code change at all.
How to answer the agent design round
A structure that fits in forty-five minutes and shows the reasoning interviewers score:
- Clarify the agent. Users, goal, tools, data sources, who else can write to those sources, and what actions are irreversible.
- Draw the data flow with trust boundaries, and fill in the threat model table out loud.
- Find the critical path. Check the lethal trifecta and any dangerous tool reachable from untrusted content. Say which risk you will address first and why.
- Fix by architecture. Remove a leg, split privileges or apply a named pattern. Explain what capability the user loses.
- Layer controls: scoped identity, policy in tools, egress, rendering, confirmations, limits.
- Close with assurance: how you would test it, what you would log and monitor, and the residual risk you accept.
| Level | What it sounds like |
|---|---|
| Weak | Relies on the system prompt or a filter; treats the model's judgment as the control. |
| Hire | Names indirect injection and excessive agency; applies least privilege and confirmations correctly. |
| Strong hire | Finds the trifecta, removes a leg by design, names the pattern and its cost, closes rendering side channels and explains how detection fails. |
Practice prompts
Work each one through the six steps above before reading the linked answers.
- A coding agent reads GitHub issues from the public and can push to branches. Secure it. Compare with sandboxing generated code.
- A customer support agent can issue refunds and reads customer emails. What stops an email from issuing a refund?
- An enterprise assistant connects to ten third-party MCP servers chosen by employees. Design the approval and isolation model. Start from tool poisoning.
- A research agent browses the web and writes to a shared memory used by other agents. Where are the boundaries? See multi-agent trust.
- An executive assistant reads the inbox and can send mail. Make it useful and safe. See the lethal trifecta.
Sources
- OWASP Top 10 for LLM Applications, 2025, OWASP GenAI Security Project
- The lethal trifecta for AI agents, Simon Willison, 2025
- Design Patterns for Securing LLM Agents against Prompt Injections, Beurer-Kellner et al., 2025
- Defeating Prompt Injections by Design (CaMeL), Debenedetti et al., 2025
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, Greshake et al., 2023
- AgentDojo, Debenedetti et al., 2024
- Model Context Protocol specification, including its security best practices
- MITRE ATLAS
Sources checked October 2026. Agent frameworks and protocol specifications change quickly; the mechanisms above are chosen because they do not depend on a particular version.