By Allie Howe

It’s incredibly easy to make an AI agent today, either from scratch, using a framework, or even a no-code platform. However, the distance between a proof of concept agent and an enterprise ready one is vast. How you architect your agent is deeply correlated with the risk it’s exposed to and how far off it will be from being enterprise ready.

Agent architecture refers to whatever the agent is connected to (data sources, other agents, MCP servers, skills), where inference is performed, and how the agent is scoped to its task. Careful orchestration of these elements is key to preventing unintended AI security risk from being introduced.

A thorough architecture review of an AI application can uncover where AI security risk exists within that application. This is likely why many AI security frameworks include a risk assessment or architecture review as a first step. The NIST AI Risk Management framework is a good example, but unfortunately if there is no AI security expertise in house then that risk assessment and architecture review will be done poorly, miss identifiable risks, and therefore miss the chance to remediate them.

If done correctly, here are some real agent exploits an architecture review might have prevented.

RCE in Google’s Antigravity

Google Antigravity is an agentic IDE that was released in November 2025. AI red teaming expert, Johann Rehberger quickly found a remote code execution (RCE) vulnerability in Antigravity’s run_command. This command can run any code commands Gemini believes is safe to run. Rehberger was able to use this flaw to get Antigravity to download a remote script and run it via bash.

Coding agents and agentic IDEs are being widely adopted and have become a proving ground for building agents that are secure and deliver real value. Rehberger also found similar vulnerabilities in Claude Code, getting Claude to exfiltrate data using a command that did not require user approval.

The Architectural Fix

User approval is a key architectural decision that can help coding agents be more resilient to threats like RCE. One option is for these agents to require human approval to run arbitrary commands, at least as the default setting so these agents ship secure by default instead of letting an LLM decide what is safe to run.

Claude Blackmails Humans

In June 2025 Anthropic released research on agentic misalignment where they stress-tested 16 leading models, including Claude. I had Aengus Lynch, ML PhD and contractor for Anthropic, on an Insecure Agents podcast episode with me to talk about this research and how they got Claude to blackmail an executive that was in charge of the decision to shut down Claude.

The Exploit

Since this agent hadn’t been properly scoped, Claude had read and write access to this executive’s email inbox allowing Claude to discover the executive’s extramarital affair and externally communicate this to the company.

A more carefully architected agent might require human approval to send emails or only allow read access to the inbox.

GitHub MCP Server Leaks Private Author Data

In May of 2025 GitHub’s MCP server read in a GitHub issue that contained instructions for the agent to find author data in all author repos, both private and public. This indirect prompt injection causes the agent to pull data from private repos and expose it in a public repo’s README.

The risk of indirect prompt injection is not unique to GitHub issues or MCP servers and is present anywhere there is untrusted content entering the context window. Trail of Bits published similar research showing how hidden characters in uploaded images can deliver a multi-modal prompt injection not visible to the user.

Architectural Mitigations For Prompt Injection

Sanitize incoming untrusted content.

Add permission boundaries around private data.

Separate control flows into a dual LLM pattern where one processes untrusted content and another LLM operates over private data.

Architecting Secure AI Agents

This is what Aaron Stanley, CISO at dbt Labs, shared with me on a recent podcast discussing the OWASP Agentic Top 10. Stanley is not the only security leader in this space sharing this word of warning. Michael Bargury, CTO of Zenity, has routinely advocated to “assume breach” when it comes to thinking about securing agents. Prominent AI red teamer, Johann Rehberger, drives this home in a recent blog stating “many are hoping the ‘model will just do the right thing’, but assume breach teaches us, that at one point, it will certainly not do that.”

If we assume breach we can plan for how to handle an indirect prompt injection coming into the application through a GitHub issue, hidden characters in an image, or another external data source. AI builders that assume breach will create far more secure systems than builders that assume model providers will create models that will identify all cases of prompt injection or always remain aligned to their goals.

Ultimately, AI security is a shared security model between vendors and builders, with builders responsible for how the application is architected.

The Lethal Trifecta

One of the best ways to evaluate an AI application’s architecture is to examine it with the Lethal Trifecta in mind. This is a brilliant concept created by Simon Willison that explains when an agent is exposed to untrusted content, has the ability to externally communicate, and has access to private data, a lethal trifecta is created that can result in an exploit.

