Laufzeitverteidigung für werkzeuggestützte Agenten

Vor einer Woche habe ich 50 MCP-Schwachstellen in den Bereichen SSRF, Tool Poisoning und Trust-Bypass-Muster veröffentlicht. Die implizite Schlussfolgerung war ernüchternd: Die Angriffsfläche wächst schneller als die Auditkapazitä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 zeigt 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 Toolaufruf erfolgt. Keine Modellanpassung. Keine Infrastrukturänderung. Kein sicherheitsspezifisches Fine-Tuning.¹ Die Autoren testeten mit AgentDojo, SkillInject und MCPSafeBench unter Verwendung von fünf Frontier-LLMs.¹ Das Paper beschreibt zudem eine aufgabenspezifische Regelableitungskomponente, die automatisch Einschränkungen aus dem vom Benutzer formulierten Ziel ableiten würde — allerdings wurde diese Komponente nicht in die evaluierte Konfiguration einbezogen.

Die entscheidende Aussage: 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 adversarialen zu unterscheiden. (Einige Schwachstellen, darunter SSRF, RCE und Path Traversal, nutzen serverseitige Fehler aus, die überhaupt nicht von der Befolgung von Modellanweisungen abhängen — dennoch bleibt die Tool-Call-Grenze für die Verteidigung relevant.)

Alignment-Training hilft. RLHF macht Modelle eher geneigt, schädliche Anfragen abzulehnen. Doch „eher geneigt” ist keine Sicherheitseigenschaft. Ein Modell, das 99 % der Prompt Injections ablehnt, versagt immer noch in 1 % der Fälle — und ein Angreifer, der die Eingabe kontrolliert, kann iterieren, bis diese 1 % eintreten. 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 Schicht. Ein Hook oder eine Policy-Engine, die einen Tool-Call vor der Ausführung inspiziert, hängt nicht davon ab, ob das Modell den Angriff verstanden hat. Die Prüfung ist deterministisch: Stimmt der Aufruf mit der erlaubten Menge überein, 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 adversarialen Anweisungen. Diese Anweisungen veranlassen den Agenten, Tools auf eine Weise aufzurufen, die der Benutzer nicht beabsichtigt hat. Die Silent-Egress-Angriffsfläche ist eine Instanz dieses Musters, bei der Exfiltrations-Anweisungen in abgerufenen Inhalten versteckt sind.

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

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

Die Verteidigungsarchitektur platziert die Durchsetzung an der Tool-Call-Grenze — dem einzigen 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 sein Regelwerk. In der evaluierten Konfiguration handelt es sich um grundlegende Zugriffskontrollbeschränkungen (Dateipfad-Einschränkungen, Netzwerkaufruf-Allowlists, Credential-Zugriffssperren). ClawGuard blockiert jeden Aufruf, der außerhalb dieser Beschränkungen liegt — egal wie überzeugend der Injection-Prompt ist.

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 Ergebnisse zum Zeitpunkt der Offenlegung:

Das Plugin registrierte Hooks, die Bash-Befehlszeichenketten an telemetry.vercel.com sendeten.² Eine persistente UUID, gespeichert unter ~/.claude/vercel-plugin-device-id, verknüpfte diese Befehlszeichenketten 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 statt nativer UI, um die Einwilligung des Benutzers einzuholen.² Telemetrie wurde bei jedem gematchten Event ausgelöst, es sei denn, der Benutzer setzte VERCEL_PLUGIN_TELEMETRY=off.²

Vercel adressierte die Telemetrie-Bedenken am 14. April, indem die breiten Matcher und der promptbasierte Zustimmungsmechanismus entfernt wurden.²

Der Vercel-Vorfall ist keine Schwachstelle im traditionellen Sinne. Niemand stiehlt Credentials. Er demonstriert jedoch exakt 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 läuft und Daten an einen externen Endpunkt sendet. Der Unterschied zwischen Telemetrie und Angriff ist die Absicht — und Absicht ist zur Laufzeit nicht auditierbar.

