Laufzeitverteidigung für werkzeuggestützte Agenten

Vor einer Woche habe ich 50 MCP-Schwachstellen über SSRF, Tool Poisoning und Trust-Bypass-Muster veröffentlicht. Die implizite Schlussfolgerung war ernüchternd: Die Angriffsfläche wächst schneller als die Audit-Kapazität. Ein neues Paper von Wei Zhao, Zhe Li, Peixin Zhang und Jun Sun schlägt eine strukturelle Antwort vor — und ein realer Telemetrie-Vorfall in derselben Woche demonstriert genau, warum diese Antwort wichtig ist.

ClawGuard, am 13. April auf arxiv veröffentlicht, ist ein Laufzeit-Sicherheitsframework, das ein vom Benutzer bestätigtes Regelwerk an jeder Tool-Call-Grenze durchsetzt.¹ In der evaluierten Konfiguration wendet das Framework grundlegende Zugriffskontrollregeln an — Blockierung unautorisierter Dateizugriffe, Verhinderung von Credential-Exfiltration, Einschränkung von Netzwerkaufrufen — bevor ein externer Tool-Aufruf erfolgt. Keine Modellanpassung. Keine Infrastrukturänderung. Kein sicherheitsspezifisches Fine-Tuning.¹ Die Autoren testeten mit AgentDojo, SkillInject und MCPSafeBench unter Verwendung von fünf aktuellen LLMs.¹ Das Paper beschreibt außerdem eine aufgabenspezifische Regelableitungskomponente, die automatisch Einschränkungen aus dem vom Benutzer formulierten Ziel ableiten würde — diese war jedoch nicht Teil der evaluierten Konfiguration.

Die entscheidende These: ClawGuard transformiert Alignment-abhängige Verteidigung in einen deterministischen, auditierbaren Mechanismus.¹

Warum Alignment keine Sicherheitsgrenze ist

Viele der MCP-Schwachstellen, die ich letzte Woche katalogisiert habe, nutzen eine gemeinsame strukturelle Lücke aus. Der Agent empfängt Anweisungen aus einer Tool-Beschreibung, einer abgerufenen Webseite oder einer Skill-Datei — und das Einzige, was zwischen dieser Injection und der Ausführung steht, ist die Fähigkeit des Modells, legitime Anweisungen von adversariellen zu unterscheiden. (Einige Schwachstellen — SSRF, RCE, Path Traversal — nutzen serverseitige Fehler aus, die nicht von der Befehlsbefolgung des Modells abhängen, dennoch bleibt die Tool-Call-Grenze für die Verteidigung relevant.)

Alignment-Training hilft. RLHF macht es wahrscheinlicher, dass Modelle schädliche Anfragen ablehnen. Doch „wahrscheinlicher” ist keine Sicherheitseigenschaft. Ein Modell, das 99 % der Prompt-Injections ablehnt, versagt trotzdem in 1 % der Fälle, und ein Angreifer, der die Eingabe kontrolliert, kann iterieren, bis diese 1 % treffen. Das Tool-Poisoning-Muster erfordert nicht einmal ein Versagen des Modells — die vergiftete Beschreibung lässt die bösartige Aktion wie die beabsichtigte aussehen.

Laufzeit-Interception operiert auf einer völlig anderen Ebene. Ein Hook oder eine Policy-Engine, die einen Tool-Aufruf vor der Ausführung prüft, hängt nicht davon ab, ob das Modell den Angriff verstanden hat. Die Prüfung ist deterministisch: Entspricht der Aufruf dem erlaubten Satz, oder nicht?

Drei Injection-Kanäle, ein Durchsetzungspunkt

ClawGuard identifiziert drei Angriffskanäle für werkzeuggestützte Agenten:¹

Web- und lokale Inhalts-Injection. Der Agent liest eine Webseite oder lokale Datei mit adversariellen Anweisungen. Diese Anweisungen veranlassen den Agenten, Tools auf Weisen aufzurufen, die der Benutzer nicht beabsichtigt hat. Die Silent-Egress-Angriffsfläche ist eine Instanz dieses Musters — in abgerufenen Inhalten versteckte Exfiltrations-Anweisungen.

