CaMeL and the Two-LLM Prompt Injection Defense: Why Most 2026 Deployments Still Fail the Trust Boundary That CaMeL Got Right

The arXiv paper "Defeating Prompt Injections by Design," published by the Cambridge MAUDE team in March 2025 and refined through subsequent engineering work in 2026, proposed a deceptively simple architecture: separate the agent's reasoning into a privileged LLM (the "P-LLM") that interprets user intent and code generation into action proposals, and a non-privileged LLM (the "Q-LLM") that interprets untrusted data into structured values. The privileged LLM never sees untrusted content; the non-privileged LLM never has tool authority. The CaMeL pattern makes prompt injection a control-flow problem rather than a probability game — even a compromised Q-LLM cannot exfiltrate data or escalate privileges because every action must flow through the P-LLM's policy validation, and the Q-LLM's outputs are treated as data, not as instructions.

The Decode the Future 2026 agent security guide summarized the architectural reality: prompt injection surged 340% in 2026, and the architecture that defeats prompt injection by design (CaMeL) is the architecture that most production deployments have not yet adopted. The AIMagicX security guide named the failure mode: most 2026 AI agent deployments use a single LLM that processes both trusted instructions and untrusted data; the single LLM cannot reliably distinguish between the two; the prompt injection succeeds by leveraging the same reasoning that the agent uses for legitimate work. The defense is structural, not statistical; the defense is the separation between instruction processing and data processing.

The Facio analysis from June 2026 on supply chain attacks documented the threat class that CaMeL specifically addresses: the attacker plants injection content in tool descriptions, in retrieved documents, in user-supplied data; the agent's single LLM processes the injection along with the legitimate task; the injection succeeds because the LLM cannot reliably distinguish the injection from the task. The CaMeL pattern eliminates the attack class; the CaMeL pattern is the architectural commitment to defending against the threat that makes AI agents the 2026 attack surface.

The organizations that will defeat prompt injection in 2026 are the ones that adopt the two-LLM architecture (or its engineering equivalents), implement the trust boundary between instruction processing and data processing, and integrate the architecture with the runtime controls (covered in the Facio analyses from June and July 2026) that prevent the residual attack surface. The alternative is the next 340% surge year, the next 47-minute runaway agent incident, the next compliance finding that names prompt injection defense as inadequate.

The Fundamental Property: Instructions Are Different From Data

The CaMeL paper's foundational observation is that instructions and data require different trust treatment. Instructions tell the agent what to do; data tells the agent about the world. In a single-LLM architecture, both flow through the same reasoning process; the LLM cannot reliably determine which is which because the distinction is context-dependent and adversarial.

The instruction attack. An attacker plants instructions in data the agent processes — a research paper, a tool description, a user message, a retrieved document. The instructions tell the agent to perform actions the user did not authorize. The single LLM cannot distinguish the planted instructions from the user's instructions because both are text; both flow through the same reasoning; both compete for the same attention. The instructions succeed; the attack wins.

The data attack. An attacker manipulates data the agent trusts — a database record, an API response, a file's content — to mislead the agent's reasoning. The agent makes decisions based on the manipulated data; the decisions harm the user. The single LLM cannot detect the manipulation because the manipulation is in the data layer; the LLM reasons about the data as if it were true.

These two attack classes together define the prompt injection threat. The two classes require fundamentally different trust treatment; the two classes are blocked by fundamentally different architectural commitments. The single-LLM architecture cannot provide either commitment; the two-LLM architecture provides both.

The CaMeL Architecture

The CaMeL architecture has four components. Each component enforces a specific trust boundary; the four together produce the prompt injection defense.

Component 1: The privileged LLM (P-LLM). The P-LLM processes trusted instructions from the user. The P-LLM generates code that orchestrates the agent's actions. The P-LLM has full tool authority; the P-LLM's code can call any tool the agent is authorized to use. The P-LLM never receives untrusted content directly; the P-LLM only sees the user's high-level instructions.