Vom Paper zur Praxis: Was Praktiker bereits haben

ClawGuard formalisiert etwas, das Praktiker informell bereits aufgebaut haben. Claude Code wird mit einem Hook-System ausgeliefert, das PreToolUse- und PostToolUse-Interception unterstützt. Ich betreibe über 95 Hooks, die Dateipfad-Einschrä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, Dateischreibzugriffe auf Projektverzeichnisse beschränken, Genehmigung für Git-Force-Push verlangen. Die evaluierte ClawGuard-Konfiguration verwendet grundlegende Zugriffskontrollregeln, die handgeschriebenen Hooks im Geist ähneln. Die im Paper vorgeschlagene aufgabenspezifische Regelableitungskomponente würde automatisch Einschränkungen aus dem vom Benutzer formulierten Ziel ableiten.¹ Anstatt „blockiere Schreibzugriffe auf /etc” zu schreiben, würde das Framework folgern, dass eine Aufgabe wie „Refactoring des Login-Moduls” 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 evaluierten, zeigte starke, aber nicht perfekte Ergebnisse: AgentDojo erreichte eine Angriffserfolgrate (ASR) von 0 %, doch SkillInject verzeichnete weiterhin 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 Constraints könnten Angriffe abdecken, die Sie nicht vorhergesehen haben, weil sie auf der positiven Menge operieren (was geschehen soll) statt auf der negativen Menge (was nicht geschehen soll).

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 Einschränkung des Agenten-Nutzens” rasch untergraben.

Der geschichtete Verteidigungsstack

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

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

Schicht 2: Grundlegende Regeldurchsetzung. Einschränkung der erlaubten Tools und Argumente basierend auf Zugriffskontrollregeln (Pfad-Einschränkungen, Netzwerk-Allowlists, Credential-Sperren). ClawGuards evaluierte Konfiguration operiert auf dieser Schicht.¹ Das Paper schlägt zudem aufgabenbezogene Constraint-Ableitung vor, die zwischen dieser und der nächsten Schicht angesiedelt wäre — diese Komponente bleibt jedoch zukünftige Arbeit. Höhere Abdeckung als Eingabevalidierung allein, doch die Regeln müssen gepflegt werden, wenn sich die Umgebung ändert.

Schicht 3: Ausgabeinspektion. PostToolUse-Hooks, die Tool-Ergebnisse untersuchen, bevor der Agent sie verarbeitet. Erkennt Datenexfiltration, identifiziert anomale Antworten, markiert unerwartetes Tool-Verhalten. Der Middleman-Beitrag dokumentiert, 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: Lesen der Hook-Konfiguration und Nachverfolgung, was die Hooks taten.²

Keine einzelne Schicht reicht aus. Eingabevalidierung übersieht neuartige Muster. Aufgabenbezogene Constraints können zu restriktiv oder zu permissiv sein. Ausgabeinspektion erhöht die Latenz. Sitzungsaudit erkennt Probleme erst nach dem Schaden. Der Stack 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 Einordnung. Alignment ist eine Trainingszeit-Eigenschaft, die unter adversarialen Bedingungen degradiert. Deterministische Durchsetzung ist eine Laufzeit-Eigenschaft, die unabhängig vom Modellverhalten gilt. Die Unterscheidung klingt akademisch, verändert jedoch grundlegend, was Sie über die Sicherheitslage Ihres Systems zusagen können.

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

Keine Modellanpassung erforderlich. Weder Fine-Tuning noch architektonische Modifikation vorauszusetzen bedeutet, dass die Verteidigung mit jedem Modell funktioniert — einschließlich Modellen, die Sie nicht kontrollieren. Ein Betreiber, der Claude Code, Codex CLI oder ein beliebiges anderes Agentenframework nutzt, 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 unordentlicher. Mehrere Fragen bleiben offen, bevor Praktiker sich auf automatische Constraint-Ableitung verlassen können:

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

