🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw ist eine Dual-Boundary-Sicherheitsarchitektur für werkzeugnutzende LLM-Agenten, die unbefugte externe Aktionen und die Preisgabe sensibler Daten verhindert, indem sie ein vertrauenswürdiges Gateway für Leseoperationen sowie ein PREVIEW-to-COMMIT-Protokoll für Schreiboperationen erzwingt und so eine Erfolgsrate von nahezu Null bei Angriffen über mehrere Benchmarks hinweg erreicht, während die Aufgaben-Utility aufrechterhalten wird.

Ursprüngliche Autoren: Yuhan Ma, Stefan Schmid

Veröffentlicht 2026-06-09

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yuhan Ma, Stefan Schmid

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen sehr intelligenten, aber unzuverlässigen persönlichen Assistenten (den LLM-Agenten) ein, um Ihre sensiblen Aufgaben zu erledigen, wie das Bezahlen von Rechnungen, das Lesen privater E-Mails oder die Verwaltung Ihres Kalenders.

Das Problem ist, dass dieser Assistent ein unberechenbarer Draufgänger ist. Wenn Sie ihm ein Dokument mit Ihrer Bankkontonummer geben, könnte er sie versehentlich (oder bösartig) einem Fremden laut vorlesen, oder er könnte durch eine versteckte Notiz in einer E-Mail dazu verleitet werden, Ihr Geld an einen Betrüger zu senden.

Heutige Sicherheitswächter versuchen meist nur, dem Assistenten das Ausführen der bösen Tat zu verhindern (wie das Senden des Geldes), aber sie scheitern oft daran, den Assistenten bereits beim Sehen des Geheimnisses zu stoppen. Sobald der Assistent das Geheimnis sieht, kann er es anderen Programmen zuflüstern oder es in seine Notizen schreiben, noch bevor der Wächter überhaupt die Chance hat, einzugreifen.

SecureClaw ist ein neues Sicherheitssystem, das beide Probleme gleichzeitig löst. Es behandelt das „Sehen“ und das „Tun“ als zwei getrennte Aufgaben, die zwei verschiedene Schlösser benötigen.

So funktioniert es, erklärt anhand einer einfachen Analogie:

Die zwei Schlösser von SecureClaw

1. Die „Augenbinde“ zum Lesen (Das Gateway)

Stellen Sie sich vor, Ihr Assistent muss eine geheime Rechnung einsehen, um zu wissen, wie viel er bezahlen muss.

Der alte Weg: Sie übergeben dem Assistenten die tatsächliche Papierrechnung. Er kann die Zahlen lesen, sie abschreiben oder sie sogar einem Hacker, der mithört, laut vorlesen.
Der SecureClaw-Weg: Sie geben ihm nicht das Papier. Stattdessen geben Sie ihm eine Geheimnisvolle Box (einen „undurchsichtigen Handle“) und eine winzige, bereinigte Notiz (eine „beschränkte Zusammenfassung“).
- Die Notiz besagt: „Rechnung von Anbieter A, 4.200 $, fällig am Freitag.“
- Die Geheimnisvolle Box ist ein Code, den nur der sichere Tresor entschlüsseln kann.
- Der Assistent kann seine Arbeit mithilfe der Notiz und des Codes planen, aber er kann die Box nicht öffnen, um die echten Details der Rechnung zu sehen. Er kann die echten Zahlen nicht kopieren, weil er sie nie gesehen hat.

2. Die „Doppelprüfung“ beim Handeln (Der Executor)

Nun stellt sich vor, der Assistent möchte eine E-Mail versenden, um diese Rechnung zu bezahlen.

Der alte Weg: Der Assistent schreibt die E-Mail und drückt auf „Senden“. Wenn ein Hacker den Assistenten dazu verführt hat, die E-Mail-Adresse in die eines Betrügers zu ändern, geht das Geld an den Betrüger.
Der SecureClay-Weg: Der Assistent kann die E-Mail nur vorschlagen. Er schreibt einen Entwurf und sagt: „Ich möchte dies senden.“
- Ein Vertrauenswürdiger Wächter (der Executor) nimmt den Entwurf entgegen.
- Der Wächter prüft: „Hast du darum gebeten, dies zu senden? Ist der Empfänger korrekt? Stimmt der Betrag?“
- Entscheidend ist, dass der Wächter die exakten Details mit einem versiegelten, unveränderlichen Beleg abgleicht, der ursprünglich genehmigt wurde.
- Wenn der Assistent versucht hätte, die E-Mail-Adresse nach der Genehmigung heimlich in die eines Betrügers zu ändern, erkennt der Wächter die Unstimmigkeit und blockiert die E-Mail. Nur der Wächter hat die Macht, tatsächlich auf „Senden“ zu drücken.