MCP-Server-Injection. Ein kompromittierter oder bösartiger MCP-Server bettet Anweisungen in Tool-Beschreibungen oder Antwort-Payloads ein. Der Agent liest diese Anweisungen als Kontext und handelt danach. Der 50-Schwachstellen-Katalog der letzten Woche dokumentiert diesen Kanal ausführlich.

Skill-Datei-Injection. Adversarielle Anweisungen, die in Skill-Dateien und Konfigurationen platziert werden, die der Agent als vertrauenswürdigen Kontext lädt. Der Agent behandelt Skill-Datei-Inhalte als autoritativ — ein Angreifer, der in eine Skill-Datei oder Konfiguration schreiben kann, kann das Verhalten des Agenten steuern.

Die Verteidigungsarchitektur platziert die Durchsetzung an der Tool-Call-Grenze — dem einzelnen Punkt, den jede externe Aktion passieren muss, unabhängig davon, welcher Kanal die Anweisung injiziert hat.¹ Bevor der Agent ein Tool aufruft, prüft ClawGuard den Aufruf gegen Einschränkungen, die aus der ursprünglichen Aufgabe des Benutzers abgeleitet wurden. Ein Aufruf, der außerhalb dieser Einschränkungen liegt, wird blockiert — egal wie überzeugend der Injection-Prompt war.

Die architektonische Erkenntnis verdient eine klare Formulierung: Sie müssen nicht jede Injection erkennen, wenn Sie die Policy an der Ausführungsgrenze durchsetzen können.

Der Vercel-Telemetrie-Vorfall

Vier Tage bevor das ClawGuard-Paper erschien, veröffentlichte Akshay Chugh am 9. April eine Offenlegung über das Vercel-Plugin für Claude Code.² Die Erkenntnisse zum Zeitpunkt der Offenlegung:

Das Plugin registrierte Hooks, die Bash-Befehlszeichenfolgen an telemetry.vercel.com sendeten.² Eine persistente UUID, gespeichert unter ~/.claude/vercel-plugin-device-id, verknüpfte diese Befehlszeichenfolgen mit einem Gerät.² Das Plugin verwendete leere String-Matcher für seine Hooks, was bedeutete, dass die Hooks bei allen Projekten ausgelöst wurden — nicht nur bei Vercel-Projekten.² Der Zustimmungsmechanismus nutzte eine Prompt-Injection anstelle einer nativen UI, um die Zustimmung des Benutzers einzuholen.² Die Telemetrie wurde bei jedem übereinstimmenden Ereignis ausgelöst, sofern der Benutzer nicht VERCEL_PLUGIN_TELEMETRY=off gesetzt hatte.²

Vercel hat die Telemetrie-Bedenken am 14. April adressiert und die breiten Matcher sowie den promptbasierten Zustimmungsmechanismus entfernt.²

Der Vercel-Vorfall ist keine Schwachstelle im herkömmlichen Sinne. Niemand stiehlt Anmeldedaten. Allerdings demonstriert er genau die Problemklasse, die Laufzeitverteidigung adressiert: ein Hook, der breiter auslöst als vom Benutzer beabsichtigt, Daten sammelt, deren Weitergabe der Benutzer nicht explizit zugestimmt hat, über einen Mechanismus, der die native Zustimmungs-UI umgeht.

Ersetzen Sie „Telemetrie” durch „Exfiltration”, und die Architektur ist identisch. Ein Hook mit einem zu breiten Matcher, der bei jedem Projekt ausgeführt wird und Daten an einen externen Endpunkt sendet. Der Unterschied zwischen Telemetrie und Angriff ist die Absicht — und Absicht lässt sich zur Laufzeit nicht auditieren.

Vom Paper zur Praxis: Was Praktiker bereits haben

ClawGuard formalisiert etwas, das Praktiker informell bereits aufbauen. Claude Code wird mit einem Hook-System ausgeliefert, das PreToolUse- und PostToolUse-Interception unterstützt. Ich betreibe über 95 Hooks, die Dateipfad-Beschränkungen durchsetzen, Tool-Eingaben validieren und destruktive Operationen hinter expliziter Bestätigung absichern.³

