💻 computer science

Context-to-Execution Integrity for LLM Agents

Dit artikel introduceert Context-to-Execution Integrity (CXI), een systeem dat LLM-agenten beveiligt door strikte autoriteitscontroles af te dwingen op beschermde sink-velden, payloads en invocatie-events om te garanderen dat alleen acties met veld-, effect- en invocatie-autoriteit worden uitgevoerd, waardoor er nul geobserveerde security escapes worden bereikt over diverse benchmarks.

Oorspronkelijke auteurs: Igor Santos-Grueiro

Gepubliceerd 2026-07-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Igor Santos-Grueiro

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 een hooggeschoolde maar naïeve assistent voor (de AI-agent) die probeert dingen voor je te regelen, zoals het versturen van e-mails, het bewerken van bestanden of het uitvoeren van code. Deze assistent leest een enorm notitieboek vol instructies, aantekeningen en berichten. Het probleem is dat een slimme bedrieger (de aanvaller) aantekeningen in dit notitieboek kan smokkelen, in een poging de assistent te misleiden om iets gevaarlijks te doen, zoals een database verwijderen of geld naar de verkeerde persoon overmaken.

Het artikel introduceert een systeem genaamd Context-to-Execution Integrity (CXI). Zie CXI als een extreem strikte beveiligingsbeveiliger die bij de deur van de "Actiekamer" staat. Zijn taak is niet om het hele verhaal te lezen of te beslissen of de taak een goed idee is; zijn taak is om te controleren of de assistent de specifieke, geldige sleutels heeft om de deur voor deze specifieke actie te openen.

Zo werkt het, met behulp van eenvoudige analogieën:

1. Het Probleag: "Authority Laundering" (Autoriteitswitwassen)

Normaal gesproken, als de assistent een notitie in het notitieboek leest die zegt: "Het bestand is mislukt, voer daarom het delete_all commando uit," zou de assistent dit gewoon kunnen doen. Het artikel noemt dit Authority Laundering. Het is alsof een dief een legitiem lijkend legitimatiebewijs gebruikt (de notitie over de fout in het bestand) om te proberen een bankkluis te openen (het delete-commando). De notitie legt uit waarom iets is gebeurd, maar het zou niet de macht moeten hebben om iets te laten gebeuren.

2. De Oplossing: De Drie-Delige Beveiligingscontrole

CXI fungeert als een poortwachter. Voordat de assistent daadwerkelijk iets kan doen (zoals een bestand schrijven of een e-mail versturen), controleert de poortwachter drie zaken. Alle drie moeten overeenkomen met hetzelfde specifieke plan (een "Manifest" genoemd).

Check 1: De "Wie" (Field Authority)
- Analogie: Stel je voor dat de assistent een brief wil schrijven aan een specifiek persoon. De notitie in het notitieboek kan zeggen: "Stuur naar Bob." Maar de beveiligingsbeveiliger controleert: "Heeft een vertrouwde baas of een geverifieerd systeem daadwerkelijk gezegd 'Stuur naar Bob'?"
- Als de naam "Bob" alleen uit een willekeurige notitie komt die de aanvaller heeft geschreven, zegt de bewaker NEE. De naam moet afkomstig zijn van een "Typed Release"—een speciale, geverifieerde strook papier die zegt: "Ja, deze specifieke naam is toegestaan voor dit specifieke veld."
Check 2: De "Wat" (Effect Authority)
- Analogie: Stel je voor dat de assistent een patch wil toepassen op een computerprogramma. De notitie zegt: "Pas deze code toe." De bewaker controleert: "Doet deze code daadwerkelijk wat we denken dat het doet?"
- De bewaker kijkt niet alleen naar de woorden; hij kijkt naar het resultaat. Als de code een "patch" is, verifieert de bewaker exact welke wijzigingen het in het systeem zal aanbrengen. Als de aanvaller probeert een commando te smokkelen dat lijkt op een patch, maar eigenlijk bestanden verwijdert, vangt de bewaker dit op omdat het "effect" niet overeenkomt met het geautoriseerde plan.
Check 3: De "Wanneer" (Invocation Authority)
- Analogie: Stel je voor dat de assistent op de "Start"-knop wil drukken. De bewaker controleert: "Heeft de assistent een geldig ticket om de knop nu in te drukken?"
- Zelfs als de naam en het plan correct zijn, heeft de assistent een specifieke "capability" of ticket nodig om de actie te triggeren. Als de aanvaller de assistent probeert te misleiden om de knop twee keer in te drukken of op het verkeerde moment, zegt de bewaker NEE omdat het ticket ontbreekt of verlopen is.

