🤖 AI

LACUNA: Safe Agents as Recursive Program Holes

LACUNA is een veilig programmeermodel voor LLM-agenten dat acties behandelt als getypeerde programmagaten die door het model worden ingevuld en via statische typecontrole worden gevalideerd voordat ze worden uitgevoerd, waardoor de besturingsflow van agenten wordt verenigd met gegenereerde code terwijl runtime-fouten worden voorkomen en de toegang tot hulpmiddelen wordt beperkt.

Oorspronkelijke auteurs: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

Gepubliceerd 2026-05-28

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

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 de CEO bent van een bedrijf en je huurt een briljante maar iets onbetrouwbare assistent (de AI) in om je werk te doen.

De Oude Manier (Huidige Agents):
Meestal geef je de assistent een specifieke, kleine instructie: "Bel het telefoonbedrijf." De assistent doet precies dat, stopt dan en wacht op je volgende bevel. Jij houdt het klembord vast, bepaalt de volgorde van taken en houdt de sleutels van het kantoor. De assistent kan niet beslissen om in plaats daarvan de bank te bellen, of om de kantoorregels te herschrijven, omdat ze slechts één knop per keer kunnen indrukken.

Het Probleem:
Soms raakt de assistent in de war door een lastige notitie die je schreef (een "prompt injection"), of ze halverwege een taak en maken een fout, waardoor het kantoor in een rommelige, inconsistente toestand achterblijft. Omdat de assistent alleen knoppen mag indrukken, kunnen ze het gebouw niet vernielen, maar kunnen ze toch veel chaos veroorzaken binnen de ruimte waarin ze zich bevinden.

De Nieuwe Manier (LACUNA):
Het paper introduceert LACUNA, wat de relatie verandert. In plaats van de assistent één knop te geven om in te drukken, geef je ze een lege ruimte in een contract (een "getypte holte") en zeg je: "Vul deze ruimte met de code die je nodig hebt om dit probleem op te lossen, maar het moet perfect passen in ons juridische contract."

Hier is hoe het werkt, met eenvoudige analogieën:

1. Het "Magische Contract" (Getypte Holtes)

Stel je voor dat je een contract hebt dat zegt: "Het eindresultaat van dit gedeelte moet een Lijst met Getallen zijn."

Je vraagt de AI: "Zoek de priemgetallen in deze lijst."
De AI schrijft een heel alinea met instructies (code) om het op te lossen.
De Veiligheidscontrole: Voordat de AI iets daadwerkelijk mag doen, controleert een strenge Inspecteur (de compiler) het alinea van de AI.
- Resulteert het alinea daadwerkelijk in een "Lijst met Getallen"? Als de AI probeert een "Lijst met Appels" terug te geven, verwierpt de Inspecteur het direct.
- Probeerde de AI een tool te gebruiken die ze niet mogen aanraken? (bijvoorbeeld proberen een bestand te openen waar ze geen sleutel voor hebben). De Inspecteur vangt dit ook op.
- Het Resultaat: Als de AI een fout maakt, wordt het contract verworpen voordat er enige actie plaatsvindt. Het kantoor blijft schoon. De AI krijgt de afwijzingsmelding, probeert het opnieuw en schrijft een beter alinea.

2. De "Alles-of-Niets" Regel

Op de oude manier, als een AI probeerde "Een bestand te verwijderen" en daarna "Een som te berekenen", en de berekening faalde, zou het bestand misschien al verwijderd zijn.
Bij LACUNA is het als een enkel, ondeelbaar blok klei.

De AI beeldt het hele blok uit.
De Inspecteur controleert het hele blok in één keer.
Als enig deel van het beeldhouwwerk verkeerd is (de verkeerde vorm, het verkeerde materiaal), wordt het hele blok weggegooid. Er gebeurt niets. Het kantoor blijft precies zoals het was voordat de AI begon. Dit voorkomt "halfafgewerkte" rampen.

3. De "Sleutelbos" (Mogelijkheden)

Het paper spreekt ook over Mogelijkheden. Stel je voor dat de AI een specifieke set sleutels (een sleutelbos) krijgt voor de baan.

