11. Agentic systems

An agent is an LLM in a loop with tools, memory and the authority to act. That turns prompt injection from “bad text” into “bad actions”: an agent is a confused deputy that reads untrusted content all day long. Agent security is therefore mostly about bounding authority and controlling data flow, not about perfecting the model.

Anatomy of an agent

A user gives a goal. The LLM plans, calls a tool (an API, a browser, a code runner, the file system, email), reads the result, and plans again. It may store notes in long-term memory, act under an identity with credentials, and hand work to other agents.

The crucial detail: every tool result re-enters the context as new, untrusted input. Each loop iteration is a fresh opportunity for injection. And unlike a chatbot, the agent can act on what it reads before any human sees it.

OWASP’s agentic guidance pairs two principles. Least privilege limits permissions. Least agency limits autonomy: if a task does not need an agent, do not build one, because unnecessary autonomy adds attack surface without adding value.

Two whiteboard tests: the lethal trifecta and the Rule of Two

The lethal trifecta (Simon Willison, 2025): an agent that has all three of

1. access to private data,
2. exposure to untrusted content, and
3. a way to communicate externally

can be tricked into stealing that data. Injected text arrives through leg 2 and uses leg 3 to send out leg 1. Any two legs are manageable; all three together are an exfiltration risk.

The Agents Rule of Two (Meta, 2025) generalizes this. Within a session, an agent should have at most two of: processing untrustworthy inputs; access to sensitive systems or private data; the ability to change state or communicate externally. If a task truly needs all three, a human must supervise.

Real incidents fit the pattern exactly. In 2025, a crafted email could make an enterprise copilot leak data from the victim’s context without any click (“EchoLeak”). In another case, a malicious issue in a public code repository instructed a connected coding agent to read the user’s private repositories and publish their contents publicly. One over-broad token covered both public and private repos. Both cases had all three legs.

Tools and the Model Context Protocol

A tool is described to the model by a name, a natural-language description and an input schema. Those descriptions go into the context - so tool descriptions are instructions too.

The Model Context Protocol (MCP) is an open standard for connecting agents to tool and data servers. Local MCP servers run as programs on your machine, with your user’s privileges. Remote servers are reached over HTTP and authorized with OAuth. Key risks:

• Tool poisoning - hidden instructions inside a tool’s description or its outputs.
• Rug pulls - a tool’s definition changes after you approved it (Part 2’s time-of-check to time-of-use).
• Shadowing and name collisions - one server’s tool impersonates or influences how another’s is used.
• Malicious or buggy servers - a local server is third-party code running as you; server implementations have had ordinary command-injection bugs.
• Token misuse - over-broad scopes, or a server passing the client’s token through to other APIs.
• Too many tools - every tool is attack surface the model can be talked into using.

Defenses: install servers only from sources you trust; pin versions and hash tool definitions, alerting on any change; give each tool its own narrow scopes; separate servers by trust level; and sandbox local servers. OWASP also maintains a dedicated MCP Top 10.

Identity and privilege for agents

• Give agents their own identities rather than borrowed user sessions or shared keys.
• Issue short-lived, task-scoped tokens, and re-check each privileged step with a policy engine.
• Keep signing keys and long-lived secrets out of the agent’s reach; let the orchestrator perform sensitive operations on its behalf.
• Watch delegation chains: when agent A calls agent B, authority must never grow along the chain.

Code execution, memory, multi-agent systems

Code execution. Generated code is untrusted, however helpful the model that wrote it. Run it per session in a sandbox (Part 2): never as root, network egress allowlisted, file access limited to a working directory. Separate generation from execution with a validation step, and ban eval in production agents.

Memory and context poisoning. Long-term memory and RAG stores let one injection persist across every later session. Validate writes before they are stored; isolate memory per user and tenant; record provenance; expire unverified entries; be able to roll back or quarantine; and never automatically feed an agent’s own outputs back into trusted memory.

Multi-agent systems. Messages between agents need ordinary distributed-systems security: mutual authentication, signatures, and replay protection. They also need semantic caution, because one agent’s output is another’s untrusted input. Faults can cascade faster than humans can review them, so add quotas, checkpoints and circuit breakers.

Humans in the loop

Human approval is a control only if the human can actually judge. Show the raw action - exact recipient, exact command, exact amount - not the agent’s friendly summary, which an attacker may have shaped. Ask too often and people rubber-stamp (Part 1’s psychological acceptability). Reserve approvals for high-impact, irreversible actions and enforce the rest with deterministic policy. Remember too that an agent can be used to persuade a human to perform the harmful step themselves.

Design patterns that hold up

A 2025 paper from researchers across several labs and companies, “Design Patterns for Securing LLM Agents against Prompt Injections”, collected patterns that trade some flexibility for limits you can reason about:

Pattern	Idea	Why it resists injection
Action-selector	The LLM only chooses from a fixed menu of actions; results are not fed back	Untrusted text never steers later steps
Plan-then-execute	The plan of tool calls is fixed before any untrusted content is read	Injection can alter data, not which tools run (arguments still need checks)
LLM map-reduce	Each untrusted item is processed in isolation into a constrained output, then aggregated	One bad document only affects its own small output
Dual LLM	A privileged LLM plans and calls tools but never sees untrusted text; a quarantined LLM reads it but has no tools	Untrusted text never meets authority
Code-then-execute	The LLM writes a program up front; untrusted data only flows through it as values	Control flow is fixed; policies can follow each value
Context minimization	Remove untrusted content from context once it is no longer needed	Less injected text survives into later steps

Google DeepMind’s CaMeL (2025) builds on the code-then-execute idea. It tracks where every value came from and enforces policies such as “data derived from an untrusted email may not be sent to a new address”. This is classical taint tracking applied to agents.

The big idea: move security out of the probabilistic model and into deterministic code around it - control-flow and data-flow policies that hold regardless of what the model believes.

The OWASP Top 10 for Agentic Applications

Published on 9 December 2025, this list complements the LLM Top 10 for systems that plan, use tools, keep memory and act (official resource; detailed summary).

ID	Risk	In one line
ASI01	Agent Goal Hijack	Inputs redirect the agent’s goals or plan (multi-step prompt injection)
ASI02	Tool Misuse and Exploitation	Legitimate tools used unsafely within granted privileges
ASI03	Identity and Privilege Abuse	Delegation, inherited credentials and cached tokens abused to escalate
ASI04	Agentic Supply Chain Vulnerabilities	Malicious or tampered tools, servers, models, prompts and agents
ASI05	Unexpected Code Execution	Generated or injected code runs on hosts or containers
ASI06	Memory & Context Poisoning	Stored memory or RAG data corrupted, persisting across sessions
ASI07	Insecure Inter-Agent Communication	Agent messages spoofed, intercepted or manipulated
ASI08	Cascading Failures	One fault spreads and amplifies across agents and workflows
ASI09	Human-Agent Trust Exploitation	Humans over-trust or are steered by agent output
ASI10	Rogue Agents	Agents drift or are compromised and act outside their scope

Questions to ask

• Does this agent combine private data, untrusted content and external communication? Which leg can we remove?
• What is the most damaging action it can take, and what deterministically stops it?
• Whose identity does it act under, how long do its credentials live, and what can they do?
• What enters its context from outside - tool outputs, documents, memory, other agents - and can any of it change the plan?
• Are tool definitions pinned, and would we notice if one changed?
• What exactly does a human approver see before a high-impact action?
• How do we stop it, revoke its access, and clean its memory if it goes wrong?