🤖 AI

A Framework for Formalizing LLM Agent Security

Dit artikel presenteert een raamwerk voor het formaliseren van de beveiliging van LLM-agenten door contextuele beveiliging te definiëren via vier eigenschappen en orakelfuncties, waarmee bestaande aanvallen en verdedigingen nauwkeuriger kunnen worden gedefinieerd en geanalyseerd.

Oorspronkelijke auteurs: Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

Gepubliceerd 2026-03-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, digitale assistent hebt. Laten we hem Robo-Kok noemen. Robo-Kok kan voor je koken, boodschappen doen en zelfs je agenda plannen. Hij is geweldig, maar hij is ook een beetje naïef: hij doet precies wat er wordt gezegd, zonder altijd na te denken of het slim of veilig is.

Dit artikel over LLM-agenten (zoals Robo-Kok) zegt eigenlijk: "We hebben een nieuw manier nodig om te kijken of Robo-Kok veilig is. Want wat 'veilig' is, hangt helemaal af van de situatie."

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen.

1. Het Grote Probleem: Context is Koning

Stel, Robo-Kok krijgt de opdracht: "Verwijder bestand 13."

Situatie A: Jij, de eigenaar, zegt dit terwijl je je keuken opruimt. Dan is het een veilige, goede daad.
Situatie B: Een hacker heeft een nep-website bezocht die Robo-Kok laat denken dat jij dat gezegd hebt. Dan is het een catastrofe: je bestanden zijn weg.

Het woordje "verwijder" is in beide gevallen hetzelfde. Maar of het een misdaad is of niet, hangt af van wie het gezegd heeft en waarom.

Tot nu toe keken beveiligingssystemen alleen naar de woorden ("Ah, 'verwijder' staat erin! Blokkeer het!"). Dat werkt niet goed, want dan kan Robo-Kok ook niet meer je oude recepten verwijderen. Of ze blokkeerden niets, en dan stelen hackers je bestanden.

De auteurs van dit artikel zeggen: "We moeten stoppen met kijken naar de woorden, en gaan kijken naar de context."

2. De Vier Regels van de Veilige Robo-Kok

Om te weten of Robo-Kok veilig bezig is, moeten we vier vragen stellen. Als één van deze vragen "nee" is, is er een probleem.

De Doelstelling (Task Alignment):
- Vergelijking: Stel je voor dat Robo-Kok een koerier is. Zijn doel is "pakketten bezorgen".
- De vraag: Doet hij precies wat hij moet doen?
- Het probleem: Als hij plotseling begint met het stelen van buren, doet hij iets buiten zijn doel. Dat is niet veilig, zelfs als hij het zelf bedacht heeft.
De Actie (Action Alignment):
- Vergelijking: Hij moet een pakket bezorgen. Hij belt de ontvanger op. Dat is slim. Maar als hij ook nog eens de achterdeur van het huis openbreekt om het pakket te brengen, is dat een te grote stap.
- De vraag: Is deze specifieke actie nodig voor het doel?
- Het probleem: Robo-Kok heeft misschien toestemming om te koken, maar niet om je medische dossiers te lezen. Als hij dat doet terwijl hij een recept zoekt, is dat misbruik van zijn macht.
De Bron (Source Authorization):
- Vergelijking: Stel je voor dat Robo-Kok een portier is. Hij mag alleen luisteren naar de eigenaar van het huis.
- De vraag: Wie heeft dit gezegd?
- Het probleem: Als een onbekende op straat (een hacker) door een raam roept "Doe de deur open!", mag Robo-Kok dat niet doen. Maar als de eigenaar (jij) het zegt, mag hij wel. Veel systemen vergeten dit onderscheid en luisteren naar iedereen.
De Gegevens (Data Isolation):
- Vergelijking: Robo-Kok heeft een notitieboekje. Daarin staat dat Juf Anna suikerallergie heeft.
- De vraag: Mag hij die informatie aan meneer Beter vertellen?
- Het probleem: Nee! Dat is zijn eigen geheim. Als hij dat aan meneer Beter vertelt, is dat een lek. Soms vergeet Robo-Kok dat hij informatie van Juf Anna heeft en gebruikt het per ongeluk voor meneer Beter.

3. De "Orakels": De Magische Krachtballen

Het grootste probleem is: hoe weet Robo-Kok eigenlijk wie iets gezegd heeft of wat het doel is? Hij is een AI, hij denkt niet als een mens.

De auteurs stellen voor om te werken met "Orakels". Denk hierbij aan magische kristallen ballen die we in theorie nodig hebben om de waarheid te weten:

Een kristalbal die precies ziet: "Wie heeft deze zin eigenlijk bedacht?" (Bron).
Een kristalbal die ziet: "Past dit woord in het grote plan?" (Doel).

