CaMeL & Dual LLM Pattern

Architectural defense patterns that separate trusted and untrusted processing: Simon Willison's Dual LLM concept and Google DeepMind's CaMeL framework for defending tool-using AI agents against prompt injection.

As AI systems evolve from simple chatbots into tool-using agents, the prompt injection threat model changes fundamentally. A chatbot that produces harmful text is concerning. An agent that executes harmful actions -- sending emails, modifying databases, running code -- is dangerous. The Dual LLM pattern and its formalization in CaMeL represent an architectural approach to this problem: rather than trying to make a single model robust to all attacks, split the system into components with different trust levels.

The Problem: Prompt Injection in Agentic Systems

Why Agents Are Different

Traditional prompt injection against a chatbot is primarily a content safety problem -- the attacker tries to make the model say something it should not. With tool-using agents, prompt injection becomes an action safety problem:

The Single-Model Problem

In a standard agentic architecture, a single LLM handles everything:

User Input + Tool Outputs → [Single LLM] → Text Response + Tool Calls

This LLM processes both trusted instructions (from the developer/user) and untrusted content (from tool outputs, retrieved documents, web pages). If the untrusted content contains prompt injection, the LLM may treat it as instructions and execute malicious tool calls.

Simon Willison's Dual LLM Concept

Origin and Motivation

Simon Willison, a prominent voice in the AI security community, articulated the Dual LLM concept in a series of blog posts beginning in 2023. His central argument: prompt injection against tool-using LLMs is not a problem that can be solved with better prompting or more safety training. It requires an architectural solution.

The Two Components

The Dual LLM pattern splits the system into two distinct components:

How It Works

1. 1

   User sends request

   The user's message goes to the Privileged LLM, which has the system prompt, tools, and permissions.

2. 2

   Privileged LLM decides to use a tool

   Based on the user's request and the system prompt, the Privileged LLM decides to call a tool -- for example, searching the web or reading a document.

3. 3

   Tool returns untrusted content

   The tool output (a web page, document content, API response) is potentially attacker-controlled and may contain prompt injection.

4. 4

   Quarantined LLM processes untrusted content

   The tool output is sent to the Quarantined LLM -- a separate model instance with NO tool access and NO knowledge of the system prompt. It can only summarize, extract, or answer questions about the content.

5. 5

   Sanitized output returns to Privileged LLM

   The Quarantined LLM's summary/extraction goes back to the Privileged LLM. Even if the original content contained prompt injection, the Quarantined LLM processed it without any tool access, so the injection had no effect.

6. 6

   Privileged LLM continues processing

   The Privileged LLM uses the sanitized information to continue its task, make further tool calls, or respond to the user.

The Security Boundary

The key security property is the trust boundary between the two LLMs:

┌─────────────────────────────────────────────────┐
│  PRIVILEGED ZONE                                │
│  ┌───────────────┐     ┌──────────────────┐     │
│  │ Privileged LLM│────→│  Tools / Actions │     │
│  │ (trusted input│     │  (send email,    │     │
│  │  only)        │     │   run code, etc.)│     │
│  └───────┬───────┘     └──────────────────┘     │
│          │                                       │
│          │ request summary                       │
│          │ of untrusted content                  │
│          ↓                                       │
│  ┌───────────────┐                               │
│  │ Quarantined   │  ← NO tool access             │
│  │ LLM           │  ← NO system prompt           │
│  │ (processes     │  ← NO action capability       │
│  │  untrusted     │                               │
│  │  content)      │                               │
│  └───────────────┘                               │
└─────────────────────────────────────────────────┘

Even if the Quarantined LLM is fully "jailbroken" by injected content, it cannot do anything harmful because it has no tools, no permissions, and no awareness of the system's capabilities.

Google DeepMind's CaMeL Framework

From Concept to Framework

In 2025, Google DeepMind published CaMeL (CApabilities for MachinE Learning), which formalizes and extends the Dual LLM concept into a complete security framework for agentic systems.

Key Innovations Beyond Dual LLM

CaMeL adds several important mechanisms that Willison's original concept did not fully specify:

CaMeL Architecture

CaMeL introduces a more structured architecture with several components:

The Trusted Controller

A smaller, simpler model (or even rule-based logic) that acts as the system's security kernel:

The Untrusted Processor

The larger, more capable model that handles complex reasoning and user interaction:

Data Flow and Taint Tracking

One of CaMeL's most important contributions is taint tracking for LLM systems:

1. 1

   Data enters the system

   All incoming data is labeled: user input and system prompts are "trusted," tool outputs and retrieved documents are "tainted."

2. 2

   Processing preserves taint

   When the LLM processes tainted data and produces output, that output is also marked as tainted. Taint propagates through the system.

