The Dual-LLM Pattern Against Prompt Injection

Prompt injection is difficult because instructions and data arrive as language in the same model context. A malicious web page can ask an agent to ignore its task, disclose information, or call a tool; merely telling one model to ignore such text does not create a reliable security boundary. The dual-LLM pattern reduces direct exposure by assigning different permissions. A privileged model plans and acts using approved tools, while a quarantined model reads untrusted documents or pages and has no ability to act. Its response should be narrow, such as a validated price, date, or selected label, rather than a general narrative that could carry hidden instructions back across the boundary. The handoff is the critical design point. Treat the quarantined result as untrusted data, validate its schema and allowed values in ordinary code, and give the privileged model only the fields needed for its decision. Keep tool authorization outside the returned text: an extracted field must not grant a new capability. Log which source produced each value, and require confirmation for consequential actions. Also inspect indirect paths such as retrieved text, tool outputs, conversation memory, and error messages; a second model does not help if raw hostile content reaches the privileged context through another route. This is an architectural pattern, not a guarantee attached to using two models. It adds calls and integration work, and an attacker may still manipulate the extractor, exploit a permissive schema, or reach the acting model through an unreviewed channel. Research such as CaMeL explores stronger system-level boundaries using explicit control and data flow plus capabilities; it is related work, not evidence that every two-model design has CaMeL’s properties. Test the whole workflow with adversarial inputs and verify authorization in code, independently of what either model says.