GuardAgent: Deterministické presadzovanie bezpečnosti pre LLM agentov prostredníctvom vykonávania kódu

Hlavným bezpečnostným problémom každého agenta so spätným zápisom je: ako mu zabrániť v vykonaní akcie, ktorú nikdy nemal vykonať? GuardAgent (Xiang a kol., ICML 2025) navrhuje dedikovaného strážneho agenta (guardrail agent) — samostatného LLM agenta, ktorý pred vykonaním skontroluje každú akciu cieľového agenta voči súboru bezpečnostných pravidiel. Pre Bean Labs, kde je otázka „môže agent zapisovať do účtovnej knihy bez porušenia účtovných pravidiel?“ kľúčová, táto práca stojí priamo v centre nášho výskumného programu.

Práca

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning od Zhen Xianga a kolegov z UIUC, Emory a UC Berkeley predstavuje to, čo autori označujú za prvého všeobecne použiteľného strážneho agenta pre LLM systémy. Hlavná myšlienka je priamočiara: namiesto vkladania bezpečnostných obmedzení priamo do promptu cieľového agenta (kde môžu byť ignorované alebo zabudnuté), GuardAgent beží ako nezávislý agent, ktorý zachytáva akcie cieľového agenta a overuje ich voči stanoveným pravidlám.

Mechanizmus má dve fázy. Najprv LLM načíta bezpečnostné pravidlá a navrhovaný vstup alebo výstup cieľového agenta, potom zapíše podrobný akčný plán popisujúci, čo treba skontrolovať. V druhej fáze prevedie tento plán na vykonateľný kód v jazyku Python pomocou preddefinovanej sady volateľných funkcií. Externý interpret Pythonu spustí kód a vygeneruje deterministický verdikt áno/nie. Pamäťový modul ukladá minulé trojice úloh (pravidlo, plán, kód) a vyhľadáva podobné predchádzajúce príklady pomocou Levenshteinovej vzdialenosti, čo umožňuje učenie v kontexte (few-shot learning) bez potreby dodatočného jemného ladenia. Práca vyhodnocuje tento prístup na dvoch nových benchmarkoch vytvorených autormi.

Kľúčové myšlienky

• Vykonávanie kódu poráža verdikty v prirodzenom jazyku. Keď sú bezpečnostné rozhodnutia interpretované ako kód a nie ako text LLM, výstup je deterministický: engine Pythonu akciu buď povolí, alebo zablokuje, bez rizika halucinácií v poslednom kroku rozhodovania. LLM musí vygenerovať iba správny kód, nie konečnú správnu odpoveď.
• Dva vlastné benchmarky. EICU-AC (316 príkladov) testuje riadenie prístupu pre EHRAgenta nad zdravotníckou databázou s tromi používateľskými rolami a desiatimi databázami. Mind2Web-SC (200 príkladov) testuje šesť bezpečnostných pravidiel pre webového agenta SeeAct. Oba benchmarky boli vytvorené autormi špeciálne pre túto prácu.
• Presnosť označovania 98,7 % a 90,0 % (GPT-4) na EICU-AC a Mind2Web-SC. Dôležité je, že presnosť konečnej odpovede — či cieľový agent stále dokončí svoju úlohu vtedy, keď by mu to malo byť povolené — zostáva v oboch prípadoch na 100 %.
• Hardkódované bezpečnostné pravidlá výrazne zlyhávajú. Vloženie pravidiel priamo do systémového promptu cieľového agenta dosahuje presnosť iba 81,0 % / 77,5 % v dvoch benchmarkoch a spôsobuje, že cieľový agent zlyhá pri 29,2 % / 71,0 % svojich legitímnych úloh — čo je neprijateľný kompromis medzi užitočnosťou a bezpečnosťou.
• LlamaGuard je tu nesprávny nástroj. Baseline pre moderovanie obsahu dosahuje presnosť zhruba 50 % — čo je takmer náhoda — pretože bol navrhnutý pre škodlivý text, nie pre uvažovanie o tom, či akcia agenta porušuje konkrétne pravidlo riadenia prístupu.
• Odstránenie sady nástrojov stojí približne 8 bodov. Bez knižnice volateľných funkcií klesá úspešnosť GuardAgenta z 98,7 % na 90,8 % na EICU-AC, hoci to čiastočne kompenzuje autonómnym definovaním potrebných funkcií (68 % výstupov generuje kód aj bez výslovného pokynu, čo autori považujú za podporný dôkaz pre návrh založený na generovaní kódu).

Čo funguje — a čo nie