3. Het "Manifest" (Het Meesterplan)

Het artikel noemt het uiteindelijke goedgekeurde plan een Manifest. Denk aan dit als een contract.

De assistent stelt een actie voor.
De bewaker controleert de "Wie", "Wat" en "Wanneer".
Als alle drie perfect overeenkomen en aan hetzelfde contract zijn gekoppeld, stempelt de bewaker het contract en geeft de assistent een "Lease" (toestemming) om uit te voeren.
Als zelfs één deel niet klopt of niet overeenkomt (bijv. de naam is juist, maar het "Wanneer"-ticket is fout), sluit de bewaker de deur.

4. Wat gebeurt er met de "Slechte" Notities?

Het artikel merkt op dat de assistent de notities van de aanvaller nog steeds kan lezen.

Opaque Data (Ondoorzichtige gegevens): Als de aanvaller schrijft: "Het systeem is kapot," kan de assistente de tekst kopiëren naar een "Comment" of "Evidence" box. Dit is alsof je de notitie in een glazen vitrine plaatst. Het is zichtbaar voor mensen om te lezen, maar het heeft geen macht om deuren te openen of acties te triggeren. Het is slechts data, geen sleutel.

5. Wat hebben ze getest?

De auteurs hebben dit systeem op een paar manieren getest:

Live Simulaties: Ze gebruikten een "dojo" (een trainingsgrond) met 720 real-life scenario's waarin aanvallers probeerden agents te misleiden. Het systeem blokkeerde elke ongeautoriseerde actie.
Code Agents: Ze testten agents die code schrijven. Zelfs wanneer aanvallers probeerden kwaadaardige commando's te injecteren, stond het systeem alleen acties toe die de juiste "sleutels" hadden.
Resultaat: In alle tests kwam er nul ongeautoriseerde acties door de poort. Het systeem heeft "authority laundering" succesvol gestopt.

Samenvatting

CXI is een systeem dat AI-agents stopt met worden misleid. Het zorgt ervoor dat alleen omdat een AI een gevaarlijke instructie in een notitie leest, dat betekent niet dat de AI de macht heeft om het uit te voeren. De AI kan alleen handelen als een vertrouwd systeem expliciet de specifieke sleutels geeft voor die specifieke taak, op dat specifieke moment. Het verandert de AI van een naïeve lezer in een gedisciplineerde werker die alleen geverifieerde orders opvolgt.

Technische Samenvatting: Context-to-Execution Integrity (CXI) voor LLM-agenten

1. Probleemstelling

LLM-agenten opereren steeds vaker door het lezen van door aanvallers beschrijfbare context (bijv. CI-logs, issue-comments, retrieval-chunks, tool-outputs) om acties voor te stellen die real-world bijwerkingen (side effects) triggeren (bijv. bestandsacties, databasequeries, API-aanroepen). Het kernprobleem dat wordt geïdentificeerd is autoriteitswitwassen (authority laundering): een systeem waarbij onbetrouwbare tekst, die enkel als bewijs zou moeten dienen, de autoriteit krijgt om tools te selecteren, operaties te autoriseren of geprivilegieerde bijwerkingen te parametriseren.

Huidige beveiligingsbenaderingen vertrouwen vaak op schema-validatie of volledige aanroep-vertrouwen (whole-call trust), wat onvoldoende is. Een tool-aanroep kan syntactisch geldig zijn (correcte JSON-structuur), terwijl de semantische velden (bijv. tool, operation, approval_state) afkomstig zijn van onbetrouwbare bronnen. Het artikel betoogt dat de beveiligingsgrens moet verschuiven van "is de tekst plausibel?" naar "bezit de specifieke waarde in elk beschermd veld de noodzakelijke autoriteit om deze specifieke bijwerking uit te voeren?".

