🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw is een dual-boundary beveiligingsarchitectuur voor tool-gebruikende LLM-agenten die ongeautoriseerde externe acties en blootstelling van gevoelige gegevens voorkomt door een vertrouwde gateway voor leesoperaties af te dwingen en een PREVIEW-to-COMMIT-protocol voor schrijfoperaties te hanteren, waarbij een succespercentage van nagenoeg nul wordt bereikt over meerdere benchmarks terwijl de taakutiliteit behouden blijft.

Oorspronkelijke auteurs: Yuhan Ma, Stefan Schmid

Gepubliceerd 2026-06-09

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yuhan Ma, Stefan Schmid

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 intelligente, maar onbetrouwbare persoonlijke assistent inhuurt (de LLM Agent) om je gevoelige taken af te handelen, zoals het betalen van rekeningen, het lezen van privé-e-mails of het beheren van je agenda.

Het probleem is dat deze assistent een onvoorspelbare factor is. Als je hen een document geeft met je bankrekeningnummer, kunnen ze per ongeluk (of kwaadwillig) die informatie hardop aan een vreemde doorgeven, of ze kunnen worden misleid door een verborgen notitie in een e-mail om jouw geld naar een oplichter te sturen.

Huidige beveiligingssystemen proberen de assistent meestal alleen tegen te houden bij het doen van de slechte handeling (zoals het versturen van het geld), maar ze falen vaak in het stoppen van de assistent bij het zien van het geheim in de eerste plaats. Zodra de assistent het geheim ziet, kunnen ze het aan andere programma's fluisteren of het in hun aantekeningen opschrijven voordat de bewaker de kans krijgt om in te grijpen.

SecureClaw is een nieuw beveiligingssysteem dat ontworpen is om beide problemen tegelijk op te lossen. Het behandelt het "zien" en het "doen" als twee aparte taken die elk een eigen slot vereisen.

Hier is hoe het werkt, met behulp van een eenvoudige analogie:

De Twee Sloten van SecureClaw

1. De "Blinddoek" voor het Lezen (De Gateway)

Stel je voor dat je assistent een geheime factuur moet bekijken om te weten welk bedrag er betaald moet worden.

De Oude Manier: Je overhandigt de assistent de werkelijke papieren factuur. Ze kunnen de cijfers lezen, ze opschrijven of zelfs hardop voorlezen aan een hacker die meeluistert.
De SecureClaw Manier: Je geeft hen niet de papieren factuur. In plaats daarvan geef je hen een mysterieus doosje (een "opaque handle") en een klein, gesaneerd briefje (een "bounded summary").
- Het briefje zegt: "Factuur van Leverancier A, $4.200, vervaldatum vrijdag."
- Het mysterieus doosje is een code die alleen de beveiligde kluis kan openen.
- De assistent kan hun werk plannen met behulp van het briefje en de code, maar ze kunnen het doosje niet openen om de echte details van de factuur te zien. Ze kunnen de echte cijfers niet kopiëren omdat ze ze nooit hebben gezien.

2. De "Dubbelcheck" voor het Doen (De Executor)

Stel je nu voor dat de assistent een e-mail wil sturen om die factuur te betalen.

De Oude Manier: De assistent schrijft de e-mail en drukt op "Verzenden". Als een hacker de assistent heeft misleid om het e-mailadres te veranderen naar dat van een oplichter, gaat het geld naar de oplichter.
De SecureClaw Manier: De assistent kan alleen een e-mail voorstellen. Ze schrijven een concept en zeggen: "Ik wil dit verzenden."
- Een Vertrouwde Bewaker (de Executor) pakt het concept op.
- De Bewaker controleert: "Heb je dit gevraagd? Is de ontvanger correct? Is het bedrag juist?"
- Cruciaal is dat de Bewaker de exacte details controleert tegen een verzegeld, onveranderlijk bewijs van wat er oorspronkelijk is goedgekeurd.
- Als de assistent na de goedkeuring stiekem het e-mailadres naar een oplichter heeft veranderd, ziet de Bewaker de afwijking en blokkeert de e-mail. Alleen de Bewaker heeft de macht om daadwerkelijk op "Verzenden" te drukken.

Waarom dit een Groot Ding is

Het onderzoek testte dit systeem tegen drie verschillende "hack-speeltjes" (AgentDojo, AgentLeak en ASB) waar aanvallers probeerden agenten te misleiden om gegevens te stelen of geld naar de verkeerde persoon te sturen.

Het Resultaat: SecureClaw was het enige systeem dat erin slaagde om 100% van de ongeautoriseerde geldtransfers te stoppen (0% succes voor de aanval) en verminderde het lekken van geheime gegevens tot bijna nul.
Het Geheime Ingrediënt: Het papier bewijst dat je niet met slechts één slot toe kunt.
- Als je alleen de "Dubbelcheck" hebt (het stoppen van het verzenden), kan de assistent het geheim nog steeds lezen en het via hun interne aantekeningen lekken.
- Als je alleen de "Blinddoek" hebt (het verbergen van het geheim), kan de assistent nog steeds worden misleid om een bericht naar de verkeerde persoon te sturen als ze de informatie niet hebben.
- SecureClaw gebruikt beide. Het houdt de geheimen verborgen voor de assistent en zorgt ervoor dat de assistent geen actie kan afdwingen zonder een laatste, vertrouwde controle.