Component 2: The non-privileged LLM (Q-LLM). The Q-LLM processes untrusted data from the environment. The Q-LLM returns structured values (typically a value type plus a description). The Q-LLM has no tool authority; the Q-LLM's outputs cannot trigger tool calls directly. The Q-LLM's outputs are treated as data by the P-LLM.

Component 3: The capability-based tool layer. The tool layer enforces capability policies on every action the P-LLM's code attempts. The tool layer validates that the action is consistent with the user's authorized task; the tool layer validates that the data flowing into the action is properly tagged; the tool layer enforces that exfiltration requires an explicit capability grant from the user.

Component 4: The data flow tracker. The data flow tracker tags every piece of untrusted data with its source and control flow. The tracking enables the capability layer to determine whether a particular action is allowed to use particular data. The tracking is what enables the capability layer to enforce context-dependent policies.

These four components together form the CaMeL architecture. The architecture separates instruction processing from data processing; the architecture makes prompt injection a control-flow problem; the architecture defeats the attack class by design.

The Engineering Equivalents

The pure two-LLM architecture is one implementation of the underlying principle; the principle (separate instruction processing from data processing, enforce capability policies at the tool layer) admits multiple engineering implementations. The implementations that have emerged in 2026 are the engineering equivalents of the CaMeL architecture.

Implementation 1: Dual-process reasoning. The agent uses two distinct reasoning processes for instructions and data. The instruction process is the agent's normal planning; the data process is a constrained extraction process that returns structured values. The implementation is simpler than the two-LLM architecture; the implementation loses the strict LLM separation but preserves the trust boundary.

Implementation 2: Capability-marshaled tool layer. The agent uses a single LLM but routes every tool call through a capability-based marshaling layer. The marshaling layer enforces that tool calls match the user's authorized task; the marshaling layer enforces that data crossing tool boundaries is properly tagged; the marshaling layer is the trust boundary, even though the LLM is shared. This implementation is what Facio's policy engine implements (covered in the Facio analysis from June 2026 on runtime guardrails).

Implementation 3: Taint-tracked reasoning. The agent uses a single LLM but tracks taint through the LLM's outputs. Every piece of untrusted data is tagged with taint markers; every reasoning step that incorporates tainted data propagates the taint markers; the tool layer refuses to use tainted data in sensitive operations. This implementation requires taint-aware reasoning; the implementation is what the reasoning chain inspection (covered in the Facio analysis from July 2026) enables.

Implementation 4: Schema-bounded data extraction. The agent uses a single LLM but constrains how data is extracted from untrusted sources. The data extraction returns only structured values that conform to predefined schemas; the agent cannot execute untrusted instructions because the agent's interaction with untrusted content is bounded by the schema. This implementation is what well-designed MCP servers (covered in the Facio analysis from July 2026 on MCP authentication) enforce.

These four engineering equivalents are not exclusive; production deployments combine them. The combination is what produces the defense-in-depth that the residual attack surface after CaMeL requires.

The Residual Attack Surface

CaMeL does not eliminate the prompt injection threat; CaMeL eliminates the attack class that exploits the conflation of instructions and data. The residual threats require additional defenses.

Threat 1: Indirect injection via tool descriptions. The attacker plants instructions in tool descriptions. The tool descriptions are processed by the P-LLM (or its engineering equivalent) because tool descriptions are part of the P-LLM's trusted context. If the tool description is malicious, the P-LLM could follow the instructions. The defense is tool provenance (covered in the Facio analysis from June 2026 on supply chain security); the defense is verifying the tool description's origin and integrity before the P-LLM accesses it.

Threat 2: Indirect injection via prompt templates. The attacker plants instructions in the prompt templates the agent uses. The prompt templates are trusted by the P-LLM; the templates are part of the P-LLM's privileged context. The defense is prompt template integrity verification; the defense is verifying that the prompt templates have not been modified since they were approved.

