The short version: the AI-agent security feature you reach for first should not be a smarter content filter. It should be a deterministic authorization layer that sits outside the model — a per-session tool allowlist, scoped and short-lived credentials, egress control, and human approval on anything destructive. Filters (Llama Guard, NeMo Guardrails, Lakera) are worth running, but as noise reduction, not as a security boundary — because the one thing every headline agent breach has in common is that it walked straight through the filter. If you remember one sentence: you cannot prompt your way out of prompt injection. The rest of this is why, and the exact features to turn on.
The breach that proves the point#
In 2025, Aim Labs disclosed EchoLeak — tracked as CVE-2025-32711, rated CVSS 9.3. It let an attacker exfiltrate data from Microsoft 365 Copilot with zero clicks: a crafted email sits in the inbox, Copilot pulls it into its retrieval context while answering some unrelated question, and the attacker's instructions in that email steer Copilot into leaking private data out through a Markdown link. No user ever clicked anything.
The detail that matters for your architecture: the exploit bypassed Microsoft's own prompt-injection classifier (XPIA), its link redaction, and its content-security policy. Microsoft is not a small shop with a naïve filter. They had the classifier. It did not hold, because a probabilistic text filter is being asked to separate "instructions" from "data" in a channel where the whole point is that the model reads untrusted content as part of its job.
A content filter guesses whether text is dangerous. An authorization layer decides whether an action is allowed. Only one of those is a security boundary.
Simon Willison named the underlying shape the lethal trifecta: any agent that has access to private data, exposure to untrusted content, and a way to send data externally can be turned against its user. EchoLeak is just that trifecta with the serial numbers filed off. And it is not specific to Copilot — it is the default shape of almost every useful agent you will build.
Map the features to the real failure classes#
The reference list for what actually goes wrong is the OWASP Top 10 for Agentic Applications (2026 edition): ten risk classes from ASI01 Agent Goal Hijack to ASI10 Rogue Agents. Read it and a pattern jumps out — the most-reported real-world failures (goal hijack, and especially ASI03 Identity & Privilege Abuse, where agents inherit user sessions and tokens they should never hold) are authorization problems. They are not solved by a better prompt or a stricter classifier. They are solved by giving the agent less power.
So the security features worth your time are the ones that reduce power deterministically. The "At a glance" matrix on this page lays out the decision: the first row — the content filter — is the control the market sells hardest, and the one that keeps failing. Build from the rows below it up.
Turn these on, in this order#
- Least-privilege tool allowlist. Per session, the agent may call only the tools that task needs. If a refund tool isn't on the list, no injection can invoke it. This is the single highest-leverage control, and it maps directly onto MCP tool annotations — know which of your tools are read-only and which are destructive before you grant them.
- Scoped, short-lived credentials. Give the agent its own identity with narrow, expiring tokens — never a human's inherited session or a long-lived API key. This is the direct fix for ASI03, and it caps the blast radius when (not if) something gets hijacked.
- Egress / network control. Break the lethal trifecta's exfiltration leg. If the agent must read untrusted content, restrict where it — and any sandbox it runs code in — can send data.
- Human-in-the-loop on destructive actions. A person confirms anything irreversible. Keep the list short so approvals stay meaningful instead of becoming a reflexive "yes."
- Sandboxed execution. Run agent-generated and tool code in an isolated microVM or container — the same discipline we covered in how to run untrusted agent code, and the reason Perplexity's newly open-sourced SPACE sandbox is worth a look.
Two more, cheaply: scan your MCP servers. Tool-description poisoning is real — hidden instructions in a tool's description that the model reads and the user never sees — so run Invariant's mcp-scan (uvx mcp-scan@latest) and pin tool definitions by hash to catch a silent "rug pull." And keep the classifiers — OpenAI's Agents SDK guardrails and NVIDIA NeMo Guardrails are genuinely useful — just file them under hygiene, not under your security model.
Why this is suddenly a conference circuit#
Agent security has matured from a conference track into its own events: Zenity's AI Agent Security Summit runs its New York edition at Pier Sixty on October 21, after London on the 8th. That arc — from a novelty talk to a dedicated summit in roughly a year — tells you the same thing the OWASP list does: shipping an agent is now shipping a system that acts with real privilege on untrusted input, and the industry has stopped pretending a filter is enough. Build like you believe that. Treat the agent as an untrusted user, and put your trust in the controls it can't talk its way around.
This piece draws on public disclosures and framework documentation (OWASP's Agentic Top 10, the EchoLeak/CVE-2025-32711 reporting, Invariant Labs' MCP research) summarized from release coverage and primary pages; OWASP's framework text is licensed CC BY-SA 4.0, so check genai.owasp.org for authoritative wording. We deliberately leave out several dramatic, still-unconfirmed 2026 agent-breach claims circulating in secondary aggregators until they're corroborated by primary sources.
