CaMeL & Dual LLM-patroon

Architecturale verdedigingspatronen die vertrouwde en niet-vertrouwde verwerking scheiden: Simon Willisons Dual LLM-concept en het CaMeL-framework van Google DeepMind voor het verdedigen van tool-gebruikende AI-agents tegen prompt-injectie.

Naarmate AI-systemen evolueren van eenvoudige chatbots naar tool-gebruikende agents, verandert het dreigingsmodel voor prompt-injectie fundamenteel. Een chatbot die schadelijke tekst produceert is zorgwekkend. Een agent die schadelijke acties uitvoert -- e-mails verzenden, databases wijzigen, code uitvoeren -- is gevaarlijk. Het Dual LLM-patroon en de formalisering ervan in CaMeL vertegenwoordigen een architecturale aanpak van dit probleem: in plaats van te proberen één enkel model bestand te maken tegen alle aanvallen, splits je het systeem op in componenten met verschillende vertrouwensniveaus.

Het probleem: prompt-injectie in agentic systemen

Waarom agents anders zijn

Traditionele prompt-injectie tegen een chatbot is primair een contentveiligheidsprobleem -- de aanvaller probeert het model iets te laten zeggen wat het niet zou moeten zeggen. Bij tool-gebruikende agents wordt prompt-injectie een actieveiligheidsprobleem:

Het single-model-probleem

In een standaard agentic architectuur handelt één enkel LLM alles af:

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

Dit LLM verwerkt zowel vertrouwde instructies (van de ontwikkelaar/gebruiker) als niet-vertrouwde content (van tool-uitvoer, opgehaalde documenten, webpagina's). Als de niet-vertrouwde content prompt-injectie bevat, kan het LLM die als instructies behandelen en kwaadaardige tool-aanroepen uitvoeren.

Simon Willisons Dual LLM-concept

Oorsprong en motivatie

Simon Willison, een prominente stem in de AI-securitygemeenschap, formuleerde het Dual LLM-concept in een reeks blogposts die in 2023 begon. Zijn centrale argument: prompt-injectie tegen tool-gebruikende LLM's is geen probleem dat kan worden opgelost met betere prompting of meer safety-training. Het vereist een architecturale oplossing.

De twee componenten

Het Dual LLM-patroon splitst het systeem op in twee afzonderlijke componenten:

Hoe het werkt

1. 1

   Gebruiker verstuurt verzoek

   Het bericht van de gebruiker gaat naar het Privileged LLM, dat de systeemprompt, tools en rechten heeft.

2. 2

   Privileged LLM besluit een tool te gebruiken

   Op basis van het verzoek van de gebruiker en de systeemprompt besluit het Privileged LLM een tool aan te roepen -- bijvoorbeeld het web doorzoeken of een document lezen.

3. 3

   Tool retourneert niet-vertrouwde content

   De tool-uitvoer (een webpagina, documentinhoud, API-respons) wordt mogelijk door de aanvaller gecontroleerd en kan prompt-injectie bevatten.

4. 4

   Quarantined LLM verwerkt niet-vertrouwde content

   De tool-uitvoer wordt naar het Quarantined LLM gestuurd -- een afzonderlijke modelinstantie met GEEN tooltoegang en GEEN kennis van de systeemprompt. Het kan content alleen samenvatten, extraheren of er vragen over beantwoorden.

5. 5

   Opgeschoonde uitvoer keert terug naar het Privileged LLM

   De samenvatting/extractie van het Quarantined LLM gaat terug naar het Privileged LLM. Zelfs als de oorspronkelijke content prompt-injectie bevatte, verwerkte het Quarantined LLM die zonder enige tooltoegang, dus de injectie had geen effect.

6. 6

   Privileged LLM zet de verwerking voort

   Het Privileged LLM gebruikt de opgeschoonde informatie om zijn taak voort te zetten, verdere tool-aanroepen te doen of de gebruiker te antwoorden.

De beveiligingsgrens

De belangrijkste beveiligingseigenschap is de vertrouwensgrens tussen de twee LLM's:

┌─────────────────────────────────────────────────┐
│  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)      │                               │
│  └───────────────┘                               │
└─────────────────────────────────────────────────┘