Warum das eine große Sache ist

Das Paper testete dieses System gegen drei verschiedene „Hacking-Spielplätze“ (AgentDojo, AgentLeak und ASB), bei denen Angreifer versuchten, Agenten dazu zu bringen, Daten zu stehlen oder Geld an die falschen Leute zu senden.

Das Ergebnis: SecureClaw war das einzige System, das 100 % der unbefugten Geldüberweisungen erfolgreich stoppte (0 % Erfolgsrate für Angriffe) und die Lecks von geheimen Daten fast auf Null reduzierte.
Das Erfolgsgeheimnis: Das Paper beweist, dass man nicht nur ein Schloss verwenden kann.
- Wenn man nur die „Doppelprüfung“ (das Stoppen des Sendens) hat, kann der Assistent das Geheimnis trotzdem noch lesen und es über seine internen Notizen nach außen tragen.
- Wenn man nur die „Augenbinde“ (das Verbergen des Geheimnisses) hat, kann der Assistent dennoch dazu verleitet werden, eine Nachricht an die falsche Person zu senden, wenn er die Informationen gar nicht erst besitzt.
- SecureClaw nutzt beides. Es hält die Geheimnisse vor dem Assistenten verborgen und stellt gleichzeitig sicher, dass der Assistent keine Handlung erzwingen kann, ohne eine letzte, vertrauenswürdige Prüfung zu durchlaufen.

Was passiert, wenn es „Nein“ sagt?

Manchmal blockiert das System eine Anfrage, weil sie verdächtig aussieht. In der Vergangenheit hätte dies möglicherweise einfach den gesamten Arbeitsablauf gestoppt, was den Nutzer frustriert hätte. SecureClaw verfügt jedoch über eine „Safe Recovery“-Funktion (Sichere Wiederherstellung).

Wenn der Wächter eine Anfrage blockiert, sagt er nicht einfach nur „Fehler“, sondern gibt dem Assistenten einen sicheren, vorab genehmigten Pfad vor, um es erneut zu versuchen.

Beispiel: „Ich kann diese E-Mail nicht an den Fremden senden. Aber ich kann einen Entwurf für Sie vorbereiten, damit Sie ihn zuerst prüfen können.“
Dies hält die Arbeit in Gang, ohne die Sicherheitsstandards zu senken.

Das Fazste

SecureClaw ist wie ein Leibwächter, der eine Augenbinde trägt, wenn er Ihr Tagebuch liest (damit er sich nicht Ihre Geheimnisse merkt), und der gleichzeitig die Schlüssel zu Ihrem Auto hält (damit er Sie nicht ohne vorherige Prüfung auf einen gefährlichen Ort fährt). Es trennt die Fähigkeit zu planen von der Fähigkeit zu handeln und stellt sicher, dass selbst wenn der Assistent getäuscht wird, der Schaden begrenzt bleibt.

Technisches Resümee: SecureClaw

Problemstellung

Werkzeugnutzende Large Language Model (LLM) Agenten stehen vor zwei distinkten und nicht austauschbaren Sicherheitsfehlermodi, die bestehende Abwehrmechanismen oft nicht gleichzeitig adressieren können:

Unbefugte externe Effekte: Das Risiko, dass ein Agent – potenziell kompromittiert durch Prompt Injection oder adversarielles Laufzeitverhalten – Aktionen ausführt (z. B. E-Mails versenden, Gelder überweisen), die für den spezifischen Kontext, die Sitzung oder den Aufrufer nicht autorisiert waren.
Exposition von Klartext zur Laufzeit: Das Risiko, dass sensible Daten (z. B. Rechnungen, medizinische Unterlagen) dem vertrauensunwürdigen LLM-Runtime im Klartext ausgesetzt werden. Selbst wenn eine darauffolgende Aktion blockiert wird, kann die Runtime die Geheimnisse bereits „gelesen“ haben und sie über interne Kanäle (Inter-Agent-Nachrichten, gemeinsam genutzter Speicher, Protokolle) weiterleiten, welche von rein ausgabebasierten Audit-Mechanismen nicht erfasst werden.

