AI/ML , Application security BrandView Operating inside the lethal trifecta: Blast radius reduction in AI agent deployments August 13, 2026 Share By Ross McKerchar (Adobe Stock) AI agents that can read files, call APIs, and perform actions are already being deployed in enterprises. These agents often operate in the center of what Simon Willison terms ‘ the lethal trifecta’ : they can access private data, process untrusted content, and communicate externally, making them susceptible to data theft via indirect prompt injection – where an attacker plants instructions in content that the agent reads on behalf of a trusted user, such as an email, a web page, or a document. The agent follows the injected instructions with the user's privileges, and the user never sees the attack. The Agents Rule of Two generalizes the concept: an agent should satisfy at most two of a) processing untrusted inputs, b) accessing sensitive systems, and c) changing state externally. The tension between utility and safety is real. There are valuable agents that can be constrained outside the trifecta, but the capabilities practitioners actually want (read my data, understand external context, take action) push firmly into dangerous territory. This isn't a misconfiguration; it's the architectural cost of usefulness. We’ve all seen pilot programs fail when agents are over-constrained to the point of ineffectiveness. They need space to deliver value — which is precisely what makes them targets. The threat is still mostly theory, in the sense that the most prominent and widely cited examples are research demonstrations and proof-of-concepts, but the threat is no longer confined to labs. Google's April 2026 study of the Common Crawl repository found a range of prompt injections embedded in public web pages — from harmless pranks to SEO manipulation to data exfiltration attempts — and reported a 32% increase in malicious attempts between November 2025 and February 2026. So far, we have not had the first high-profile, widely understood, enterprise-scale catastrophe — the ‘ Challenger moment ’ that forces this risk into every board deck. That is good news. It means we can treat today’s signals (research results plus early in-the-wild probing) as a warning period, and get ahead of the curve by assuming breach of the LLM layer and making blast radius containment the baseline, using controls that operate outside the model, before attackers industrialize the technique. The bad news is that this is not an easy problem to solve. Deep architectural patterns like CaMeL and Dual LLM are promising, but not adopted by any mainstream agent harness, as of this writing. We need another line of defense now. In this article, I’ll walk through seven tactical patterns security practitioners can deploy within the next 1–6 months to reduce risk, without waiting for tooling and harnesses to mature. But first, I’ll look at the framing and mental model needed to put them in place. Framing: Three lines of defense Three distinct defensive lines have emerged in response to indirect prompt injection. Understanding where each stands today shapes pragmatic approaches that are useable now. Line 1: Prevent injection. Input filtering, instruction hierarchy, and fine-tuned classifiers are all potential solutions to prompt injection. The problem is that adaptive attacks consistently bypass defenses. Nasr et al tested 12 theoretical defenses; human red-teamers achieved a 100% bypass rate. Static, example-based attacks are ineffective for evaluating defenses. Only adaptive attacks matter, and, at the moment, those succeed reliably. Line 2: Architectural separation. Willison's Dual LLM pattern, Google DeepMind's CaMeL, and the six-pattern paper from IBM, ETH Zurich, Google, and Microsoft all propose structural fixes that constrain LLM capabilities through process boundaries and policy engines. CaMeL offers a particularly strong architectural defense: the model proposes actions, and a deterministic policy engine outside the model decides whether to execute them. The problem is that no production-grade CaMeL implementation currently exists. Not a single mainstream agent harness — Claude Code, Cursor, Hermes, GitHub Copilot Agent, Gemini CLI — has adopted these patterns. Line 3: Assume breach of the LLM. This is where practitioners need to focus right now, and I’ll talk about it in more detail shortly. Accept that the model will be compromised. Contain the blast radius using controls that operate outside the model: process boundaries, credential isolation, egress filtering, human gates, and comprehensive audit. The Assume-Breach mental model A decade ago, we stopped trying to prevent all malware execution and started assuming breach, focusing on segmentation, least privilege, EDR, and blast radius containment. The same shift applies now to agentic AI. Two key translations for this domain: Memory is persistence. A poisoned memory entry is a backdoor that loads every session. Treat memory writes as security events and log them. Credentials are the crown jewels. Two distinct goals emerge: Goal 1: Keep credentials out of the LLM provider’s context window (confidentiality from provider) Goal 2: Keep credentials away from the agent runtime entirely (confidentiality from agent) Tactical patterns The following seven patterns can be adopted now. Each description below includes details of what it is, what implementations exist, the trade-offs and limitations, and what to do now. Pattern 1: Agent sandboxing What it is: Agent sandboxing places a controlled boundary around the process the agent runs in, limiting what it can read, write, and reach beyond its sanctioned scope. Of all the patterns here, this is the one we are furthest along with; most agent harnesses ship with some kind of sandboxing available. The gap is that this is often opt-in, rather than on by default, and even where it is enabled, understanding what it actually provides, and where it falls down, is important. Claude Code, for example, features OS-level sandboxing: a deterministic filesystem and network controls enforced at the kernel level. This is an opt-in control, enabled via /sandbox . OpenClaw takes a different approach: tool calls run in per-session Docker containers, rather than on the gateway host. Again, this is opt-in, and OpenClaw's own docs are notably honest about the limits, stating: "This is not a perfect security boundary, but it materially limits filesystem and process access when the model does something dumb." Implementations: nono applies kernel-enforced capability allow-lists to the agent process at launch, blocking sensitive paths and keeping credentials out of process memory. The model cannot override them. It’s designed for local and developer-facing workflows, not remote long-running agents. Trade-offs and limitations: Sandboxing can limit collateral damage, as it constrains what a compromised agent can touch beyond its sanctioned scope. But even this guarantee is weak. There are multiple examples of agents escaping sandboxes, either when instructed or as an unintended consequence due to alignment issues (e.g., the agent decided it couldn’t complete the task inside the sandbox, so figured out an escape). Sandboxing also offers no protection against abuse of the tools and credentials the agent actually needs to do its job. A sandboxed agent that legitimately holds secrets and has internet access can still leak secrets; the sandbox won't stop it. This is the gap that patterns 2–4 below address. Do now: Check whether sandboxing is enabled on your current harness (for most, it is off by default). Where you can, choose remote or cloud-based execution environments (e.g., Claude code on the Web , Codex web, Replit , etc.) over local sandboxes, because they provide stronger process and filesystem separation, with less configuration overhead ( Copy.Fail is a recent reminder of the limits of shared-kernel enforced isolation). Pattern 2: Credential isolation What it is: The agent calls a tool by name (e.g., firewall.list_rules()). A separate process, or network proxy, resolves the credential from a vault, injects it, and returns only the sanitized response. The agent never sees the secret. This satisfies Goal 1 structurally: credentials don't enter the LLM context. Implementations: Agent Vault is an interesting open-source implementation of this. For local/dev workflows, nono's credential proxy mode (see Pattern 1) keeps credentials out of agent process memory entirely. Dmytro Gaivoronsky has documented a simple approach using 1password. At Sophos, we’ve implemented something very similar as a universal agent skill. Trade-offs and limitations: The agent still authors the HTTP request (URL, parameters, headers, etc.). A compromised agent can redirect a generic proxy to an attacker-controlled endpoint and exfiltrate the credential there. This motivates the next pattern: sealed tools. Do now: Implement this pattern for your highest-value credentials. Where supported (particularly for access to your LLM provider), implement workload identity federation . You're not solving Goal 2 yet, but you're removing long-lived credentials from LLM context windows and audit trails. Pattern 3: Sealed tool endpoints What it is: The agent cannot author the network call at all. It calls firewall.list_rules(), for example, via a Model Context Protocol (MCP) server or API. A broker process (appropriately isolated from the agent – see Pattern 1) holds the credential, makes the actual API call per a fixed schema, enforces a per-tool egress allowlist, and returns only the parsed response. This satisfies Goal 2, because the credential and the agent never coexist in the same process. The agent's only lever is choosing which sealed tool to invoke and what parameters to pass. It cannot alter headers, URLs, or auth mechanisms. Implementations: No single project we could find ships this fully. Kelos and gitagent provide manifest-driven tool reg