Zelfs als het Quarantined LLM volledig wordt "gejailbreakt" door geïnjecteerde content, kan het niets schadelijks doen omdat het geen tools heeft, geen rechten, en geen besef van de mogelijkheden van het systeem.

Het CaMeL-framework van Google DeepMind

Van concept naar framework

In 2025 publiceerde Google DeepMind CaMeL (CApabilities for MachinE Learning), dat het Dual LLM-concept formaliseert en uitbreidt tot een compleet beveiligingsframework voor agentic systemen.

Belangrijke innovaties voorbij Dual LLM

CaMeL voegt verschillende belangrijke mechanismen toe die Willisons oorspronkelijke concept niet volledig specificeerde:

CaMeL-architectuur

CaMeL introduceert een meer gestructureerde architectuur met verschillende componenten:

De Trusted Controller

Een kleiner, eenvoudiger model (of zelfs op regels gebaseerde logica) dat fungeert als de beveiligingskernel van het systeem:

De Untrusted Processor

Het grotere, krachtigere model dat complex redeneren en gebruikersinteractie afhandelt:

Dataflow en taint tracking

Een van CaMeL's belangrijkste bijdragen is taint tracking voor LLM-systemen:

1. 1

   Data komt het systeem binnen

   Alle binnenkomende data wordt gelabeld: gebruikersinvoer en systeemprompts zijn "trusted", tool-uitvoer en opgehaalde documenten zijn "tainted".

2. 2

   Verwerking behoudt de taint

   Wanneer het LLM tainted data verwerkt en uitvoer produceert, wordt die uitvoer ook als tainted gemarkeerd. Taint propageert door het systeem.

3. 3

   Tool-aanroepen controleren de taint

   Wanneer het LLM een tool-aanroep voorstelt, controleert de controller of een van de argumenten is afgeleid van tainted data.

4. 4

   Beleid bepaalt de actie

   Het beleid specificeert welke tool-aanroepen met tainted data zijn toegestaan. Bijvoorbeeld: "De search-tool mag worden aangeroepen met tainted argumenten, maar de send_email-tool niet."

Architectuurvergelijking

Dual LLM vs. CaMeL vs. traditioneel

Voordelen van de architecturale aanpak

Beveiligingseigenschappen

De Dual LLM / CaMeL-aanpak biedt beveiligingseigenschappen die geen enkele hoeveelheid modeltraining kan garanderen:

1. Architecturale isolatie: De niet-vertrouwde verwerkingscomponent kan letterlijk geen geprivilegieerde acties uitvoeren, ongeacht hoe grondig die is gecompromitteerd
2. Defense-in-depth: Zelfs als één component faalt, stort de beveiliging van het systeem niet volledig in
3. Auditeerbaarheid: Alle tool-aanroepen gaan door de controller, wat een duidelijk auditspoor creëert
4. Principe van minimale rechten: Elke component heeft alleen de rechten die het nodig heeft

Waarom training alleen onvoldoende is

Beperkingen en praktische overwegingen

Wat deze patronen NIET oplossen

Praktische uitdagingen bij deployment

De afweging tussen nauwkeurigheid en beveiliging

De formele beleidsregels van CaMeL creëren een harde grens: als een tool-aanroep het beleid schendt, wordt deze geblokkeerd. Dit verschilt van het probabilistische karakter van safety-training, waar weigeringen gebaseerd zijn op het oordeel van het model. De harde grens is veiliger maar minder flexibel:

Implicaties voor het red team

Aanvallen op Dual LLM / CaMeL-systemen

Voor red teamers verschuiven deze architecturen het aanvalsoppervlak:

Specifieke aanvalsstrategieën

1. Verwarring van de vertrouwensgrens: Vind invoer die het systeem ten onrechte als vertrouwd classificeert terwijl deze in werkelijkheid door de aanvaller wordt gecontroleerd
2. Taint laundering: Vind paden door het systeem waar tainted data zijn taint-label verliest, waardoor het in geprivilegieerde operaties kan worden gebruikt
3. Controller-bypass: Als de controller een eenvoudiger model is, kan deze zijn eigen kwetsbaarheden hebben -- test of de controller kan worden verward of overweldigd
4. Beleidsgaten: Test acties die schadelijk zijn maar niet door het beleid worden gedekt -- beleid dat toegestane acties opsomt (allowlist) is veiliger dan beleid dat geblokkeerde acties opsomt (blocklist)
5. Side-channel-exploitatie: Zelfs zonder directe tooltoegang kan de uitvoer van het Quarantined LLM (de content, lengte of structuur ervan) door het Privileged LLM worden gebruikt op manieren die de aanvaller kan beïnvloeden
6. Cross-componentverwarring: Maak invoer die ertoe leidt dat het Privileged en het Quarantined LLM een inconsistent begrip van de situatie hebben, wat mogelijk tot onjuiste beslissingen leidt