Aktuelle Abwehrmechanismen schützen typischerweise nur eine Grenze: entweder den Planner/die Runtime (via Prompt-Filterung) oder den Action-Sink (via Argumentprüfung). Das Paper argumentiert, dass der Schutz des Sinks nicht verhindert, dass interne Leckagen entstehen, wenn die Runtime bereits Zugriff auf Rohgeheimnisse hatte, und dass der Schutz der Runtime nicht verhindert, dass unbefugte Commits erfolgen, wenn der Sink unmediiert bleibt.

Methodik: SecureClaw-Architektur

SecureClaw führt eine Dual-Boundary-Architektur ein, die die Kontrolle über externe Effekte von dem Zugriff auf sensible Klartextdaten trennt. Sie stützt sich auf eine vertrauenswürdige Infrastruktur (Gateway, Handle Store, Policy Engine, Executor), die vom vertrauensunwürdigen Agenten-Runtime unterscheidbar ist.

1. Read-Pfad: Opake Handle-Konfinierung

Mechanismus: Wenn die Runtime sensible Daten anfordert, unterbricht ein Trusted Gateway den Lesevorgang. Anstatt die Rohdaten im Klartext zurückzugeben, speichert das Gateway die Daten in einem Trusted Handle Store und gibt einen opaken Handle (eine hoch-entropische symbolische Referenz) an die Runtime zurück.
Deklassifizierung: Falls der Agent für die Aufgabenplanung relevante Informationen benötigt, stellt das Gateway eine beschränkte Zusammenfassung bereit (z. B. „Rechnung von Anbieter A, 4,2k $“). Diese Zusammenfassung wird als explizites Deklassifizierungs-Interface behandelt, nicht als Klartext-Leckage.
Beschränkung: Die Runtime kann Handles routen und speichern, aber sie kann sie nicht dereferenzieren, um die Rohgeheimnisse wiederherzustellen. Interne Kanäle (C2, C5) transportieren symbolische Referenzen, keine Geheimnisse.

2. Write-Pfad: PREVIEW→COMMIT-Protokoll

Mechanismus: Die Runtime schlägt eine effektive Aktion vor (Intention + Inputs). Ein Trusted Gateway fügt authentifizierten Kontext (Aufrufer, Sitzung, Sink-Felder) hinzu und kanonisiert die Anfrage zu einem Bindungs-Digest ( $h$ ).
Autorisierung: Eine Policy Engine autorisiert die exakte kanonisierte Anfrage und gibt ein Autorisierungs-Artefakt zurück, das an $h$ gebunden ist.
Ausführung: Ein Trusted Executor ist die einzige Komponente, die die externe Sink erreichen kann. Vor dem Commit:
1. Berechnet er den Bindungs-Digest $h$ neu.
2. Verifiziert er das Autorisierungs-Artefakt.
3. Prüft er Aktualität (Freshness), Replay-Status und Handle-Auflösung.
4. Führt den Commit nur aus, wenn die Anfrage exakt mit der autorisierten kanonisierten Form übereییchtimmt.
Integrität: Jede Mutation der Anfrage (z. B. Änderung eines Empfängers) nach dem Preview verändert die kanonisierte Form, was das Autorisierungs-Artefakt ungültig macht und dazu führt, dass der Executor „fail-closed“ reagiert.

3. Ablehnungsbewusste Wiederherstellung (Deny-Aware Recovery)

Um die Nützlichkeit bei blockierten Aktionen aufrechtzuerhalten, nutzt das System einen deny-aware recovery Mechanismus. Anstatt den Workflow zu terminieren, gibt das System eine strukturierte Ablehnung mit einem groben Grund und einem sicheren nächsten Schritt-Hinweis zurück (z. B. „Entwurf zur Bestätigung“ statt „senden“), wodurch die Kontinuität des Workflows gewahrt bleibt, ohne die Sicherheitsinvarianten zu lockern.

Zentrale Beiträge