Hlavný architektonický poznatok — že vykonávanie kódu poskytuje deterministický bod presadzovania pravidiel — je skutočne užitočný a analýzy sú úprimné. Porovnanie s hardkódovanými bezpečnostnými pravidlami je obzvlášť presvedčivé: ukazuje, že naivné návrhy typu „stačí pridať pravidlá do promptu“ znižujú užitočnosť cieľa a zároveň zlyhávajú v spoľahlivom presadzovaní bezpečnosti.

Hodnotenie má však reálne limity. Dva benchmarky sú malé (316 a 200 príkladov) a autori vytvorili oba, čo predstavuje zjavné riziko pretrénovania (overfitting). EICU-AC je v podstate matica riadenia prístupu (rola × databáza), čo je štruktúrovaný, vymenovateľný problém — presne ten typ úloh, v ktorých kód prirodzene vyniká. Mind2Web-SC je zložitejší a údaj 90,0 % je tam podstatne menej pôsobivý, než sa na prvý pohľad zdá: autori priznávajú, že pravidlo 5 (pokrývajúce „filmy, hudbu a videá“) spôsobuje najviac zlyhaní, pretože vyžaduje široké uvažovanie o otvorenom svete. To je presne ten typ pravidla, ktorému by skutočný finančný agent čelil neustále.

Pamäťový modul vyhľadáva ukážky podľa zhody textových reťazcov, čo funguje dobre pre opakujúce sa typy pravidiel, ale pri skutočne nových pravidlách bude jeho výkon klesať. Celý rámec navyše predpokladá „dôveryhodný kontext“ — samotné bezpečnostné pravidlá musí poskytnúť dôveryhodný správca. Ak útočník dokáže pravidlá zmeniť alebo ak sada nástrojov obsahuje nebezpečné funkcie, GuardAgent neponúka žiadnu ochranu. Práca nemodeluje nepriateľskú manipuláciu s pravidlami. Nadväzujúce práce (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) už tieto medery zdôraznili, pričom ShieldAgent uvádza priemerné zlepšenie o 11,3 % oproti GuardAgentovi na širších benchmarkoch.

Prečo je to dôležité pre finančnú AI

Agent so spätným zápisom pre Beancount potrebuje viac než len bezpečnostný prompt — potrebuje mechanizmus na presadzovanie účtovných pravidiel, ktorý je štrukturálne oddelený od agenta vykonávajúceho prácu. Architektúra GuardAgenta sa na toto priamo hodí: strážny agent, ktorý pred vykonaním zápisu skontroluje každý navrhovaný účtovný zápis voči účtovným pravidlám (má dať == dal, žiadne účtovanie do uzavretých období, žiadna úprava odsúhlasených transakcií). Vrstva presadzovania cez vykonávanie kódu je tu obzvlášť atraktívna, pretože aritmetika podvojného účtovníctva je presne ten typ štruktúrovanej, vymenovateľnej kontroly, ktorú kód zvláda spoľahlivo a text LLM nie.

Úprimným obmedzením je, že GuardAgent predpokladá, že dokážete vopred vymenovať svoje bezpečnostné pravidlá a zakódovať ich do sady nástrojov. V produkčných nasadeniach Beancount sú niektoré obmedzenia implicitné (nasledujúce konvencie účtovnej knihy, ktoré si používateľ vytvoril za roky) a niektoré sú dynamické (rozpočty sa menia, štruktúry účtov sa reštrukturalizujú). GuardAgent nehovorí, ako zaobchádzať s obmedzeniami, ktoré sa nedajú vopred špecifikovať. To je ten ťažší problém a zostáva otvorený.

Čo si prečítať ďalej

• ShieldAgent (arXiv:2503.22738, ICML 2025) — stavia na GuardAgentovi s overiteľným uvažovaním o bezpečnostných pravidlách a ShieldAgent-Bench (2 tisíc príkladov v šiestich webových prostrediach); uvádza 11,3 % zlepšenie oproti GuardAgentovi a 64,7 % zníženie počtu volaní API.
• AGrail (arXiv:2502.11448) — navrhuje adaptívne bezpečnostné kontroly, ktoré sa prenášajú medzi úlohami agenta namiesto vyžadovania ukážok pre každú úlohu; priamo rieši obmedzenia škálovateľnosti GuardAgenta.
• ToolSafe (arXiv:2601.10156) — proaktívne mantinely na úrovni krokov so spätnou väzbou pre agentov volajúcich nástroje; jemnejší model než model zachytávania vstupu/výstupu GuardAgenta.