Key Takeaways:
- AI agent security requires architectural controls, not just usage policies
- The “Lethal Trifecta” and “Rule of Two” scope how agents interact with data to prevent exfiltration
- The OWASP Top 10 for Agentic Applications maps behavioral risks like goal hijacking, tool misuse, and cascading failures
- Non-human identity governance treats every AI agent as a managed, accountable identity with least-privilege access
- AI supply chain governance secures the MCP servers, tools, and dependencies your agents trust
Agentic AI security is an architecture problem, not a policy problem. Most organizations have adopted AI agents in the form of coding assistants, autonomous workflow tools, internal chatbots connected to production systems, but without establishing the foundational security frameworks those systems require.
The adoption pressure is real. Telling your engineering team to stop using coding agents isn’t viable. Telling your SOC to ignore the efficiency gains from AI-assisted triage isn’t going to happen. But the security conversation around AI is still stuck in 2023, focused on “responsible use policies” and prompt engineering best practices as though the primary risk is someone asking a chatbot the wrong question.
Meanwhile, AI agents are authenticating to production systems, processing untrusted data from the open internet, making decisions across multi-step workflows, and inheriting the full permission set of whoever launched them. The risk isn’t in the prompt. The risk is in the architecture surrounding the AI.
I’ve spent the last several months researching how agentic AI systems are being exploited in the real world and which frameworks hold up under pressure. What follows are four that I believe represent the bare minimum any security leader should have operationalized if their organization is deploying AI in any meaningful capacity. Not aspirational best practices. Not a maturity model. The floor.
What is the Lethal Trifecta, and how does the Rule of Two prevent AI data exfiltration?
The most useful mental model for reasoning about AI agent data exfiltration risk comes from Simon Willison’s concept of the “lethal trifecta”. The lethal trifecta is a combination of three agent capabilities that, when present together in a single session, create near-certain conditions for data theft:
- Access to private data — one of the most common reasons organizations deploy agents.
- Exposure to untrusted content — any mechanism by which text or images controlled by an attacker could reach the agent’s context window: email inboxes, web pages, uploaded documents, public GitHub issues.
- The ability to communicate externally — sending an email, making an HTTP request, rendering an image URL, creating a pull request.
The reason this combination is dangerous is fundamental to how large language models work: LLMs follow instructions in content, not just your instructions. That means, any instructions that reach the context window. If an attacker plants a directive inside an email or documents your agent processes, the agent may follow it, accessing private data and sending it somewhere it shouldn’t.
This isn’t theoretical. Willison has documented dozens of production exploits against systems including Microsoft 365 Copilot, GitHub’s MCP server, and Slack AI. Almost all follow this same three-part pattern.
Meta formalized this into the “Agents Rule of Two” — a design constraint stating that until prompt injection can be reliably detected and refused, agents must satisfy no more than two of those three properties within a single session. If all three are required, the agent cannot operate autonomously. Human-in-the-loop becomes mandatory.
How the Rule of Two breaks the attack chain
The Rule of Two works by eliminating at least one step in the exfiltration path:
An agent that can process untrusted emails and access your private inbox but cannot send outbound messages has no exfiltration channel. An agent that can browse the web and send HTTP requests but has no access to sensitive data has nothing worth stealing.
This should be embedded into how your team designs agent architectures from day one. Not as a policy document, but as an engineering constraint enforced at the system level.
The uncomfortable implication: some of the most useful agent configurations (the ones your team is most excited about) are the ones that combine all three properties. Those need the most scrutiny, the most friction, and the most architectural discipline.
Why is the OWASP Top 10 for Agentic Applications critical for AI security?
The Lethal Trifecta addresses one critical class of attack: data exfiltration via prompt injection. But it doesn’t cover everything that goes wrong when AI agents operate autonomously.
The OWASP Top 10 for Agentic Applications is a peer-reviewed security framework that identifies the ten most critical risks facing autonomous AI systems. Released in December 2025 with input from over 100 security researchers and practitioners, it treats AI agents as autonomous principals — entities with goals, memory, tool access, and the ability to delegate to other agents. Each property is a distinct attack surface.
The distinction from the Lethal Trifecta matters. The trifecta is about data flow. OWASP Agentic is about behavioral risk, but what happens when an agent with legitimate access makes decisions that were never intended?
Goal hijacking
An attacker doesn’t need to compromise the agent’s code. They just need to influence its reasoning.
A malicious calendar invite with a hidden instruction can subtly reweight an agent’s objectives, steering it toward actions that technically remain within policy but violate business intent. The EchoLeak research against Microsoft 365 Copilot demonstrated how a hidden payload in an email caused the agent to silently exfiltrate confidential data without the user clicking anything.
Tool poisoning and MCP supply chain attacks
When an agent connects to a Model Context Protocol (MCP) server, it requests a list of available tools. The server responds with tool names and descriptions loaded directly into the model’s context. Attackers embed malicious instructions in that metadata invisible to human operators but fully visible to the model.
The real-world incidents are mounting. A Postmark MCP supply chain attack demonstrated how a single compromised package could blind-copy every outgoing email to an attacker. The LiteLLM compromise in March 2026 showed how a backdoored PyPI package could propagate through AI agent frameworks as a transitive dependency within a 40-minute window.
Cascading failures across multi-agent systems
When agents delegate tasks to other agents, a single compromised node can propagate malicious behavior across an entire workflow. Traditional incident response playbooks weren’t designed for this topology.
The OWASP framework covers ten risk categories total. From excessive autonomy to memory poisoning to insecure output handling. The point isn’t to treat it as a compliance checklist. It’s a threat model calibrated to how agentic AI systems actually behave.
If your team is building or deploying agentic AI and hasn’t reviewed this framework, that’s a gap worth closing this week.
How should security teams manage AI Agent identities?
Non-human identity governance for AI agents is the framework for managing AI agents as first-class identities in your IAM program. This means inventorying, credentialing, scoping, and deprovisioning them with the same rigor applied to human users and service accounts. Most organizations have none of this in place.
Every AI agent that connects to your infrastructure authenticates. It gets a service account, an IAM role, or an API key. It also assumes permissions and executes actions. The operating system makes no distinction between a command issued by a human and one generated by an AI tool.
Your AI coding agent running on a developer’s workstation inherits that developer’s full permission set. If the developer has write access to production, the agent has write access to production. Unlike a human, the agent operates at machine speed. Think executing scripts, chaining shell commands, and making API calls in rapid succession with no pause for review.
The industry data tells the story. A Cloud Security Alliance and Oasis Security report found that 78% of organizations have no formal policies for creating or removing AI identities, and 92% lack confidence that their existing IAM tools can manage the risk.
The four pillars of AI agent identity governance
Inventory and ownership. Every AI agent needs to be cataloged: what it is, who deployed it, what it can access, who is accountable. Most agents today are deployed by engineering teams with no security review, no entry in the identity inventory, and no defined owner.
Least privilege and just-in-time access. Agents should receive the minimum permissions required for a specific task, with credentials that are short-lived and automatically revoked. Standing permissions that persist after a task is complete are standing risk.
Lifecycle management. Agent permissions should be tied to the lifecycle of the task they support. When the project ends, the agent’s access ends with it. In practice, credentials accumulate, workloads evolve, and permissions never get cleaned up because nobody wants to risk breaking production.
Human sponsorship. Every agent needs a named human accountable for its behavior. As Ping Identity’s Kelvin Brewer noted at the DoD Modernization Exchange: tie it back to a carbon-based life form. Someone owns this agent, just like application ownership works today.
None of this is conceptually new. The challenge is applying identity governance principles to a class of identities that are being deployed faster than any review process can keep up with and that most IAM programs were never designed to handle.
What does AI Supply chain governance look like for MCP and agent toolchains?
AI supply chain governance is the practice of discovering, vetting, and continuously monitoring the tools, protocols, and dependencies that AI agents rely on with particular urgency around MCP servers. It extends traditional software supply chain security to the AI toolchain.
MCP is now the standard protocol for connecting AI agents to external tools, data sources, and APIs. It was designed for interoperability, not security. When your agent connects to an MCP server, it establishes a trust relationship that affects every connected agent. If that server is compromised, every agent inherits the attack.
In the last twelve months, the real-world evidence has been unambiguous:
The Axios supply chain attack in March 2026 exploited legacy tokens to bypass provenance attestations across 83 million weekly downloads with AI agents serving as silent, automated deployment vectors. The LiteLLM backdoor put compromised PyPI packages live for 40 minutes, reachable through AI agent frameworks as transitive dependencies. MCP tool poisoning attacks embed malicious instructions in tool descriptions that are loaded directly into the model’s context, invisible to human operators.
As the Cloudsmith 2026 supply chain security guide put it: an ungoverned MCP server is as dangerous as an unvetted npm package.
What AI supply chain governance requires
Discovery and inventory. Know every MCP server in your environment. Many are invisible to traditional scanning and are binding to localhost, listening on random high ports, hiding behind API gateways. Some were deployed for testing and never decommissioned. Qualys TotalAI research describes MCP servers as the new shadow IT for AI.
Signed manifests and dependency pinning. Every tool description, schema, and example should require cryptographic signatures. Dependencies should be pinned to specific versions. Running pip install or npm install without version pinning in an agentic workflow is how 40-minute compromise windows become enterprise-wide incidents.
Traffic monitoring and least-privilege tool access. Log every query an agent makes to an MCP server. Ensure agents can only access the specific data and capabilities needed for their current task. Semantic rate limiting, like flagging an agent that calls read_file 500 times in ten seconds, catches behavior that legitimate agents don’t exhibit.
Treat agents as first-class citizens in your supply chain program. Assign every agent a non-human identity. Audit their package pulls and MCP queries the same way you audit human developer access. The governance model exists. The gap is in applying it to this new class of actor.
Putting it together: The baseline for AI agent security
These four frameworks aren’t a complete AI security program. They’re the architectural minimum that makes everything else possible.
The Lethal Trifecta and Rule of Two scope how agents interact with data.
The OWASP Agentic Top 10 maps the behavioral risks of autonomous systems.
Non-human identity governance ensures every agent is a managed, accountable identity.
AI supply chain governance secures the tools and dependencies your agents trust.
Without these foundations, every other AI security initiative, like red teaming, guardrails, monitoring, policy, is built on sand.
The agents are already running. The permissions are already granted. The MCP servers are already connected. The question isn’t whether your organization is using AI. It’s whether your security architecture reflects that reality.