Sicherheitsdekomposition: Das Paper identifiziert zwei nicht substituierbare Sicherheitsanforderungen für werkzeugnutzende Agenten: die an die Anfrage gebundene Autorisierung externer Effekte und die Konfinierung von sensitivem Klartext fernab der vertrauensunwürdigen Runtime.
Dual-Boundary-Architektur: SecureClaw implementiert diese Anforderungen über ein Trusted Gateway (für die Read-Konfinierung) und einen Trusted Executor (für die Write-Autorisierung) unter Verwendung von opaken Handles und expliziter Deklassifizierung.
Common-Harness-Evaluierung: Die Autoren evaluieren SecureClaw gegen vier Baselines (Plain, IPIGuard, DRIFT, Faramesh) über drei Benchmarks (AgentDojo, AgentLeak, ASB) unter Verwendung eines abgestimmten Harnesses, um einen fairen Vergleich zu gewährleisten.

Experimentelle Ergebnisse

Evaluierung auf gpt-4o-mini mit Temperatur 0:

Agent Security Bench (ASB): SecureClaw erreichte eine Attack Success Rate (ASR) von 0 %, was die Baselines (z. B. DRIFT mit 87,75 % ASR) signifikant übertrifft. Dabei wurde eine Nützlichkeit von 88,90 % bei benignen Aufgaben beibehalten.
AgentDojo: Erzielte eine ASR von 0,64 % (4/629 Angriffe), verglichen mit 2,38 % für die nächstbeste Baseline (DRIFT).
AgentLeak: Erzielte eine Gesamtleckage von 3,23 % auf der angegriffenen Paritätsspur. Entscheidend ist, dass es interne Relay-Leckagen (C2 und C5) auf nahezu Null reduzierte (0,20 % bzw. 0,00 %), während Baselines wie Faramesh (welches keine Read-Konfinierung besitzt) eine hohe interne Leckage zeigten (92,74 % bei C2).
Ablationsstudien: Das Entfernen des Handle-Mechanismus führte zum Wiederauftreten von C2/C5-Leckagen, während das Entfernen der Ausführungsgrenze die interne Leckage nicht beeinflusste, aber die unbefugten Commits nicht verhinderte. Dies bestätigt, dass die beiden Mechanismen unterschiedliche Oberflächen schützen.
Robustheit: In einer Bypass-Suite mit 29 adversariellen Szenarien (Manipulation von Artefakten, Replay, Session-Mixing) verweigerte SecureClaw alle 25 Angriffsszenarien, erlaubte jedoch 4 legitime Kontrollen.
Overhead: Die Executor-Verifizierung liegt im Sub-Millisekundenbereich; die Single-Service-Autorisierung fügt ca. 15 ms hinzu. Diese Kosten sind vernachlässigbar im Vergleich zu den LLM-Inferenz-Latenzen (500–2000 ms).

Bedeutung und Ansprüche

Das Paper behauptet, dass die Sicherung von LLM-Agenten eine strukturelle Trennung erfordert und nicht nur lokale Laufzeit-Abwehren.

Nicht-Substituierbarkeit: Die Evaluierung zeigt, dass die Sink-seitige Autorisierung und die Read-seitige Konfinierung komplementär sind; keine kann die andere ersetzen. Ein blockierter Commit kann ein bereits durch den Speicher weitergeleitetes Geheimnis nicht rückgängig machen, und ein Handle kann nicht verhindern, dass eine kompromittierte Runtime versucht, unbefugte Aktionen auszuführen.
Vertrauensmodell: SecureClaw verlagert das Vertrauen von der vertrauensunwürdigen Runtime auf eine minimale Menge vertrauenswürdiger Komponenten (Gateway, Handle Store, Policy Engine, Executor). Es beansprucht nicht, die semantische Korrektheit von politisch erlaubten Aktionen zu garantieren (z. B. wenn eine Policy zu grob gefasst ist, könnte der Agent dennoch auf das falsche Objekt agieren), noch überlebt es die Kompromittierung seiner vertrauenswürdigen Komponenten.
Residuen: Die verbleibenden Fehler konzentrieren sich auf die Deklassifizierungsebene (autorisierte Zusammenfassungen, die Informationen preisgeben) oder die Policy-Fehlausrichtung (autorisierte Aktionen, die semantisch falsch für die Intention des Nutzers sind), anstatt auf Umgehungen der Kern-Sicherheitsinvarianten.

Die Autoren kommen zu dem Schluss, dass SecureClaw das einzige in ihrer Studie evaluierte System ist, das gleichzeitig unbefugte externe Effekte auf Null/nahezu Null drückt und interne Klartext-Weiterleitungen eliminiert, während es durch die deny-aware recovery eine hohe Aufgaben-Nützlichkeit beibehält.