GuardAgent: Deterministische handhaving van veiligheid voor LLM-agents via code-uitvoering

Het centrale veiligheidsprobleem voor elke write-back agent is: hoe voorkom je dat deze een actie onderneemt die nooit de bedoeling was? GuardAgent (Xiang et al., ICML 2025) stelt een speciale vangrail-agent voor — een afzonderlijke LLM-agent die elke actie van de doelagent controleert aan de hand van een set veiligheidsregels voordat deze wordt uitgevoerd. Voor Bean Labs, waar de vraag "kan de agent naar het grootboek schrijven zonder de boekhoudregels te schenden?" onbespreekbaar is, vormt dit artikel de kern van onze onderzoeksagenda.

Het artikel

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning, door Zhen Xiang en collega's van UIUC, Emory en UC Berkeley, introduceert wat de auteurs claimen als de eerste multifunctionele vangrail-agent voor LLM-systemen. Het basisidee is simpel: in plaats van veiligheidsbeperkingen rechtstreeks in de prompt van de doelagent te verwerken (waar ze genegeerd of vergeten kunnen worden), draait GuardAgent als een onafhankelijke agent die acties van de doelagent onderschept en verifieert tegen vastgesteld beleid.

Het mechanisme bestaat uit twee fasen. Eerst leest de LLM het veiligheidsbeleid en de voorgestelde input of output van de doelagent, en schrijft vervolgens een stapsgewijs actieplan waarin staat wat er gecontroleerd moet worden. Ten tweede wordt dat plan omgezet in uitvoerbare Python-code met behulp van een vooraf gedefinieerde toolbox met aanroepbare functies. Een externe Python-interpreter voert de code uit en produceert een deterministisch ja/nee-oordeel. Een geheugenmodule slaat eerdere taaktupels (beleid, plan, code) op en haalt vergelijkbare eerdere voorbeelden op met behulp van Levenshtein-afstand, wat few-shot in-context learning mogelijk maakt zonder extra fine-tuning. Het artikel evalueert de aanpak op twee nieuwe benchmarks die door de auteurs zijn geïntroduceerd.

Kernideeën

• Code-uitvoering is beter dan oordelen in natuurlijke taal. Wanneer veiligheidsbeslissingen worden weergegeven als code in plaats van LLM-tekst, is de output deterministisch: de Python-engine staat toe of blokkeert, zonder risico op hallucinaties in de uiteindelijke beslissingsstap. De LLM hoeft alleen correcte code te genereren, niet een correct eindantwoord.
• Twee aangepaste benchmarks. EICU-AC (316 voorbeelden) test toegangscontrole voor EHRAgent over een database in de gezondheidszorg met drie gebruikersrollen en tien databases. Mind2Web-SC (200 voorbeelden) test zes veiligheidsregels voor de SeeAct webagent. Beide zijn door de auteurs specifiek voor dit artikel gemaakt.
• 98,7% en 90,0% nauwkeurigheid van labels (GPT-4) op respectievelijk EICU-AC en Mind2Web-SC. Cruciaal is dat de nauwkeurigheid van de uiteindelijke respons — of de doelagent zijn taak nog steeds voltooit wanneer dit wel is toegestaan — in beide scenario's op 100% blijft.
• Hardgecodeerde veiligheidsregels falen jammerlijk. Het direct inbedden van beleid in de systeemprompt van de doelagent behaalt slechts 81,0% / 77,5% nauwkeurigheid op de twee benchmarks, en zorgt ervoor dat de doelagent in 29,2% / 71,0% van zijn legitieme taken faalt — een onacceptabele afweging tussen bruikbaarheid en veiligheid.
• LlamaGuard is hier het verkeerde gereedschap. De baseline voor contentmoderatie behaalt een nauwkeurigheid van ongeveer 50% — vergelijkbaar met gokken — omdat het is ontworpen voor schadelijke tekst, niet voor het redeneren over de vraag of een actie van een agent een specifieke toegangscontroleregel overtreedt.
• Het verwijderen van de toolbox kost ongeveer 8 punten. Zonder de bibliotheek met aanroepbare functies zakt GuardAgent van 98,7% naar 90,8% op EICU-AC, hoewel het dit deels compenseert door zelfstandig benodigde functies te definiëren (68% van de outputs genereert code, zelfs zonder expliciete instructie, wat de auteurs beschouwen als ondersteunend bewijs voor het ontwerp met codegeneratie).

