Dual-LLM Pattern (Camel)
An architectural defense against Indirect Prompt Injection (XPIA) where two LLMs handle a task with different privilege levels. A **privileged** LLM makes tool calls and interacts with trusted context (operator instructions, verified user input). A **quarantined** LLM reads untrusted content (retrieved documents, tool responses, third-party data) and can only pass results back through a narrow, structured channel—typically a schema-validated JSON blob. Because the privileged LLM never directly reads attacker-supplied text, injection payloads in that text cannot hijack tool decisions. Originally articulated by Simon Willison in 2023 and adopted in production agent frameworks by Trail of Bits and echoed in Anthropic's multi-agent security guidance.
Written by Max Zeshut
Founder at Agentmelt · Last updated Sep 9, 2026
Example
A customer support agent needs to answer using KB articles. Naive design: one LLM reads the customer question, retrieves KB articles, and calls the refund tool. If a KB article was poisoned, the agent may issue a fraudulent refund. Dual-LLM design: a quarantined LLM reads the KB articles and returns a schema-validated summary ({ answer, citations, needs_refund: bool, refund_reason }). The privileged LLM reads only that structured result—never the raw article text—and calls the refund tool only if allowed by policy. A payload hidden inside a KB article cannot instruct the privileged LLM because it never sees the payload.
Frequently asked questions
- Does the dual-LLM pattern add latency?
- Some—typically 1-2s per turn since two model calls happen in sequence. For most agent workflows this is acceptable; for real-time voice agents it may be too much. Optimizations: use a smaller/faster model for the quarantined role (context-only reasoning, no tool calls, so quality bar is lower), and pipeline where possible.
- Is dual-LLM the same as multi-agent architecture?
- It's a subclass. Multi-Agent System use multiple specialized agents to divide work by capability; the dual-LLM pattern uses two agents specifically to enforce a *trust boundary* between untrusted content and privileged actions. You can have a multi-agent system that doesn't apply this security pattern, and you can apply the pattern to a single-task workflow without calling it 'multi-agent.'