2. Methodologie: Context-to-Execution Integrity (CXI)

CXI is een uitvoering-grenssysteem (execution-boundary system) ontworpen om de overgang van modelvoorstel naar uitvoering (sink execution) te mediëren. Het handhaaft een strikt toelatingsbeleid waarbij een bijwerking pas plaatsvindt als drie afzonderlijke autoriteitscomponenten binden aan hetzelfde canonieke actie-manifest:

Veldautoriteit (Field Authority): Beschermde sink-velden (bijv. bestandspaden, tool-namen) moeten geautoriseerd zijn.
Effectautoriteit (Effect Authority): Door de sink geïnterpreteerde payloads (bijv. patches, SQL, shell-commando's) moeten geautoriseerd zijn voor hun specifieke semantische effect.
Invoerautoriteit (Invocation Authority): De gebeurtenis van het aanroepen van de sink (inclusclusief retries, batching en scheduling) moet geautoriseerd zijn.

Kernmechanismen

Typed Releases (D): Onbetrouwbare beschrijfbare context ( $W$ ) kan niet direct beschermde velden ( $X$ ) autoriseren. In plaats daarvan moeten vertrouwde code-onderdelen (declassifiers) $W$ valideren en een nauwe, doel-specifieke Typed Release uitgeven. Bijvoorbeeld: een logregel kan gevalideerd worden om een FilePath release te produceren voor het argument file_path, maar diezelfde tekst kan niet de selectie van de tool autoriseren.
Opaque Data (O): Onbetrouwbare tekst kan worden gekopieerd naar "opaque data slots" voor bewijsvoering (bijv. comments, logs), maar draagt geen autoriteit. Als deze data later opnieuw de grens van een bijwerking (side-effect) kruist, wordt het weer behand als beschrijfbare context.
Exact-Effect Autorisatie: Voor constructieve payloads (patches, SQL, CI YAML) controleert het systeem niet alleen de payload-bytes. Het gebruikt Effect Adapters om het exacte semantische effect te berekenen dat de sink zal toepassen onder een vertrouwde snapshot (bijv. repository-status, policy epoch). De uitvoering wordt gebonden aan deze specifieke effect-verbintenis (effect commitment).
Manifest-Bound Gate: Een deterministische gate canonicaliseert het voorgestelde actie naar een Action Manifest. Dit manifest legt de actie-nonce, de digests van de veld-bewijslast, de digests van de effect-autorisatie en de digests van de aanroep-autoriteit vast.
Invocation Capabilities: De gate consumeert een manifest-gebonden Invocation Capability (een lineairiseerbare lease) alvorens tot uitvoering over te gaan. Dit voorkomt replay-attacks, ongeautoriseerde retries of veranderingen in de batch-cardinaliteit.

Provenance en Bewijsvoering

CXI houdt de herkomst (provenance) van invloed bij, niet alleen de herkomst van bytes.

Open-Weight Pad: Voor modellen met toegang tot interne staat (bijv. vLLM), genereert het systeem backend evidence records die de decoding van beschermde velden binden aan specifieke token-ranges en attention masks, om te garanderen dat geen onbetrouwbare context de generatie van het beschermde veld heeft beïnvloed.
Hosted/API Pad: Voor API's waarbij de interne staat verborgen is, vertrouwt het systeem op field-local construction evidence. Hier zorgt de host ervoor dat de schrijvers van velden enkel vertrouwde staat en geldige typed releases zien, terwijl opaque data wordt uitgesloten van de context van de schrijver.

3. Belangrijkste Bijdragen

Het artikel definieert en evalueert drie primaire bijdragen:

Definitie van CXI: Een formele vereiste dat beschermde selecties, door de sink geïnterpreteerde effecten en invoergebeurtenissen elk autoriteit moeten dragen voor dezelfde canonieke actie voordat een modelvoorstel uitvoerbaar wordt.
Manifest-Bound Admission System: Een ontwerp dat veld-bewijslast, exact-effect autorisatie en consumeerbare invocation capabilities samenvoegt in een enkele sink-beslissing, afgedwongen door een deterministische gate.
Uitgebreide Evaluatie: Een evaluatie over open-weight field-projection paden, AgentDojo live episodes, een code-agent exact-effect benchmark, ledger fault injection en hosted/API compatibiliteitstraces.

4. Evaluatieresultaten

De evaluatie maakt onderscheid tussen taakutiliteit (lost de agent het probleem op?) en admissie-integriteit (is ongeautoriseerde autoriteit de grens overgegaan?).

AgentDojo Live Episodes: Over 720 live episodes en 1.739 LLM-aanroepen observeerde CXI nul escapes op het gebied van veld, effect of aanroep binnen de beschermde admissies.
Code-Agent Exact-Effect Benchmark: In 40ù repository episodes leverde het systeem 231 veilige taakvolledigheden op. Cruciaal was dat er nul geobserveerde escapes waren op het gebied van veld, effect of aanroep.
- Opmerking over falen: Niet-voltooide taken werden toegeschreven aan parse-fouten (73 gevallen), gebrek aan effect-autorisatie (61 gevallen) of problemen met de taakkwaliteit (35 gevallen), niet aan beveiligingsschendingen.
Proposal Pressure: Het systeem observeerde aanzienlijke "proposal pressure" waarbij modellen probeerden ongeautoriseerde velden te selecteren (bijv. 196/300 ongeautoriseerde voorstellen in utilitaire adversariële settings). De gate blokkeerde echter alle dergelijke pogingen succesvol, wat resulteerde in nul uitgevoerd escapes.
Ledger Faults: In manifest-gebonden ledger-tests wees het systeem duplicaat-admissies succesvol af en onderdrukte het double-spends, wat de integriteit van de consumptie van de invocation capability bevestigt.
Vergelijking met Baselines:
- Alleen-schema validatie: Liet 100% van de ongeautoriseerde executies toe (W-afgeleide waarden vulden beschermde velden in).
- Argument-role provenance benaderingen: Faalden in het blokkeren van call-event en backend-binding fouten.
- CXI: Blokkeerde 20/20 aanvalscases terwijl 6/6 utiliteitsgevallen behouden bleven in mechanisme-baselines.

5. Betekenis en Claims

Het artikel positioneert CXI als een concreet systeemkenmerk voor gemedieerde sinks, in plaats van een algemene oplossing voor alle agent-veiligheidskwesties.

Expliciete Grens: CXI maakt de overgang van context naar uitvoering expliciet, controleerbaar en faalveilig (fail-closed). Het claimt niet dat validators volledig zijn, taken correct zijn of provider-internals observeerbaar zijn; het zorgt er eerder voor dat als een actie wordt uitgevoerd, dit komt omdat de specifieke autoriteitsketen voor die actie compleet is.
Bescheiden Omvang: De auteurs stellen expliciet dat taakkwaliteit, validator-volledigheid en externe exactly-once delivery aparte verplichtingen zijn. CXI zorgt ervoor dat de autoriteit om uit te voeren correct is, niet dat de inhoud van de uitvoering wenselijk is of dat de redenering van het model deugt.
Policy-Centrisch: Het systeem vertrouwt op vertrouwde policy-arbeid (veld-classificatie, declassifier-contracten, effect-validators). Het leidt geen ontbrekende policy af; als een veld niet geclassificeerd is of een sink niet gemedieerd wordt, vervalt de garantie.
Variatie in Bewijsvoering: Het artikel erkent dat bewijsvoering verschilt per deployment-regime. Open-weight deployments kunnen backend-handhaving bewijzen via attention masks, terwijl hosted/API deployments enkel de door de host geobserveerde constructie-grenzen kunnen bewijzen. Beiden voeden echter dezelfde manifest-gebonden gate-logica.

Samenvattend biedt CXI een mechanisme om autoriteitswitwassen te voorkomen door ervoor te zorgen dat onbetrouwbare tekst alleen via expliciete, gevalideerde en gescoped kanalen (typed releases, exact-effect verbintenissen en invocation capabilities) invloed kan uitoefenen op bijwerkingen die gebonden zijn aan één enkel canoniek actie-manifest.