Wat gebeurt er als het "Nee" zegt?

Soms blokkeert het systeem een verzoek omdat het verdacht lijkt. In het verleden zou dit simpelweg de hele workflow hebben gestopt, wat frustrerend was voor de gebruiker. SecureClaw heeft een "Safe Recovery" functie.

Als de Bewaker een verzoek blokkeert, zegt hij niet zomaar "Fout", maar geeft hij de assistent een veilig, vooraf goedgekeurd pad om het opnieuw te proberen.

Voorbeeld: "Ik kan die e-mail naar de vreemde niet verzenden. Maar ik kan wel een concept maken voor je om eerst door jou te laten controleren."
Dit houdt het werk gaande zonder de beveiligingsnormen te verlagen.

De Kern van het Verhaal

SecureClow is als het inhuren van een lijfwacht die een blinddoek draagt bij het lezen van je dagboek (zodat hij je geheimen niet uit zijn hoofd leert) en die de sleutels van je auto vasthoudt (zodat hij je niet naar een gevaarlijke plek kan rijden zonder eerst de kaart te controleren). Het scheidt het vermogen om te plannen van het vermogen om te handelen, waardoor wordt gewaarborgd dat zelfs als de assistent wordt misleid, de schade beperkt blijft.

Technische Samenvatting: SecureClaw

Probleemstelling

Tool-gebruikende Large Language Model (LLM) agenten worden geconfronteerd met twee afzonderlijke en niet-uitwisselbare beveiligingsfoutmodi die bestaande verdedigingen vaak niet tegelijkertijd aanpakken:

Ongeautoriseerde Externe Effecten: Het risico dat een agent, die mogelijk gecompromitteerd is door prompt injection of kwaadwillig runtime-gedrag, acties uitvoert (bijv. e-mails verzenden, geld overmaken) die niet geautoriseerd waren voor de specifie�e context, sessie of oproeper.
Runtime Tekstuele Blootstelling: Het risico dat gevoelige gegevens (bijv. facturen, medische dossiers) in klare tekst worden blootgesteld aan de onbetrouwbare LLM-runtime. Zelfs als een daaropvolgende actie wordt geblokkeerd, kan de runtime de geheime informatie al hebben "gelezen" en deze via interne kanalen (inter-agent berichten, gedeeld geheugen, logs) verspreiden die door output-only auditingmechanismen worden gemist.

Huidige verdedigingen beschermen doorgaans slechts één grens: ofwel de planner/runtime (via prompt filtering) ofwel de action sink (via argumentcontrole). Het artikel stelt dat het beschermen van de sink niet voorkomt dat er interne lekkage plaatsvindt als de runtime al toegang heeft gehad tot de ruwe geheimen, en het beschermen van de runtime voorkomt niet dat er ongeautoriseerde commits plaatsvinden als de sink ongemedieerd is.

Methodologie: SecureClaw Architectuur

SecureClaw introduceert een dual-boundary architectuur die de controle over externe effecten scheidt van de toegang tot gevoelige klare tekst. Dit berust op een vertrouwde infrastructuur (Gateway, Handle Store, Policy Engine, Executor) die onderscheid maakt van de onbetrouwbare agent-runtime.

1. Read Path: Opaque Handle Confinement

Mechanisme: Wanneer de runtime gevoelige gegevens opvraagt, onderschept de Trusted Gateway de leesopdracht. In plaats van de ruwe klare tekst terug te geven, slaat de gateway de gegevens op in een Trusted Handle Store en geeft een opaque handle (een hoog-entropische symbolische referentie) terug aan de runtime.
Declassificatie: Als de agent informatie nodig heeft die relevant is voor de taak, levert de gateway een beperkte samenvatting (bijv. "factuur van Leverancier A, $4,2k"). Deze samenvatting wordt behandeld als een expliciete declassificatie-interface, niet als een lek van klare tekst.
Restrictie: De runtime kan handles routeren en opslaan, maar kan ze niet derefereren om de ruwe geheimen te herstellen. Interne kanalen (C2, C5) dragen symbolische referenties, geen geheimen.

2. Write Path: PREVIEW→COMMIT Protocol

Mechanisme: De runtime stelt een effectieve actie voor (intentie + inputs). Een Trusted Gateway voegt geauthenticeerde context toe (oproeper, sessie, sink-velden) en canoniseert het verzoek naar een binding digest ( $h$ ).
Autorisatie: Een Policy Engine autoriseert de exacte canonieke aanvraag en retourneert een autorisatie-artifact dat gebonden is aan $h$ .
Executie: Een Trusted Executor is de enige component die de externe sink kan bereiken. Voordat hij commit, voert deze de volgende stappen uit:
1. Herrekent de binding digest $h$ .
2. Verifieert het autorisatie-artifact.
3. Controleert de versheid (freshness), replay-status en handle-resolutie.
4. Commit alleen als het verzoek exact overeenkomt met de geautoriseerde canonieke vorm.
Integriteit: Elke mutatie van het verzoek (bijv. het wijzigen van een ontvanger) na de preview verandert de canonieke vorm, waardoor het autorisatie-artifact ongeldig wordt en de executor in een 'fail-closed' status terechtkomt.