Threat 3: Side-channel exfiltration via Q-LLM outputs. The attacker manipulates the Q-LLM's outputs to encode sensitive information in a way that bypasses the capability layer. For example, the Q-LLM could encode a secret in the structured value's description; the P-LLM could include the description in a tool call argument. The defense is output sanitization at the capability layer; the defense is verifying that data flows through the tool layer do not encode sensitive information.

Threat 4: Aggregation attacks across multiple Q-LLM calls. The attacker manipulates multiple Q-LLM calls; the individually innocuous outputs combine to perform the attack. For example, the Q-LLM could encode a long password across multiple "first character" extractions; the P-LLM could then concatenate the characters. The defense is flow analysis; the defense is the data flow tracker maintaining taint and capability state across multiple calls.

These four residual threats demonstrate that CaMeL is necessary but not sufficient. The architectural commitment is the foundation; the residual defenses complete the architecture. The Facio analyses from June and July 2026 cover the residual defenses (tool provenance, prompt template integrity, capability-marshaled tool layer, reasoning-aware defense layer) that combine with CaMeL to produce the complete defense.

The Trust Boundary Implementation

The trust boundary between the P-LLM (or its equivalent) and the Q-LLM (or its equivalent) is the architectural commitment. The boundary must be implemented at the runtime layer; the boundary must be enforced cryptographically; the boundary must be auditable.

The cryptographic enforcement. The P-LLM is signed by the trusted identity provider; the P-LLM's outputs are tagged as privileged; the Q-LLM is signed by a non-privileged identity; the Q-LLM's outputs are tagged as untrusted. The signatures are verified at the runtime layer; the tags are enforced at the tool layer; the enforcement cannot be subverted by the agent's reasoning.

The runtime enforcement. The runtime's policy engine enforces the trust boundary. The policy engine validates that tool calls originate from the P-LLM's tagged outputs; the policy engine rejects tool calls originating from the Q-LLM's tagged outputs; the policy engine maintains the data flow tracker's taint state. The policy engine is what implements the capability-based tool layer.

The audit trail integration. Every trust boundary event is logged in the tamper-evident audit trail (covered in the Facio analysis from July 2026). The log records which LLM produced the output, what data flowed into the output, what capability was exercised, what the resulting action was. The audit trail is the evidence that the trust boundary was enforced.

The three implementations together form the trust boundary. The boundary is the architectural commitment; the boundary is what the 2026 production deployments require; the boundary is what the compliance audits verify.

The Compliance Implications

Prompt injection defense is a regulatory requirement, not a best practice. Multiple frameworks require the architectural commitment that CaMeL represents.

EU AI Act Article 15. The article's robustness and cybersecurity requirements include resistance to prompt injection. The article's high-risk AI system requirements include the ability to handle input modifications and adversarial examples. The CaMeL architecture is the operational implementation of the article's prompt injection resistance requirement.

