Agent Security

An agent turns text into actions, so any text that reaches its context - a web page, an email, a tool result, a document, another agent's message - can try to steer those actions. Agent security is the discipline of limiting what a successfully manipulated agent can do: least privilege, isolation of untrusted content, architectures that keep untrusted data out of control flow, policy enforced in code, sandboxes, and human approval.

The Core Problem

A model processes instructions and data in the same token stream and cannot reliably tell them apart. Direct prompt injection comes from the user; indirect prompt injection arrives in content the agent reads while working - the attacker never talks to the agent at all. Models are trained to resist injection and the resistance keeps improving, but it is statistical: the MCP lab measured a local model ignoring an injected instruction in a tool description 30 times out of 30 and obeying the same instruction in a tool result 7 times out of 30. Adaptive attackers search for the phrasing that works. So design as if injection will sometimes succeed, and limit what success can do.

The Lethal Trifecta

Simon Willison's test (June 2025): an agent can be made to exfiltrate data when it has all three of

1. access to private data,
2. exposure to untrusted content, and
3. a way to communicate externally (send email, make web requests, write to a public place - even rendering an image URL).

flowchart LR
    P["🔒 Private data"] --- A["🤖 Agent"]
    U["☠️ Untrusted content"] --- A
    A --- E["📤 External<br/>communication"]
    A -->|"all three = exfiltration path"| X["⚠️"]

    style P fill:#d8dfe8,stroke:#b0bac8
    style U fill:#e8e0d4,stroke:#c8b89a
    style E fill:#ddd8e4,stroke:#b8b0c8

The fix is structural: remove one leg for each context. A research sub-agent reads the web but has no private data and no send tool; the agent with private data never sees raw untrusted content; sending requires approval with the exact content shown, or only goes to allowlisted destinations. Scoping also counts: a token for one repository instead of all of them shrinks "private data" to what the task needs.

OWASP Top 10 for Agentic Applications (2026)

Published by the OWASP GenAI Security Project in December 2025, the list names the risks specific to agents that plan, remember, use tools and act with delegated authority:

It complements the OWASP Top 10 for LLM Applications (prompt injection, sensitive information disclosure, excessive agency and so on), which still applies to the model inside the agent.

Design Patterns That Resist Injection

Beurer-Kellner et al. (2025) describe six patterns that give provable resistance by constraining what untrusted data can influence - each trades some flexibility for security:

CaMeL reported solving 77% of AgentDojo tasks with provable security, against 84% for the undefended system - a small utility cost for a guarantee rather than a probability.

Sandboxing and Credentials

For agents that run code, use a browser or touch a file system:

• Sandbox every execution: containers with seccomp profiles, gVisor, or microVMs (Firecracker); no host mounts beyond a scratch workspace; CPU, memory and time limits.
• Network egress through an allowlisting proxy; block cloud metadata endpoints; log destinations.
• No long-lived secrets in the sandbox: inject credentials at the egress proxy or tool layer so the agent (and any injected instruction) never sees them.
• Per-user, short-lived, scoped credentials for every tool (OAuth token exchange, audience-bound tokens - see MCP Authorization); the agent should never hold more authority than the user it acts for.
• Confirmation for destructive or externally visible actions, showing exact arguments.

Guardrails and Monitoring

Input and output classifiers (injection detectors, PII and secrets scanners, topic filters) are useful filters and cheap telemetry, but they are probabilistic in the same way as the model and should never be the only control. Place them where they are cheap to be wrong (flag and log) and put deterministic controls where being wrong is expensive. Monitor tool calls for anomalies - new destinations, unusual volumes, first-time actions - and keep a kill switch per agent and per tenant. Red-team continuously with benchmarks such as AgentDojo and with your own injected content, and add every successful attack to the regression suite.

Check Yourself

Exercises

Study Notes

• Injection: direct and indirect; model resistance helps but is statistical - limit the blast radius
• Lethal trifecta: private data + untrusted content + external communication; remove one leg per context
• OWASP Agentic Top 10 (Dec 2025): goal hijack, tool misuse, identity/privilege, supply chain, code execution, memory poisoning, inter-agent comms, cascading failures, human trust, rogue agents
• Patterns: action-selector, plan-then-execute, map-reduce, dual LLM, code-then-execute (CaMeL), context minimisation
• Sandboxes, egress allowlists, no secrets in the sandbox, per-user scoped credentials, approvals
• Classifiers are telemetry and filters, not guarantees; monitor, kill switch, red-team continuously

References

• Simon Willison, The lethal trifecta for AI agents (Jun 2025) and The Dual LLM pattern (Apr 2023)
• OWASP GenAI Security Project, Top 10 for Agentic Applications for 2026 (Dec 2025)
• Beurer-Kellner et al., Design Patterns for Securing LLM Agents against Prompt Injections (2025)
• Debenedetti et al., Defeating Prompt Injections by Design (CaMeL) (2025)
• Debenedetti et al., AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents (2024)
• Greshake et al., Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (2023)

Last reviewed: 2026-09