3. Deny-Aware Recovery

Om de bruikbaarheid te behouden wanneer acties worden geblokkeerd, gebruikt het systeem een deny-aware recovery mechanisme. In plaats van de workflow te beëindigen, geeft het systeem een gestructureerde weigering terug met een grove reden en een veilige volgende stap-hint (bijv. "concept voor bevestiging" in plaats van "verzenden"), waardoor de continuïteit van de workflow behouden blijft zonder de beveiligingsinvarianten te versoepelen.

Belangrijkste Bijdragen

Beveiligingsdecompositie: Het artikel identificeert twee niet-vervangbare beveiligingseisen voor tool-gebruikende agenten: de aanvraag-gebonden autorisatie van externe effecten en de inkapseling van gevoelige klare tekst weg van de onbetrouwbare runtime.
Dual-Boundary Architectuur: SecureClaw implementeert deze eisen via een vertrouwde gateway (voor read-confinement) en een vertrouwde executor (voor write-autorisatie), gebruikmakend van opaque handles en expliciete declassificatie.
Common-Harness Evaluatie: De auteurs evalueren SecureClaw tegen vier baselines (Plain, IPIGuard, DRIFT, Faramesh) over drie benchmarks (AgentDojo, AgentLeak, ASB) met een overeenkomstige harness om een eerlijke vergelijking te garanderen.

Experimentele Resultaten

Geëvalueerd op gpt-4o-mini met temperatuur 0:

Agent Security Bench (ASB): SecureClaw behaalde een 0% Attack Success Rate (ASR), waarmee het aanzienlijk presteerde ten opzien van de baselines (bijv. DRIFT met 87,75% ASR). Het behield een 88,90% utility op legitieme taken.
AgentDojo: Behaalde een 0,64% ASR (4/629 aanvallen), vergeleken met 2,38% voor de op één na beste baseline (DRIFT).
AgentLeak: Behaalde een 3,23% totale lek op de aangevallen parity lane. Cruciaal is dat het interne relay-lekken (C2 en C5) verminderde tot bijna nul (0,20% en 0,00% respectievelijk), terwijl baselines zoals Faramesh (die geen read-confinement heeft) een hoge interne lekkage vertoonden (92,74% op C2).
Ablatie-studies: Het verwijderen van het handle-mechanisme zorgde ervoor dat C2/C5-lekkage weer optrad, terwijl het verwijderen van de executie-grens de interne lekkage niet beïnvloedde maar wel faalde om ongeautoriseerde commits te stoppen. Dit bevestigt dat de twee mechanismen verschillende oppervlakken beschermen.
Robuustheid: In een bypass-suite van 29 adversariële scenario's (tampering met artifacts, replay, sessie-mixing) weigerde SecureClaw alle 25 aanvalspogingen terwijl het 4 legitieme controles toestond.
Overhead: De executor-verificatie duurt minder dan een milliseconde; single-service autorisatie voegt ongeveer 15 ms toe. Deze kosten zijn verwaarloosbaar vergeleken met de LLM-inferentielatenties (500–2000 ms).

Betekenis en Claims

Het artikel beweert dat het beveiligen van LLM-agenten een structurele scheiding vereist in plaats van runtime-lokale defensies.

Niet-vervangbaarheid: De evaluatie toont aan dat sink-zijde autorisatie en read-zijde inkapseling complementair zijn; noch kan de ene de andere vervangen. Een geblokkeerde commit kan een geheim dat al via het geheugen is doorgegeven niet ongedaan maken, en een handle kan een gecompromitteerde runtime niet voorkomen van het proberen uit te voeren van ongeautoriseerde acties.
Vertrouwensmodel: SecureClaw verschuift het vertrouwen van de onbetrouwbare runtime naar een minimale set vertrouwde componenten (Gateway, Handle Store, Policy Engine, Executor). Het claimt niet de semantische correctheid van policy-toegestane acties te garanderen (bijv. als een policy te grofmazig is, kan de agent nog steeds handelen op het verkeerde object), noch overleeft het de compromittering van zijn eigen vertrouwde componenten.
Residuen: De resterende fouten concentreren zich op het declassificatievlak (geautoriseerde samenvattingen die informatie onthullen) of policy-misalignment (geautoriseerde acties die semantisch fout zijn voor de intentie van de gebruiker), in plaats van het omzeilen van de kern-beveiligingsinvarianten.

De auteurs concluderen dat SecureClaw het enige geëvalueerde systeem in hun studie is dat tegelijkertijd ongeautoriseerde externe effecten naar nul/bijna nul brengt en interne tekstuele relay elimineert, terwijl een hoge taak-utility behouden blijft door deny-aware recovery.