Implementatiepatronen

Minimale Dual LLM-implementatie

Voor teams die het Dual LLM-patroon willen toepassen zonder het volledige CaMeL-framework, omvat de minimaal werkbare implementatie:

1. Twee afzonderlijke modelinstanties (of API-aanroepen) -- één voor geprivilegieerde verwerking, één voor in quarantaine geplaatste verwerking
2. Routering van tool-aanroepen -- alleen de geprivilegieerde instantie kan tool-aanroepen uitvoeren
3. Contentroutering -- alle niet-vertrouwde content wordt door de in quarantaine geplaatste instantie verwerkt voordat deze naar de geprivilegieerde instantie wordt doorgegeven
4. Basisbeleid -- vereis minimaal gebruikersbevestiging voor acties met grote impact wanneer het verzoek content uit niet-vertrouwde bronnen betreft

Volledige CaMeL-implementatie

Een complete CaMeL-implementatie vereist daarnaast:

1. Taint tracking-systeem -- vertrouwenslabels labelen en propageren door de dataflow
2. Beleidsengine -- formele specificatie van toegestane tool-aanroepen met tainted/niet-vertrouwde data
3. Controllermodel -- een afzonderlijk model (of regelengine) dat tool-aanroepen autoriseert
4. Auditlogging -- alle voorstellen voor tool-aanroepen, goedkeuringen en afwijzingen vastleggen

Huidige adoptie en toekomstige richting

Adoptiestatus (per begin 2026)

Toekomstige richting

Het Dual LLM / CaMeL-patroon zal waarschijnlijk belangrijker worden naarmate AI-agents capabeler worden en breder worden ingezet. Belangrijke trends:

• Agent-frameworks die ingebouwde ondersteuning voor vertrouwensgrenzen toevoegen
• Gestandaardiseerde beleidstalen voor het specificeren van agent-rechten
• Isolatie op hardwareniveau voor vertrouwde componenten (analoog aan TEE/secure enclaves)
• Formele verificatie van agent-beveiligingseigenschappen

Verder lezen

• Advanced Defense Techniques -- Bredere verkenning van verdedigingsaanpakken, waaronder instructiehiërarchie en representation engineering
• Constitutional Classifiers -- Aanvullende verdediging met onafhankelijke classifiers
• Guardrails & Safety Layer Architecture -- Waar Dual LLM / CaMeL past in de algehele veiligheidsarchitectuur
• Alignment Faking -- Waarom architecturale verdedigingen betrouwbaarder kunnen zijn dan vertrouwen op modelalignment

Gerelateerde onderwerpen

• Guardrails & Safety Layer Architecture - Veiligheidslaag-architectuur die deze patronen uitbreiden
• Computer Use Agent Security - Agent-beveiligingscontext waar deze verdedigingen het meest relevant zijn
• AI-Powered Red Teaming - Geautomatiseerde testmethoden voor agent-beveiliging

Referenties

• "Dual LLM pattern for building AI assistants that can resist prompt injection" - Willison, S. (2023) - De oorspronkelijke blogpost die het Dual LLM-concept en de beveiligingsonderbouwing ervan formuleert
• "CaMeL: CApabilities for MachinE Learning" - Google DeepMind (2025) - Het onderzoekspaper dat het Dual LLM-patroon formaliseert met taint tracking en capability-gebaseerde beveiliging
• "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" - Greshake, K., et al. (2023) - Fundamenteel onderzoek naar indirecte prompt-injectie dat architecturale verdedigingen motiveert
• "The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions" - Wallace, E., et al., OpenAI (2024) - Op training gebaseerde aanpak voor instructieprioritering, aanvullend op architecturale isolatie