Wat standhoudt — en wat niet

Het centrale architecturale inzicht — dat code-uitvoering een deterministisch handhavingspunt biedt — is oprecht nuttig, en de ablaties zijn eerlijk. De vergelijking met hardgecodeerde veiligheidsregels is bijzonder overtuigend: het laat zien dat naïeve ontwerpen waarbij "gewoon regels aan de prompt worden toegevoegd" de bruikbaarheid van het doel verslechteren, terwijl ze er nog steeds niet in slagen de veiligheid betrouwbaar te handhaven.

De evaluatie heeft echter reële beperkingen. De twee benchmarks zijn klein (316 en 200 voorbeelden), en de auteurs hebben beide zelf samengesteld, wat een duidelijk risico op overfitting met zich meebrengt. EICU-AC is in wezen een toegangscontrolematrix (rol × database), wat een gestructureerd, opsombaar probleem is — het soort ding waar code van nature goed in is. Mind2Web-SC is rommeliger, en het cijfer van 90,0% daar is aanzienlijk minder indrukwekkend dan het op het eerste gezicht lijkt: de auteurs geven toe dat regel 5 (over "films, muziek en video's") de meeste fouten veroorzaakt omdat hiervoor breed open-world redeneren nodig is. Dat is precies het soort regel waar een echte financiële agent constant mee te maken zou krijgen.

De geheugenmodule haalt demonstraties op via string-gelijkenis, wat prima werkt voor herhaalde beleidstypen, maar zal verslechteren bij echt nieuw beleid. Bovendien gaat het hele raamwerk uit van een "vertrouwde context" — de veiligheidsregels zelf moeten door een vertrouwde beheerder worden verstrekt. Als een aanvaller de regels kan wijzigen, of als de toolbox onveilige functies bevat, biedt GuardAgent geen bescherming. Het artikel modelleert geen vijandige manipulatie van beleid. Vervolgonderzoek (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) heeft deze hiaten al benadrukt, waarbij ShieldAgent een gemiddelde verbetering van 11,3% ten opzichte van GuardAgent rapporteert over bredere benchmarks.

Waarom dit belangrijk is voor financiële AI

De Beancount write-back agent heeft meer nodig dan een veiligheidsprompt — het heeft een mechanisme nodig om boekhoudregels af te dwingen dat structureel gescheiden is van de agent die het werk doet. De architectuur van GuardAgent sluit hier direct op aan: een guard-agent die elke voorgestelde journaalpost controleert tegen boekhoudregels (debet == credit, geen boekingen in afgesloten periodes, geen wijziging van afgeletterde transacties) voordat de schrijfopdracht wordt uitgevoerd. De handhavingslaag via code-uitvoering is hier bijzonder aantrekkelijk omdat dubbel boekhouden precies het soort gestructureerde, opsombare controle is die code betrouwbaar afhandelt en LLM-tekst niet.

De eerlijke beperking is dat GuardAgent ervan uitgaat dat u al uw veiligheidsregels vooraf kunt opsommen en in een toolbox kunt coderen. In productie-omgevingen van Beancount zijn sommige beperkingen impliciet (volgens grootboekconventies die de gebruiker in de loop der jaren heeft opgebouwd) en sommige zijn dynamisch (budgetten veranderen, rekeningstructuren worden herzien). GuardAgent vertelt u niet hoe u moet omgaan met beperkingen die niet vooraf kunnen worden gespecificeerd. Dat is het moeilijkere probleem, en dat blijft onopgelost.

Wat u hierna kunt lezen

• ShieldAgent (arXiv:2503.22738, ICML 2025) — bouwt voort op GuardAgent met verifieerbare redenering over veiligheidsbeleid en ShieldAgent-Bench (2K voorbeelden in zes webomgevingen); rapporteert 11,3% verbetering ten opzichte van GuardAgent en 64,7% reductie in API-aanroepen.
• AGrail (arXiv:2502.11448) — stelt adaptieve veiligheidscontroles voor die overdraagbaar zijn tussen agent-taken in plaats van demonstraties per taak te vereisen; pakt de schaalbaarheidsbeperking van GuardAgent direct aan.
• ToolSafe (arXiv:2601.10156) — proactieve vangrails op stap-niveau met feedback voor agents die tools aanroepen; fijnmaziger dan het interceptiemodel van GuardAgent voor input/output.