Die Lücke zwischen meinen Hooks und ClawGuards Vision ist die Automatisierung. Meine Hooks sind handgeschriebene Regeln: interne IP-Adressen in MCP-Eingaben blockieren, Dateischreibvorgänge auf Projektverzeichnisse beschränken, Genehmigung für git force-push erfordern. Die evaluierte ClawGuard-Konfiguration verwendet grundlegende Zugriffskontrollregeln, die im Geiste handgeschriebenen Hooks ähneln. Die vorgeschlagene aufgabenspezifische Regelableitungskomponente des Papers würde automatisch Einschränkungen aus dem vom Benutzer formulierten Ziel ableiten¹ — statt „Schreibvorgänge auf /etc blockieren” zu schreiben, würde das Framework ableiten, dass eine als „Refactoring des Login-Moduls” beschriebene Aufgabe keinen Schreibzugriff auf Systemverzeichnisse benötigen sollte. Diese Komponente bleibt zukünftige Arbeit.

Automatische Constraint-Ableitung ist das schwierigere Problem — und ClawGuards aufgabenspezifische Regelableitungskomponente stellt zukünftige Arbeit dar, keine evaluierten Ergebnisse. Die Basiskonfiguration, die die Autoren tatsächlich evaluiert haben, zeigte starke, aber nicht perfekte Ergebnisse: AgentDojo erreichte eine Angriffserfolgrate (ASR) von 0 %, SkillInject lag jedoch noch bei 4,8–14 % ASR und MCPSafeBench zeigte je nach Modell 7,1–11,0 % ASR.¹ Handgeschriebene Regeln sind fragil — sie decken die Angriffe ab, die Sie vorhergesehen haben. Abgeleitete Einschränkungen könnten Angriffe abdecken, die Sie nicht vorhergesehen haben, weil sie auf dem positiven Satz operieren (was passieren sollte) statt auf dem negativen Satz (was nicht passieren sollte).

Ob automatische Ableitung in der Produktion zuverlässig funktioniert, bleibt eine offene Frage. Die Benchmarks sind kontrollierte Umgebungen. Reale Agentensitzungen umfassen mehrdeutige Aufgaben, mehrstufige Tool-Ketten und Tool-Aufrufe, die anomal aussehen, aber legitim sind. False Positives, die gültige Tool-Aufrufe blockieren, würden die Behauptung „ohne Beeinträchtigung des Agentennutzens” schnell untergraben.

Der mehrschichtige Verteidigungsstapel

Laufzeitverteidigung ist kein einzelner Mechanismus. Der praktische Stapel für werkzeuggestützte Agenten umfasst mindestens vier Schichten:

Schicht 1: Eingabevalidierung. Hooks, die Tool-Call-Argumente vor der Ausführung prüfen. Interne IP-Adressen blockieren, Dateipfade validieren, Shell-Metazeichen ablehnen. Meine PreToolUse-Hooks operieren auf dieser Schicht. Niedrige False-Positive-Rate, fängt aber nur bekannte Negativmuster ab.

Schicht 2: Aufgabenbezogene Einschränkungen. Beschränkung der erlaubten Tools und erlaubten Argumente auf das, was die aktuelle Aufgabe erfordert. ClawGuard operiert primär auf dieser Schicht.¹ Höhere Abdeckung als Eingabevalidierung allein, erfordert jedoch akkurates Aufgabenverständnis.

Schicht 3: Ausgabeinspektion. PostToolUse-Hooks, die Tool-Ergebnisse untersuchen, bevor der Agent sie verarbeitet. Erkennt Datenexfiltration, identifiziert anomale Antworten und markiert unerwartetes Tool-Verhalten. Der Middleman-Beitrag dokumentierte, warum Ausgabeinspektion wichtig ist — ein kompromittierter Router modifiziert Antworten nach der Generierung.

Schicht 4: Sitzungsaudit. Protokollierung jedes Tool-Aufrufs, jedes Arguments, jedes Ergebnisses für nachträgliche Überprüfung. Kein Präventionsmechanismus, sondern ein Erkennungsmechanismus. Akshay Chugh deckte den Vercel-Telemetrie-Vorfall durch genau diese Art von Audit auf — durch Lesen der Hook-Konfiguration und Nachvollziehen der Hook-Aktivitäten.²

Keine einzelne Schicht genügt. Eingabevalidierung übersieht neuartige Muster. Aufgabenbezogene Einschränkungen können zu restriktiv oder zu freizügig sein. Ausgabeinspektion erhöht die Latenz. Sitzungsaudit erkennt Probleme erst nach dem Schaden. Der Stapel funktioniert, weil jede Schicht die Lücken der anderen abdeckt.