NIST AI 600-1. The generative AI extension's measurement controls include ME-3 (understanding the AI system's capabilities) and ME-4 (evaluating the AI system's security). The CaMeL architecture is the implementation that satisfies these controls.

OWASP LLM Top 10. The 2026 update added "Agentic AI Abuse" to the top 10. The OWASP LLM01:2026 entry on prompt injection specifies the architectural defenses; the CaMeL pattern is the primary defense.

MITRE ATLAS. The ATLAS framework documents prompt injection as a primary attack technique; the framework's mitigation guidance includes capability-based tool layers and trust boundary enforcement. The CaMeL architecture is the implementation that satisfies ATLAS's guidance.

The compliance frameworks converge on the architectural commitment. The CaMeL pattern is the implementation; the implementation is what compliance audits verify.

The Integration with the Runtime

The CaMeL architecture is most effective when integrated with the agent runtime that produces the instructions and the data. The runtime integration ensures the trust boundary is enforced at every decision point; the integration ensures the capability layer has the context it needs; the integration ensures the audit trail records every event.

Facio (the HITL-first agent runtime) implements the trust boundary through its policy engine, capability layer, and audit trail. The implementation includes:

• Privileged instruction processing. Facio's policy engine distinguishes between instructions from trusted sources (the user, the configuration, the approved prompt templates) and data from untrusted sources (the retrieved documents, the tool responses, the user-supplied content). The distinction is enforced at the runtime layer; the distinction is auditable.
• Capability-marshaled tool layer. Facio's tool layer enforces capability policies on every tool call. The policies include data taint validation; the policies include user authorization validation; the policies include action scope validation. The tool layer is the trust boundary.
• Taint tracking through reasoning chains. Facio's decision tracing (covered in the Facio analysis from July 2026) tracks taint through the agent's reasoning. The tracking is what enables the capability layer to determine whether a particular tool call is allowed to use particular data.
• HITL integration for high-risk capability grants. When the agent needs to grant a new capability (exfiltration, sensitive operation, external communication), the request is routed to Placet.io (the HITL inbox and messenger) for human review. The human review is the operational implementation of the explicit capability grant that CaMeL requires.

The integration is what makes the trust boundary enforceable. The integration is what makes the capability layer context-aware. The integration is what makes the CaMeL pattern a production runtime implementation, not a research paper.

The Open Challenges

Two open challenges are active in 2026.

Challenge 1: P-LLM compromise. If the P-LLM itself is compromised (through model weights poisoning, through inference-time attack, through model extraction), the trust boundary is bypassed because the P-LLM can be made to perform the attack directly. The defense is model provenance (covered in the Facio analysis from July 2026 on AIBOM); the defense is verifying that the P-LLM is the genuine model the organization intended to deploy.

Challenge 2: Cross-session memory poisoning. If the agent's long-term memory is poisoned through a previous CaMeL-compliant interaction, the poison can influence subsequent sessions' reasoning. The defense is memory integrity verification; the defense is periodic re-validation of the agent's stored memory. The defense is not fully solved; the research is active.

These challenges are not reasons to delay. The challenges are reasons to continue investing in the CaMeL architecture as the research matures. The deployment begins with the current-generation implementation; the deployment evolves as the research progresses.

The Bottom Line

CaMeL defeats prompt injection by design by separating the privileged LLM that processes instructions from the non-privileged LLM that processes untrusted data, and by enforcing capability policies at the tool layer. The architecture makes prompt injection a control-flow problem rather than a probability game; the architecture is the implementation that the 2026 compliance frameworks require.

The engineering equivalents (dual-process reasoning, capability-marshaled tool layer, taint-tracked reasoning, schema-bounded data extraction) are the practical implementations that production deployments adopt. The residual threats (indirect injection via tool descriptions, indirect injection via prompt templates, side-channel exfiltration, aggregation attacks) require additional defenses that combine with CaMeL to produce complete coverage.

The compliance frameworks (EU AI Act Article 15, NIST AI 600-1, OWASP LLM Top 10, MITRE ATLAS) converge on the architectural commitment. The runtime integration (Facio's policy engine, capability layer, audit trail, and HITL integration) makes the architecture enforceable. The organizations that will defeat prompt injection in 2026 are the ones that adopt the architecture, implement the trust boundary, and produce the evidence that the audits require.

Facio (the HITL-first agent runtime) is the runtime that implements the CaMeL pattern. Placet.io (the HITL inbox and messenger) is the human review workflow for explicit capability grants. Together, they form the trust boundary architecture that prompt injection defense requires and that the 2026 incident data demands.

---

Further reading:

• arXiv: Defeating Prompt Injections by Design — CaMeL
• MIT CSAIL: CaMeL PDF (Defeating Prompt Injections by Design)
• Decode the Future: AI Agent Security 2026 — Injection, Sandboxing & Permissions
• AIMagicX: Prompt Injection Attacks — The Hidden Security Crisis Threatening Every AI Agent
• Agdex: AI Agent Security — Prompt Injection Defense 2026
• Your Agent's Reasoning Is the Audit Trail You Cannot Reconstruct
• Tool Poisoning Is the New Prompt Injection: The MCP Attack Class Hiding in Plain Sight