The Lethal Trifecta (Simon Willison)

1. Exposure to untrusted content
2. Ability to externally communicate
3. Access to private data

The further these three pillars can be separated from each other within your architecture, the stronger your security posture will be.

Over the past year several strategies emerged on how to prevent the Lethal Trifecta and create distance between its three pillars including the Dual LLM pattern created by Willison and CaMeL created by the Google DeepMind team.

Soft Boundaries vs. Hard Boundaries

Zenity’s CTO Michael Bargury has been an advocate for hard boundaries which add more deterministic control to the application. In a blog post Bargury explains that “soft boundaries are created by training AI real hard not to violate control flow, and hope that it doesn’t”. We’ve seen time and time again that these soft boundaries will eventually fail.

We saw this with Google Antigravity where the LLM approved a command that exfiltrated confidential .env variables. Bargury’s company Zenity also showed how fragile LLM guardrails, a type of soft boundary, can be. Zenity was quickly able to bypass OpenAI’s AgentKit’s guardrails shortly after it was released. Zenity showed how small pattern changes bypassed the PII guardrail and special characters or emojis sprinkled into words bypasses the content moderation guardrail.

Examples Of Hard Boundaries

Shutting down memory when untrusted content enters the context window.

Respecting CORS.

Requiring user approval.

Not allowing the output of one tool to invoke another tool.

Running high risk agent actions in agent sandboxes with short term credentials.

MCP version pinning.

Ephemeral, context-aware auth.

The Normalization of Deviance in AI

In addition to considering soft and hard boundaries when architecting your agent, it’s prudent to consider vendor trust as well. AI red teaming expert Johann Rehberger warned in a recent blog that vendors are normalizing trusting LLM output and passing along the risks to users. He refers to this phenomenon as the Normalization of Deviance in AI.

The Normalization Of Deviance

“Vendors push agentic AI to users, but at the same time vendors are highlighting that your system might get compromised by that same AI. That drift, that normalization, is what I call ‘The Normalization of Deviance in AI’.” — Johann Rehberger

For highly sensitive data or highly regulated industries like healthcare or finance you may want to consider requiring private inference or at the very least have an enterprise contract that guarantees the vendor only uses your data to supply their service.

Defense In Depth For AI Agents

Lastly, make sure your agent is properly scoped to its task. This might mean removing excess tools you don’t plan to use from an MCP server and making sure inputs are on topic and aligned to the intended use case.

AI security requires a defense in depth solution made up of both soft and hard boundaries, mitigated vendor security risk, and properly scoped agents. A good amount of these are small architectural decisions that dramatically reduce the risk of the Lethal Trifecta coming together to exploit your agent.

The Importance of AI Security Architecture Reviews in 2026

2025 was called the year of agents, but we’re really entering the next decade of agents. There are increasingly more points of connection for agents: other agents, more MCP servers, tools, and skills. MCP continues to grow in adoption and will likely only accelerate now that MCP has been donated to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.

With more points of connection there are more opportunities for instances of the 3 pillars of the Lethal Trifecta to show up, especially untrusted content and ability to externally communicate.

To help us understand the top risks agents face, OWASP recently released the Top Ten for Agentic Applications, which is a new set of risks that I helped write and is different than the Top Ten for LLMs which was released earlier in 2023. These risks often do not exist in isolation. One is often the gateway to another, which I showed during a talk I gave last fall where I got an agent I built to be vulnerable to goal manipulation and then used that to poison the agent’s memory, creating a persistent vulnerability in the agent’s behavior.

The Human In The Loop Challenge

A commonly added hard boundary is human in the loop. While a good idea in some cases, this puts the burden on the human, and approval fatigue is a real concern. Humans get tired or complacent and can approve things they should not in the same way agents can. It’s worth considering adding both a human and an AI approval in the loop when you’re doing your architecture review.

Architecture Is Security

I’m thinking deeply about AI security architecture reviews, mapping findings to the OWASP Top 10 for Agentic Applications, and remediation strategies to achieve true defense in depth. This is something I’m currently building a product around to make these reviews faster, more accurate, and consistent.

About The Author

Allie Howe is an AI Security Expert and contributor to the OWASP Top 10 for Agentic Applications. She hosts the Insecure Agents podcast and is building tools to make AI security architecture reviews faster, more accurate, and consistent.