Als de baan is "Lees het menu", krijgt de AI de "Menu-sleutel".
Als de baan is "Verstuur een e-mail", krijgt de AI de "E-mail-sleutel".
Zelfs als de AI wordt bedrogen door een slechte notie die zegt: "Gebruik de Bank-sleutel om geld te stelen", kunnen ze het fysiek niet doen. Ze hebben de Bank-sleutel niet in hun zak. De Inspecteur controleert hun sleutelbos voordat ze de slot mogen draaien.
Dit betekent dat zelfs als een hacker de AI bedriegt om iets slechts te proberen, de AI letterlijk de "sleutels" mist om die deuren open te maken.

4. De "Gestapelde Russische Poppen" (Recursie)

De AI kan code schrijven die meer instructies voor zichzelf bevat.

Je vraagt: "Schrijf een rapport over drie onderwerpen."
De AI schrijft een plan dat zegt: "Eerst zal ik de AI vragen om Onderwerp A te onderzoeken, dan Onderwerp B, dan Onderwerp C, en ze uiteindelijk te combineren."
Elk van die kleinere verzoeken is ook een "holte" die door de Inspecteur wordt gecontroleerd voordat het wordt uitgevoerd. Het is als een set Russische poppen, waarbij elke enkele pop wordt geïnspecteerd voordat deze mag worden geopend.

Wat het Paper Eigenlijk Vond

De onderzoekers testten dit systeem (LACUNA) met een programmeertaal genaamd Scala 3.

Veiligheid: Ze ontdekten dat de "Inspecteur" ongeveer 8,6% van de pogingen van de AI opving voordat ze konden worden uitgevoerd. Dit waren pogingen die ofwel de verkeerde vorm hadden, of probeerden tools te gebruiken waar de AI geen toestemming voor had.
Opnieuw proberen: Wanneer de AI een fout maakte, vroeg het systeem het om het opnieuw te proberen. Gemiddeld duurde het slechts 0,7 pogingen om een geldig antwoord te krijgen.
Prestaties: Het systeem loste ongeveer 27% van de moeilijke onderzoekstaken op en 76% van de klantenservicetaken. Dit was ongeveer hetzelfde als andere standaard AI-agents, wat bewijst dat het toevoegen van deze strenge veiligheidscontrole de AI niet "dommer" maakte, alleen veiliger.
Beveiliging: Ze testten het systeem tegen hackers die probeerden de AI te bedriegen (prompt injection). Omdat de AI werd beperkt door zijn "sleutelbos" (mogelijkheden), konden de hackers de AI niet krijgen om dingen buiten zijn toegestane scope te doen, zelfs niet als ze de AI succesvol bedroegen om het te proberen.

De Vang (Beperkingen)

Het paper geeft een paar dingen toe:

Het is niet perfect: De Inspecteur controleert of de AI de regels heeft gevolgd (gebruikte het de juiste tools? gaf het het juiste type antwoord terug?), maar het controleert niet of de AI het juiste ding logisch heeft gedaan. Als de AI een perfecte code schrijft die de verkeerde wiskunde berekent, laat de Inspecteur het door.
Het heeft een slimme AI nodig: Als de AI niet erg goed is in het schrijven van code, wordt het vaak afgewezen en zal het proces traag zijn.
Het is trager: Omdat het systeem elke keer moet stoppen, controleren en opnieuw controleren, kost het meer tijd en rekenkracht dan gewoon de AI een knop te laten indrukken.

Samenvattend: LACUNA verandert de AI van een knop-indrukker in een aannemer die een volledig plan moet indienen voor goedkeuring voordat er werk wordt uitgevoerd. Als het plan tegen de regels indruist, begint het werk nooit, waardoor het systeem veilig blijft voor fouten en trucs.

Technische Samenvatting: LACUNA: Veilige Agenten als Recursieve Programmagaten

Probleemstelling