Was ClawGuard richtig macht

Das Paper liefert drei Beiträge, die für Praktiker relevant sind:

Determinismus statt Alignment. Laufzeitverteidigung als deterministischen Mechanismus statt als Alignment-Eigenschaft zu rahmen, ist die korrekte Rahmung. Alignment ist eine Trainingszeit-Eigenschaft, die unter adversariellen Bedingungen degradiert. Deterministische Durchsetzung ist eine Laufzeit-Eigenschaft, die unabhängig vom Modellverhalten Bestand hat. Die Unterscheidung klingt akademisch, verändert aber, was Sie über die Sicherheitslage Ihres Systems zusichern können.

Kanalunabhängige Durchsetzung. Web-Injection, MCP-Injection und Skill-Datei-Injection mit einem einzigen Durchsetzungspunkt zu verteidigen, ist architektonisch solide. Drei separate Verteidigungen für drei Injection-Kanäle würden einen Wartungsaufwand schaffen und Lücken an den Schnittstellen hinterlassen. Ein einziger Durchsetzungspunkt an der Tool-Call-Grenze deckt konstruktionsbedingt alle drei Kanäle ab.

Keine Modellanpassung erforderlich. Weder Fine-Tuning noch architektonische Änderung zu erfordern bedeutet, dass die Verteidigung mit jedem Modell funktioniert, einschließlich Modellen, die Sie nicht kontrollieren. Ein Betreiber, der Claude Code, Codex CLI oder ein anderes Agenten-Framework einsetzt, kann Laufzeitverteidigung hinzufügen, ohne auf ein Sicherheitsupdate des Modellanbieters warten zu müssen.

Was offen bleibt

ClawGuard wurde auf Benchmarks getestet. Produktive Agentensitzungen sind unübersichtlicher. Mehrere Fragen bleiben offen, bevor Praktiker sich auf automatische Constraint-Ableitung verlassen können:

Mehrdeutige Aufgaben. „Hilf mir bei diesem Projekt” spezifiziert nicht, welche Tools oder Pfade im Geltungsbereich liegen. Einschränkungen aus vagen Zielen abzuleiten, birgt das Risiko, entweder legitime Aufrufe zu blockieren (zu restriktiv) oder gefährliche zuzulassen (zu freizügig).

Mehrstufige Ketten. Ein Agent, der eine Konfigurationsdatei lesen, eine API aufrufen und Ergebnisse in eine Datenbank schreiben muss, hat ein komplexes Zugriffsmuster. Aus der anfänglichen Aufgabenbeschreibung abgeleitete Einschränkungen antizipieren möglicherweise keine Zwischenschritte.

Adversarielle Aufgabenbeschreibungen. Wenn die Constraint-Ableitung vom formulierten Ziel des Benutzers abhängt, kann ein Angreifer, der die Aufgabenbeschreibung kontrolliert (über einen gemeinsamen Workspace, einen vergifteten Issue-Tracker oder eine manipulierte Projektdatei), die Einschränkungen selbst beeinflussen.

Performancekosten. Die Auswertung von Einschränkungen an jeder Tool-Call-Grenze erhöht die Latenz. Das Paper behauptet, das Framework bewahre den Nutzen, berichtet jedoch keine Latenzmessungen.¹ Bei interaktiven Agentensitzungen verändert selbst eine Verzögerung von 200 ms pro Tool-Aufruf das Benutzererlebnis.

Operative Handlungsempfehlungen

Für Praktiker, die heute werkzeuggestützte Agenten betreiben:

Setzen Sie PreToolUse-Hooks jetzt ein. Sie müssen nicht auf ClawGuard oder ein anderes Framework warten. Das Hook-System von Claude Code unterstützt Tool-Call-Interception bereits heute. Beginnen Sie mit der Eingabevalidierung — blockieren Sie interne Adressen, beschränken Sie Dateipfade, sichern Sie destruktive Operationen ab. Das Hooks-Tutorial behandelt die Implementierung.

Auditieren Sie Ihre Hook-Matcher. Der Vercel-Vorfall geschah, weil leere String-Matcher bei allen Projekten auslösten.² Überprüfen Sie jeden Hook in Ihrer .claude/settings.json und verifizieren Sie, dass jeder Matcher nur den beabsichtigten Kontext anspricht. Ein Hook mit einem zu breiten Matcher ist eine Schwachstelle, keine Verteidigung.