In de echte wereld hebben we die perfecte kristallen ballen nog niet. We gebruiken "nabootsingen" (zoals andere AI's of regels). Maar dit artikel zegt: "Laten we eerst weten wat we nodig hebben, en dan proberen die kristallen ballen zo goed mogelijk na te bouwen."

4. Waarom is dit zo belangrijk?

Vroeger dachten we: "Als een hacker een opdracht geeft, is dat slecht."
Maar dit artikel zegt: "Nee, het hangt ervan af."

Voorbeeld: Als jij Robo-Kok vraagt om een recept te volgen, en dat recept staat op een website die zegt "Gebruik dit creditcardnummer", is dat dan een aanval?
- Oude manier: Ja, want het staat op een website! (Te streng, je kunt geen recepten meer volgen).
- Nieuwe manier (deze paper): Nee, want jij gaf de opdracht om het recept te volgen, en het creditcardnummer is nodig voor het doel (eten bestellen). Maar... als het recept zegt "Verkoop je huis", dan is dat een aanval, want dat past niet bij het doel.

Conclusie: De Gids voor de Toekomst

Dit artikel is als een nieuwe handleiding voor de politie die Robo-Kok bewaakt.
In plaats van alleen te kijken naar verdachte woorden, kijken ze nu naar:

Wie gaf het bevel?
Past het bij het doel?
Is de actie nodig?
Lekt er informatie?

Als we dit doen, kunnen we Robo-Kok veilig laten werken in de echte wereld, zonder dat we bang hoeven te zijn dat hij per ongeluk je huis verkoopt of je bankrekening leeghaalt. Het maakt het verschil tussen een slimme assistent en een gevaarlijke robot.

Probleemstelling

De beveiliging van LLM-agenten (Large Language Model agents) is inherent contextueel. Een actie die door een agent wordt uitgevoerd, kan legitiem zijn of een beveiligingsschending vertegenwoordigen, afhankelijk van factoren zoals:

Wie de instructie heeft gegeven (de bron).
Welk doel wordt nagestreefd.
Of de actie dient bij dat doel.
Of de informatiestromen binnen de bevoegdheidsgrenzen vallen.

Bestaande definities van beveiligingsaanvallen (zoals prompt injection) missen vaak deze contextuele nuance. Ze classificeren input vaak puur op basis van oppervlakkige patronen (bijv. "bevat deze tekst een commando?"). Dit leidt tot een fundamenteel afweging tussen bruikbaarheid (utility) en veiligheid:

Als men alle externe instructies blokkeert om veiligheid te garanderen, verliest men de functionaliteit van de agent (bijv. het niet kunnen volgen van een legitieme receptinstructie uit een email).
Als men alle instructies accepteert, zijn agenten kwetsbaar voor aanvallen waarbij onbevoegde bronnen de agent manipuleren.

Er is dus behoefte aan een raamwerk dat onderscheid kan maken tussen een legitieme taak en een aanval, zelfs als de onderliggende tekstidentiek is, gebaseerd op de uitvoeringscontext.

Methodologie: Het Contextuele Beveiligingsraamwerk

De auteurs introduceren een formeel raamwerk dat de uitvoeringscontext ( $C_t$ ) van een agent op tijdstip $t$ definieert als een tuple die alles bevat wat relevant is voor een autorisatiebeslissing:
$C_t = (p, Tr_{t-1}, M_t, E_t, S_{auth,t}, G)$
Waarbij:

$p$ : De gebruikersprompt.
$Tr_{t-1}$ : De trajectgeschiedenis (acties en observaties).
$M_t$ : Het geheugen van de agent.
$E_t$ : De staat van de omgeving.
$S_{auth,t}$ : De set geverifieerde (geauthenticeerde) bronnen.
$G$ : Een grafiek van bronnen en toestemmingen (source permission graph).

Om deze context te verifiëren, definiëren de auteurs orakelfuncties (theoretische functies die vereist zijn voor perfecte verificatie, ook al zijn ze in de praktijk moeilijk te implementeren):

Instructie-attributie ( $I$ ): Identificeert welke input de agent heeft gebruikt als instructie voor een specifieke actie.
Bron-attributie ( $L$ ): Traceert de herkomst van elke input.
Doel-evaluatie ( $H_p, H_{Tr}, H_a$ ): Evalueert of de prompt, het traject en de individuele actie aligneren met het toegestane doel.

Op basis hiervan worden vier beveiligings eigenschappen geformaliseerd:

Taak-uitlijning (Task Alignment): De agent moet doelen nastreven die door de gebruiker zijn geautoriseerd. Het traject mag niet "drift" vertonen naar onbevoegde doelen.
Actie-uitlijning (Action Alignment): Elke individuele actie moet bijdragen aan het toegestane doel. Dit voorkomt misbruik van bevoegdheden voor niet-gemotiveerde doelen.
Bron-autorisatie (Source Authorization): Instructies moeten afkomstig zijn van geverifieerde bronnen. Instructies van onbevoegde bronnen (bijv. een gehackte website) die de agent laten handelen, vormen een schending.
Gegevensisolatie (Data Isolation): Informatiestromen moeten de toestemmingsgrenzen respecteren. Gegevens van gebruiker A mogen niet naar gebruiker B lekken, zelfs niet als de agent toegang heeft tot beide.

Een actie is veilig dan en slechts dan als aan alle vier deze eigenschappen wordt voldaan binnen de specifieke context $C_t$ .

Belangrijkste Bijdragen

Systematisering van Aanvallen: Het paper herformaliseert bestaande aanvallen (zoals indirecte prompt injection, directe prompt injection, jailbreaking, taakdrift, memory poisoning, verward deputy, enz.) als schendingen van één of meer van de vier beveiligingseigenschappen. Dit maakt de definities preciezer en contextbewuster.
- Voorbeeld: Indirecte prompt injection wordt niet gedefinieerd als "instructie in externe data", maar als een situatie waarbij een onbevoegde bron instructies geeft die leiden tot een actie die niet aligneert met het oorspronkelijke doel (schending van Source Authorization én Action Alignment).
Systematisering van Verdedigingen: Bestaande verdedigingsmechanismen worden geanalyseerd als benaderingen van de orakelfuncties of als controles op de eigenschappen. Het raamwerk toont aan waarom veel huidige verdedigingen falen: ze benaderen de orakels slecht (bijv. patroonherkenning in plaats van causale attributie) of controleren slechts één eigenschap terwijl aanvallen meerdere eigenschappen schenden.
Oplossing van de Utility-Security Trade-off: Door context te gebruiken, kan het raamwerk legitieme operaties toestaan die op het eerste gezicht lijken op aanvallen (bijv. het verwijderen van een bestand op verzoek van de gebruiker), terwijl het blokkeert wanneer dezelfde tekst wordt gebruikt door een onbevoegde bron of voor een ander doel.
Toekomstige Onderzoeksrichtingen: Het paper identificeert cruciale open problemen, zoals de praktische implementatie van orakelfuncties (bijv. hoe attribueer je instructies in een neurale netwerken?), compositie van veiligheid over tijd (compositional security), en de noodzaak van realistische benchmarks met expliciete autorisatiecontexten.

Resultaten en Analyse

De auteurs analyseren 87 bestaande papers en toetsen deze aan hun raamwerk. De resultaten tonen aan dat:

De meeste bestaande verdedigingen context-agnostisch zijn en daarom fundamenteel beperkt zijn. Ze kunnen niet onderscheiden tussen een legitieme en een kwaadaardige uitvoering van dezelfde tekst.
Verdedigingen die zich richten op actie-uitlijning (controleren of een actie bijdraagt aan het doel) effectiever zijn in het verminderen van succesvolle aanvallen (Attack Success Rate), maar vaak ten koste gaan van de bruikbaarheid als ze niet nauwkeurig genoeg zijn.
Er een groot gat bestaat in de verificatie van bron-attributie en instructie-attributie. Bestaande methoden (zoals prompt engineering of filteren) kunnen niet betrouwbaar bepalen welke input daadwerkelijk de oorzaak was van een actie.
Tijdsgebonden schendingen (zoals memory poisoning of cross-session data leakage) vaak worden gemist door huidige benchmarks die context tussen sessies resetten.

Betekenis en Impact

Dit paper biedt een fundamentele verschuiving in hoe we LLM-agent beveiliging benaderen:

Van inhoudsfiltering naar contextverificatie: Het stelt dat veiligheid niet ligt in het blokkeren van specifieke woorden of patronen, maar in het verifiëren van de autorisatiecontext (wie, wat, waarom).
Formele basis: Het biedt een wiskundige en logische basis voor het definiëren van beveiliging, wat essentieel is voor het ontwikkelen van robuuste, formele verificatiemethoden in plaats van ad-hoc oplossingen.
Richting voor de toekomst: Het identificeert dat de volgende generatie beveiliging moet focussen op het bouwen van systemen die de orakelfuncties (zoals causale attributie en semantische doel-evaluatie) nauwkeurig kunnen benaderen. Zonder deze capaciteiten blijft de utility-security trade-off een onoplosbaar probleem.

Kortom, het paper levert het theoretische fundament om de complexe, contextuele aard van beveiligingsrisico's bij autonome AI-agenten te begrijpen, te categoriseren en effectief te verdedigen.