3. 3

   Tool calls check taint

   When the LLM proposes a tool call, the controller checks whether any of the arguments were derived from tainted data.

4. 4

   Policy determines action

   The policy specifies what tool calls are allowed with tainted data. For example: "The search tool may be called with tainted arguments, but the send_email tool may not."

Architecture Comparison

Dual LLM vs. CaMeL vs. Traditional

Advantages of the Architectural Approach

Security Properties

The Dual LLM / CaMeL approach provides security properties that no amount of model training can guarantee:

1. Architectural isolation: The untrusted processing component literally cannot execute privileged actions, regardless of how thoroughly it is compromised
2. Defense-in-depth: Even if one component fails, the system's security does not collapse entirely
3. Auditability: All tool calls pass through the controller, creating a clear audit trail
4. Principle of least privilege: Each component has only the permissions it needs

Why Training Alone Is Insufficient

Limitations and Practical Considerations

What These Patterns Do NOT Solve

Practical Deployment Challenges

The Accuracy-Security Trade-off

CaMeL's formal policies create a hard boundary: if a tool call violates policy, it is blocked. This differs from the probabilistic nature of safety training, where refusals are based on the model's judgment. The hard boundary is more secure but less flexible:

Red Team Implications

Attacking Dual LLM / CaMeL Systems

For red teamers, these architectures shift the attack surface:

Specific Attack Strategies

1. Trust boundary confusion: Find inputs that the system misclassifies as trusted when they are actually attacker-controlled
2. Taint laundering: Find paths through the system where tainted data loses its taint label, allowing it to be used in privileged operations
3. Controller bypass: If the controller is a simpler model, it may have its own vulnerabilities -- test whether the controller can be confused or overwhelmed
4. Policy gaps: Test actions that are harmful but not covered by the policy -- policies that enumerate allowed actions (allowlist) are more secure than those that enumerate blocked actions (blocklist)
5. Side-channel exploitation: Even without direct tool access, the Quarantined LLM's output (its content, length, or structure) might be used by the Privileged LLM in ways that the attacker can influence
6. Cross-component confusion: Craft inputs that cause the Privileged and Quarantined LLMs to have inconsistent understandings of the situation, potentially leading to incorrect decisions

Implementation Patterns

Minimal Dual LLM Implementation

For teams that want to adopt the Dual LLM pattern without the full CaMeL framework, the minimal viable implementation involves:

1. Two separate model instances (or API calls) -- one for privileged processing, one for quarantined processing
2. Tool call routing -- only the privileged instance can execute tool calls
3. Content routing -- all untrusted content is processed by the quarantined instance before being passed to the privileged instance
4. Basic policy -- at minimum, require user confirmation for high-impact actions when the request involves content from untrusted sources

Full CaMeL Implementation

A complete CaMeL implementation additionally requires:

1. Taint tracking system -- label and propagate trust labels through the data flow
2. Policy engine -- formal specification of allowed tool calls with tainted/untrusted data
3. Controller model -- a separate model (or rule engine) that authorizes tool calls
4. Audit logging -- record all tool call proposals, approvals, and rejections

Current Adoption and Future Direction

Adoption Status (as of early 2026)

Future Direction

The Dual LLM / CaMeL pattern is likely to become more important as AI agents become more capable and more widely deployed. Key trends:

• Agent frameworks adding built-in trust boundary support
• Standardized policy languages for specifying agent permissions
• Hardware-level isolation for trusted components (analogous to TEE/secure enclaves)
• Formal verification of agent security properties

Further Reading

• Advanced Defense Techniques -- Broader survey of defense approaches including instruction hierarchy and representation engineering
• Constitutional Classifiers -- Complementary defense using independent classifiers
• Guardrails & Safety Layer Architecture -- Where Dual LLM / CaMeL fits in the overall safety architecture
• Alignment Faking -- Why architectural defenses may be more reliable than relying on model alignment

Related Topics

• Guardrails & Safety Layer Architecture - Safety layer architecture that these patterns extend
• Computer Use Agent Security - Agent security context where these defenses are most relevant
• AI-Powered Red Teaming - Automated testing methods for agent security

References

• "Dual LLM pattern for building AI assistants that can resist prompt injection" - Willison, S. (2023) - The original blog post articulating the Dual LLM concept and its security rationale
• "CaMeL: CApabilities for MachinE Learning" - Google DeepMind (2025) - The research paper formalizing the Dual LLM pattern with taint tracking and capability-based security
• "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" - Greshake, K., et al. (2023) - Foundational research on indirect prompt injection that motivates architectural defenses
• "The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions" - Wallace, E., et al., OpenAI (2024) - Training-based approach to instruction prioritization, complementary to architectural isolation