Protokollieren Sie jeden Tool-Aufruf. Sitzungsaudit ist die Verteidigungsschicht mit dem geringsten Aufwand und dem höchsten Nutzen. Selbst wenn Sie nicht jeden Angriff verhindern können, können Sie ihn nachträglich erkennen — aber nur, wenn Sie Protokolle haben.

Evaluieren Sie ClawGuard gegen Ihren Stack. Der Code des Papers ist öffentlich verfügbar. Evaluieren Sie die Basiskonfiguration gegen Ihren bestehenden Hook-Stapel. Sollte die aufgabenspezifische Regelableitungskomponente reifen, würde automatische Constraint-Ableitung handgeschriebene Regeln ergänzen, nicht ersetzen.

Behandeln Sie Konfiguration als Vertrauensgrenze. Skill-Dateien, Hook-Konfigurationen, MCP-Server-Definitionen — jede Datei, die das Agentenverhalten beeinflusst, ist eine Angriffsfläche. Wenden Sie dieselben Zugriffskontrollen an, die Sie auch für Produktions-Credentials anwenden würden.

Der MCP-Schwachstellenkatalog dokumentierte die Angriffsfläche. ClawGuard schlägt eine Verteidigungsarchitektur vor. Der Vercel-Vorfall demonstriert, warum beides wichtig ist. Laufzeitverteidigung an der Tool-Call-Grenze ist die durchsetzbare Schicht — nicht weil Alignment nicht hilft, sondern weil Durchsetzung nicht davon abhängt.

Quellen

Häufig gestellte Fragen

Wie unterscheidet sich ClawGuard vom eingebauten Berechtigungssystem von Claude Code?

Das Berechtigungssystem von Claude Code fragt den Benutzer um Genehmigung auf Tool-Ebene — Genehmigung oder Ablehnung bestimmter Tool-Kategorien. ClawGuard operiert auf Argumentebene und leitet automatisch Einschränkungen ab, welche Argumente ein Tool-Aufruf basierend auf der aktuellen Aufgabe enthalten sollte. Beide Mechanismen ergänzen sich: Berechtigungen steuern, welche Tools ausgeführt werden dürfen; Laufzeit-Einschränkungen steuern, wie diese Tools aufgerufen werden können.

Muss ich auf die Veröffentlichung von ClawGuard warten, bevor ich Laufzeitverteidigung hinzufüge?

Nein. Das Hook-System von Claude Code unterstützt PreToolUse- und PostToolUse-Interception bereits heute. Handgeschriebene Hooks, die Tool-Eingaben validieren, decken die häufigsten Angriffsmuster sofort ab. ClawGuards Beitrag liegt in der automatischen Constraint-Ableitung, die manuelle Regeln ergänzen, nicht ersetzen würde.

War der Vercel-Telemetrie-Vorfall eine Sicherheitslücke?

Die Offenlegung beschrieb ein Datenschutz- und Zustimmungsproblem, keine traditionelle Schwachstelle. Zum Zeitpunkt der Offenlegung sammelte das Plugin Bash-Befehlszeichenfolgen aus allen Projekten und sendete sie ohne explizites Opt-in über native UI an einen externen Endpunkt. Vercel hat diese Bedenken inzwischen adressiert. Das architektonische Muster — breite Hook-Matcher, externe Datenübertragung, nicht-native Zustimmung — bleibt lehrreich, da es dasselbe Muster widerspiegelt, das ein bösartiger Hook zur Datenexfiltration verwenden würde.

Welche Auswirkungen hat die Laufzeit-Tool-Call-Interception auf die Performance?

Bei handgeschriebenen Hooks mit Shell-Skripten oder leichtgewichtigen Validatoren sollte der Overhead gemäß den Hooks-Dokumentationsrichtlinien unter 200 ms pro Tool-Aufruf bleiben. Das ClawGuard-Paper berichtet keine Latenzmessungen für seine Constraint-Auswertung, die zusätzlichen Overhead verursachen könnte. Bei interaktiven Sitzungen ist die Latenz pro Tool-Aufruf entscheidend — testen Sie vor dem Einsatz komplexer Validierungslogik.