Huidige agents op basis van Large Language Models (LLM's) staan voor een fundamentele architecturale splitsing tussen de runtime die de agentlus aandrijft en de code die het model schrijft. In dominante benaderingen zoals ReAct bezit de runtime de controleflow, contextbeheer en tool-dispatch, terwijl het model slechts individuele tooloproepen of redeneerstappen genereert. Bij "code-as-action"-agenten schrijft het model code om tools en logica te compositeren, maar blijft deze code distinct van de runtime.

Deze schepping creëert een veiligheidsdilemma. Als de runtime de lus strikt controleert, mist de agent expressiviteit. Als het model de runtime zelf vormt om expressiviteit te vergroten, escaleren de veiligheidsrisico's: een model dat wordt afgeleid door prompt-injectie, een toolopropfout of een gedeeltelijke mislukking, kan de omgeving in een inconsistente staat achterlaten of de runtime compromitteren. Bestaande verdedigingsmechanismen (sandboxen, beperkte interpreters, beleidslanguages) werken vaak gefragmenteerd, opererend op runtime of op inputs, en geen enkel mechanisme verifieert een gehele gegenereerde actie tegen de omringende programmaccontext voordat de uitvoering begint.

Methodologie: LACUNA

De auteurs stellen LACUNA voor, een programmeermodel dat de splitsing tussen agent-runtime en door het model geschreven code sluit, terwijl de veiligheid behouden blijft via statische typering. De kernprimitief is een getypeerd "gat" in het hostprogramma:

def agent[T](task: String): T

Kernmechanisme

Getypeerde Gaten: Een agentoproep fungeert als een placeholder waar het omringende programma statisch een waarde van het type T verwacht. De LLM wordt geprompt om Scala-code te genereren die deze waarde produceert.
Contextbewuste Compilatie: Wanneer de uitvoering de agent-oproep bereikt, genereert de LLM code op basis van de natuurlijke taal task, het verwachte type T en de live lexicaal scope (variabelen, functies, tools en imports die op dat specifieke punt beschikbaar zijn).
Pre-uitvoering Verificatie: De gegenereerde code wordt gecompileerd door de hostcompiler (Scala 3) in de context van het omringende programma voordat deze ooit wordt uitgevoerd.
- Typecontrole: De code moet een waarde van het type T produceren.
- Scopecontrole: Alle gebruikte namen moeten in scope zijn.
- Capaciteitscontrole: Indien ingeschakeld, zorgt capture-checking ervoor dat de code alleen toegang heeft tot resources (bestanden, netwerk, tools) die expliciet zijn verleend in de lexicaal scope.
Alles-of-Nothing Uitvoering: Als de code alle controles passeert, wordt deze uitgevoerd. Als deze faalt (bijvoorbeeld type-mismatch, ontbrekende tool, ongeautoriseerde toegang), wordt het gehele fragment afgewezen. Er vindt geen gedeeltelijke uitvoering plaats, wat inconsistente staten voorkomt. Compilerdiagnostiek wordt teruggevoerd naar de LLM om een retry-lus aan te sturen.

Implementatie

Het prototype is gebouwd in Scala 3, waarbij gebruik wordt gemaakt van twee specifieke functies:

In-process recompilatie: De mogelijkheid om de compiler binnen een draaiend programma aan te roepen om een string broncode te splitten en te compileren tegen de huidige context.
Capture Checking: Een mechanisme om bij te houden welke effecten en resources een codefragment mag gebruiken, en zo op capaciteit gebaseerde beveiliging af te dwingen.

De agent-primitief is een dunne wrapper rond een lagere-level eval-operatie. Het beheert de promptconstructie (inclusief de omsluitende bron en besch beschikbare bindingen), roept de LLM aan, geeft het resultaat door aan eval en behandelt de retry-lus bij compilatiefouten.

Belangrijkste Bijdragen

Een Code-as-Action Model met Statische Garanties: Een model waarbij de LLM acties schrijft als code die loopt als onderdeel van zijn eigen runtime, geverifieerd op de aanroepplaats voordat uitvoering plaatsvindt.
Veiligheidsanalyse: Demonstreert dat pre-uitvoering afwijzing van niet-beschikbare namen en type-mismatches, gecombineerd met atomaire uitvoering (geen gedeeltelijke runs), sterke veiligheidsgaranties biedt. Het toont verder aan hoe capaciteitsscoping de autoriteit en informatiestroom van de agent begrenst.
Expressiviteit via Gewone Controleflow: Toont aan dat geneste agentoproepen en standaard codeconstructies complexe agentpatronen kunnen uitdrukken (ReAct-lussen, sub-agenten, vaardigheden, parallelle decompositie, multi-model planning) zonder dat een apart agentprotocol nodig is.
Empirische Evaluatie: Een Scala 3-implementatie geëvalueerd op verifiërtestcases, BrowseComp-Plus (moeilijke informatieverwerving) en $\tau^2$ -bench (meerdere-omwenteling tool-gebruikende conversaties).

Resultaten

De evaluatie benadrukt de afweging tussen veiligheid, expressiviteit en modelcapaciteit:

Veiligheid en Afwijzingspercentages: Op BrowseComp-Plus werden 8,6% van de generaties voor uitvoering afgewezen vanwege type- of scopefouten. Het systeem had gemiddeld 0,7 retries per query, met een end-to-end compilatiesuccespercentage van 91,4%. Dit bevestigt dat de compiler effectief slecht-getypeerde of buiten-scope acties blokkeert.
Prestaties bij Complexe Taken:
- BrowseComp-Plus: Met het deepseek-flash-model behaalde LACUNA 27,1% nauwkeurigheid, vergelijkbaar met baseline-agenten, terwijl het echte meerstapsresearch aandreef (gemiddeld 5,9 rondes, 15,5 zoekopdrachten).
- $\tau^2$ -bench: Over 392 taken in vier domeinen (Retail, Luchtvaart, Telecom, Tel.-WF) loste LACUNA 76,0% van de taken op met een capabel model, presterend op gelijke hoogte met een referentie tool-callende agent.
Modelafhankelijkheid: Het succes van het systeem is sterk afhankelijk van de programmeercapaciteit van het model. Zwakkere modellen (bijv. gemini-3.1-flash-lite) hadden moeite met complexe domeinen (bijv. 89% afwijzingspercentage in telecom), wat leidde tot lagere oplossingspercentages. De veiligheidsgarantie blijft gelden ongeacht de competentie van het model (gebroken pogingen worden nooit uitgevoerd), maar vooruitgang stopt als het model geen geldige code kan genereren.
Adversariële Robuustheid: Bij prompt-injectietests (AgentDojo) beperkte de capaciteitslaag de acties van de agent succesvol tot zijn verleende scope. Zelfs wanneer beïnvloed door ingevoegde content, kon de agent geen toegang krijgen tot resources buiten zijn lexicaal scope.

Betekenis en Beweringen

Het artikel positioneert LACUNA niet als vervanging voor bestaande agentarchitecturen, maar als een veiligere, flexibeler fundament.

Unificatie van Uitvoering en Redenering: Door programma-uitvoering en modelredenering te fuseren in één proces waarbij het model de controleflow schrijft, stelt LACUNA agenten in staat expressiever te zijn terwijl de veiligheidsgaranties van de hosttaal behouden blijven.
Veiligheid via Compilatie: De primaire bijdrage is het verschuiven van veiligheid van runtime-sandboxen naar pre-uitvoering statische verificatie. Een afgewezen fragment laat de omgeving onaangetast, en de diagnostiek van de compiler drijft zelfcorrectie aan.
Capaciteitsveiligheid: Het systeem toont aan dat "minst autoriteit" kan worden afgedwongen via lexicaal scoping en capture-checking, waardoor wordt begrensd wat een adversariële of foutieve model kan doen, zelfs als het wordt beïnvloed door prompt-injectie.
Beperkte Beperkingen: De auteurs erkennen dat "goed-getypeerd" niet betekent "correct" (semantische fouten worden niet opgevangen), dat het systeem afhankelijk is van de programmeervaardigheid van het model (die varieert per taal en domein), en dat resource-uitputting (latentie, oneindige recursie) moet worden beheerd via runtime-budgetten in plaats van typesystemen.

Kortom, LACUNA stelt dat het behandelen van agentacties als getypeerde gaten in een statisch getypeerde hosttaal toelaat tot een recursief, expressief agentontwerp waarbij veiligheid wordt gegarandeerd door de soundness van de compiler in plaats van runtime-heuristieken.