Mehrstufige Ketten. Ein Agent, der eine Konfigurationsdatei lesen, eine API aufrufen und Ergebnisse in eine Datenbank schreiben muss, hat ein komplexes Zugriffsmuster. Constraints, die aus der initialen Aufgabenbeschreibung abgeleitet werden, antizipieren möglicherweise keine Zwischenschritte.

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

Leistungskosten. Die Auswertung von Constraints an jeder Tool-Call-Grenze erhöht die Latenz. Das Paper behauptet, das Framework bewahre den Nutzen, berichtet jedoch keine Latenzmessungen.¹ Für interaktive Agentensitzungen verändert selbst eine Verzögerung von 200 ms pro Tool-Call das Benutzererlebnis.

Operative Erkenntnisse

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 Eingabevalidierung: interne Adressen blockieren, Dateipfade einschränken, destruktive Operationen absichern. Das Hooks-Tutorial behandelt die Implementierung.

Überprüfen 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 Belastung, keine Verteidigung.

Protokollieren Sie jeden Tool-Call. Sitzungsaudit ist die Verteidigungsschicht mit dem geringsten Aufwand und dem höchsten Wert. Selbst wenn Sie nicht jeden Angriff verhindern können, können Sie ihn im Nachhinein erkennen — aber nur, wenn Sie Protokolle haben.

Evaluieren Sie ClawGuard gegen Ihren Stack. Das Paper verlinkt ein Repository, allerdings hatten die Autoren zum Zeitpunkt der Veröffentlichung noch keinen Code publiziert. Sobald verfügbar, evaluieren Sie die Basiskonfiguration gegen Ihren bestehenden Hook-Stack. Falls die aufgabenspezifische Regelableitungskomponente heranreift, würde automatische Constraint-Ableitung handgeschriebene Regeln ergänzen, nicht ersetzen.

Behandeln Sie Konfiguration als Vertrauensgrenze. Skill-Dateien, Hook-Konfiguration, 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-Schwachstellen-Katalog dokumentierte die Angriffsfläche. ClawGuard schlägt eine Verteidigungsarchitektur vor. Der Vercel-Vorfall zeigt, 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 unterstützt sowohl Tool-Level-Genehmigung (Genehmigung oder Ablehnung von Tool-Kategorien) als auch Argument-Level-Spezifizierer (z. B. Bash(git diff *), um nur passende Befehle zu erlauben). ClawGuards evaluierte Konfiguration setzt grundlegende Zugriffskontrollregeln auf Argumentebene durch. Die vorgeschlagene aufgabenspezifische Regelableitungskomponente würde automatisch Argument-Constraints aus der aktuellen Aufgabe ableiten, wurde von den Autoren jedoch nicht evaluiert. Beide Systeme ergänzen sich: Claude Code-Berechtigungen steuern, welche Tools und Argumentmuster ausgeführt werden dürfen, während ClawGuard-artige Laufzeit-Constraints eine zweite Durchsetzungsschicht hinzufügen.

Muss ich auf die Veröffentlichung von ClawGuard warten, bevor ich Laufzeitverteidigung einsetze?

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 ist die automatische Constraint-Ableitung, die manuelle Regeln ergänzen würde, nicht ersetzen.

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

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

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

Bei handgeschriebenen Hooks mit Shell-Skripten oder leichtgewichtigen Validatoren sollte der Overhead nach meiner Betriebserfahrung unter 200 ms pro Tool-Call bleiben. Das ClawGuard-Paper berichtet keine Latenzmessungen für seine Constraint-Auswertung, die zusätzlichen Overhead verursachen könnte. Für interaktive Sitzungen ist die Latenz pro Tool-Call relevant — testen Sie daher vor dem Einsatz komplexer Validierungslogik.