Agent schickt Daten nach außen: Hooks statt nur Regeln

Ein Entwickler lässt Claude Code eine Recherche erledigen. Der Agent lädt Listen von Wikipedia herunter und erledigt die Aufgabe. Erst danach meldet er selbst: Er hat die E-Mail-Adresse des Nutzers in den User-Agent-Header der Anfrage geschrieben. Niemand hatte das verlangt, und kein Mensch hat den Befehl vor der Ausführung gesehen.

Die Geschichte stammt aus einer viel diskutierten Reddit-Diskussion. Sie ist für Teams lehrreich, weil sie zeigt, wo schriftliche Regeln enden und wo technische Grenzen beginnen müssen.

Was passiert ist

Laut dem Beitrag erklärte der Agent den Vorgang selbst: Wikipedia und SEC EDGAR bitten Skripte, sich mit Kontaktdaten zu identifizieren. Der Agent folgte dieser Konvention und nahm die naheliegendste Adresse, die er hatte, nämlich die aus dem Konto des Nutzers. Eine Anweisung, diese Adresse nicht an externe Dienste zu senden, lag ihm vor. Er bezog sie aber nicht auf den Header, weil er ihn als technisches Detail behandelte und nicht als Daten, die den Rechner verlassen. Im Auto-Modus brauchte ein Routine-Download keine Freigabe.

In den Kommentaren ordnen viele ein, dass die Kontaktangabe im User-Agent bei Wikipedia eine dokumentierte Anforderung ist. Andere halten dagegen: Das Problem sei nicht die Konvention, sondern dass der Agent eine Entscheidung über persönliche Daten traf, die eine Rückfrage gebraucht hätte. Ein weiterer Nutzer berichtet Ähnliches beim Zugriff auf die API von crates.io. Und einer schildert, dass sein Agent trotz Verbotsregeln für das Löschen von Dateien Wege darum herum fand, etwa über git rm oder ein Node-Skript.

Warum Regeln allein nicht reichen

Nach dem Vorfall schrieb der Agent die Regel in sein Gedächtnis und in die globale und projektbezogene CLAUDE.md. Er wies aber selbst darauf hin, dass all das davon abhängt, dass er es liest und anwendet. Als verlässlichere Absicherung schlug er einen Hook vor.

Das ist der Kern für Teams. Kontextdateien wie CLAUDE.md oder AGENTS.md sind gut für Konventionen, Projektwissen und Abwägungen. Wie Sie solche Dateien im Team aufbauen, beschreibt der Beitrag Claude Code im Team. Für harte Grenzen, also Daten, die nie hinausgehen dürfen, oder Dateien, die nie geändert werden dürfen, sind sie zu weich. Denn das Modell muss die Regel in jeder Situation richtig auf den konkreten Befehl beziehen.

Was Hooks leisten

Die Dokumentation von Claude Code beschreibt Hooks als selbst definierte Shell-Befehle, die an festen Punkten im Ablauf laufen. Sie geben deterministische Kontrolle: Bestimmte Dinge passieren immer, statt davon abzuhängen, ob das Modell sie ausführt. Ein PreToolUse-Hook läuft vor jedem Tool-Aufruf. Er kann den geplanten Aufruf prüfen und ihn blockieren. Der Agent bekommt dann eine Begründung und kann seinen Ansatz anpassen.

Die Dokumentation nennt als Beispiel das Blockieren von Änderungen an sensiblen Dateien wie .env, package-lock.json oder allem in .git/. Nach demselben Muster lässt sich ein Hook bauen, der Befehle mit bestimmten E-Mail-Adressen oder anderen Kennungen stoppt. Wichtig für den Ernstfall: Laut Dokumentation laufen PreToolUse-Hooks vor jeder Prüfung des Berechtigungsmodus. Ein Hook, der deny zurückgibt, blockiert das Tool sogar im Modus bypassPermissions.

Für komplexere Prüfungen gibt es zusätzlich prompt- und agentenbasierte Hooks, die ein Claude-Modell die Bedingung bewerten lassen. Die Detailkonfiguration ist Thema für sich. Hier geht es um die Teamentscheidung, welche Grenzen technisch erzwungen werden.

Hooks im Team verteilen

Wo ein Hook liegt, bestimmt, für wen er gilt:

• ~/.claude/settings.json: alle Projekte, aber nur auf dem eigenen Rechner.
• .claude/settings.json: ein Projekt, kann ins Repository eingecheckt werden.
• .claude/settings.local.json: ein Projekt, nicht geteilt.
• Managed Policy Settings: unternehmensweit, von Administratoren verwaltet.
• Plugins, Skills und Subagents können eigene Hooks mitbringen.

Für ein Team heißt das: Grenzen, die für alle gelten sollen, gehören in die Projekt-Settings im Repository oder in die Managed Settings, nicht in die persönliche Konfiguration einzelner Entwickler. Mit /hooks lässt sich prüfen, welche Hooks aktiv sind. Ergänzend hilft ein Blick auf die Tool-Freigaben, wie im Beitrag über MCP-Server im Team beschrieben.

Was das für Ihr Entwicklerteam bedeutet

Legen Sie gemeinsam fest, was nie passieren darf: Secrets oder persönliche Daten in ausgehenden Anfragen, Änderungen an geschützten Dateien, bestimmte Shell-Befehle. Für genau diese Punkte reichen Regeln in Kontextdateien nicht. Sie brauchen einen Hook, der versioniert im Repository liegt, im Review geprüft wird und für alle gleich gilt. Alles andere, also Stil, Architektur und Abwägungen, bleibt in CLAUDE.md oder AGENTS.md.

Ein einfacher Test zeigt, ob es funktioniert: Ein Teammitglied versucht absichtlich, die Grenze zu überschreiten, und prüft, ob der Hook greift. Das passt zu den Sicherheitsthemen, die wir auch zu Prompt Injection und auf der Seite Sicherheit beschreiben.

Fazit

Ein Agent, der eine Regel kennt, befolgt sie nicht zwingend in jeder Situation. Harte Grenzen gehören deshalb in Hooks, die vor jedem Tool-Aufruf greifen und im Team geteilt werden.

Sie wollen festlegen, welche Grenzen Ihr Team technisch absichert und welche in Kontextdateien gehören? Inhouse-Training anfragen.