KI-Coding-Agent und Datenschutz: 5 Mythen im Faktencheck

Dutzende Spam-Mails am Tag, personalisiert mit deinem echten Vor- und Nachnamen – und das Datenleck ist weder eine gehackte Datenbank noch eine geleakte Marketingliste. Es ist der User-Agent-Header, den dein KI-Coding-Agent an Web-Requests angehängt hat, die du nie bewusst freigegeben hast. Genau das haben Entwickler herausgefunden, als sie eine Spam-Welle auf Claude Code zurückverfolgten. Das Tool hatte die Account-E-Mail-Adressen der Nutzer bei Web-Fetches und Suchen in ausgehende HTTP-Requests geschrieben. Anthropics eigene Erklärung ist fast schlimmer als der Bug: Die Account-E-Mail war in den Kontext des Modells geschrieben worden, damit es sinnvolle @author-Tags erzeugen kann. Das Modell – ein hilfsbereiter kleiner Bot – fing dann an, sie jeder Website anzubieten, die nach einem Kontakt fragte. Ich beschäftige mich seit Jahren mit dem Netzwerkverhalten von Tools, die auf Entwicklerrechnern laufen, und dieser Vorfall ist ein nahezu perfektes Lehrbeispiel. Also schauen wir uns die fünf Annahmen an, die ich zum Datenschutz bei agentischen Tools am häufigsten höre, und prüfen jede gegen das, was tatsächlich passiert ist.

Mythos 1: „Mein Coding-Agent spricht nur mit der API des Modellanbieters“

Das ist das mentale Modell, mit dem fast alle starten: Der Agent ist eine schicke Pipeline zwischen deinem Terminal und den Servern von Anthropic (oder OpenAI, oder wer auch immer). Dein Code geht rein, Tokens kommen raus, und der einzige Netzwerkendpunkt, der zählt, ist api.anthropic.com.

Das stimmt nicht. Ein moderner agentischer CLI-Client ist ein HTTP-Client für alle Zwecke, der zufällig von einem Sprachmodell gesteuert wird. Er hat ein WebFetch-Tool, das beliebige URLs abruft. Er hat ein WebSearch-Tool, das auf Suchinfrastruktur zugreift. Und er hat ein Bash-Tool – das heißt curl, wget, pip install, npm install, git clone und jedes andere netzwerkfähige Programm auf deinem System. Wenn er Dokumentation, ein Paket, ein Changelog oder eine SEC-Einreichung braucht, holt er sie sich dort, wo er vermutet, dass sie liegt. Jeder dieser Requests stammt von deiner IP-Adresse, aus deinem Firmennetzwerk, und trägt die Header, die das Modell an diesem Morgen gerade geschrieben hat.

Und das Modell kann kreativ werden. Nachdem die E-Mail-Geschichte bekannt wurde, prüfte ein Ingenieur die eigenen Webserver-Logs und fand Requests von Subagenten mit User-Agent-Strings wie company-helm-research/1.0 (Claude Code agent run by [name], [company] platform team; docs lookup) – inklusive des Firmennamens und des GitHub-Repositorys, an dem gearbeitet wurde. Der Agent hat also keinen Konfigurationswert durchgereicht, sondern identifizierende Header aus dem Kontext zusammengesetzt. Das ist wie bei einem hilfsbereiten Praktikanten, der jede Kaltakquise-Mail mit vollem Namen, Team und Projekt unterschreibt. Wenn du genauer verstehen willst, warum die Architektur das so leicht macht, haben wir darüber geschrieben, wie agentische Coding-CLIs aufgebaut sind. Die Kurzfassung: Schleife, Kontext und Tool-Set sind genau so mächtig, wie es nötig ist, um Ärger zu verursachen.

Das richtige mentale Modell: Dein Agent ist eine neue Juniorkraft mit Firmenlaptop, Firmennetzwerk und einem Stapel deiner Visitenkarten. Alles, was in seinem Kontext steht, kann über jedes Tool, das er hat, das Gebäude verlassen.

Mythos 2: „Eine Kontakt-E-Mail im User-Agent ist einfach gute Bot-Etikette“

Daran ist ein Körnchen Wahrheit, und genau deshalb ist es gefährlich. Es gibt eine echte Konvention: Gut erzogene Crawler identifizieren sich und geben einen Kontakt an. Manche Dienste setzen das knallhart durch. Die EDGAR-API der SEC zum Beispiel weist Requests mit einem generischen curl-User-Agent schlicht ab und verlangt einen angegebenen Kontakt. Das kannst du in zehn Sekunden selbst prüfen:

U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
curl -s -o /dev/null -w '%{http_code}  default UA\n' "$U"
# 403  default UA
curl -s -o /dev/null -w '%{http_code}  declared contact\n' \
-A 'Acme Research admin@acme-research.example' "$U"
# 200  declared contact

Ein Modell, das gelernt hat „Manche APIs wollen eine Kontaktadresse im User-Agent“, halluziniert also nicht – es erkennt ein Muster aus echter Internet-Etikette. Und wenn in seinem Kontext zufällig deine Account-E-Mail steht, hat es genau eine Kontaktadresse, die es anbieten kann. Der Anthropic-Ingenieur, der den Vorfall erklärte, sagte das sinngemäß: Manche Seiten fragen Agenten nach einem Kontakt, und Claude hat dann manchmal die E-Mail angegeben, die es hatte.

Hier bricht der Mythos. Die Konvention besagt, dass der Betreiber des Bots seinen eigenen Kontakt angibt – also die Stelle, die den Crawler betreibt, damit ein genervter Sysadmin jemanden erreicht, der Verantwortung trägt. Anthropics Crawler identifiziert sich als Anthropic, der von Google als Google. Wenn aber dein Agent eine Seite abruft, sollte der Betreiberkontakt die Support-URL des Tool-Anbieters sein oder eine Adresse, die du bewusst konfiguriert hast – nicht die private Account-E-Mail, mit der du das Abo bezahlst. Die Empfehlung in RFC 9110 zum User-Agent rät ausdrücklich davon ab, unnötig detaillierte Identifikationsangaben zu machen, und jeder Datenschutz-Ingenieur, den ich kenne, behandelt ungefragte personenbezogene Daten in Request-Headern als Fehler, Punkt. Bot-Etikette war nie dafür gedacht, den Menschen hinter dem Bot zu deanonymisieren.

Und der Schaden ist real, nicht theoretisch. Beliebige Drittseiten – auch die von Scams verseuchten Ecken des Webs, die ein suchender Agent zwangsläufig berührt – haben nun eine verifizierte, mit Namen verknüpfte E-Mail-Adresse eines aktiven Software-Entwicklers. Das ist ein Spear-Phishing-Startpunkt, frei Haus geliefert. Mehrere Entwickler konnten eine plötzliche Flut personalisierter Spam-Mails direkt auf dieses Verhalten zurückführen. „Gute Bot-Etikette“, die dich Spammern ausliefert, ist weder gut noch Etikette.

Mythos 3: „Berechtigungsabfragen und die Sandbox halten meine Identität unter Verschluss“

Jedes agentische Tool bringt eine Form von Zustimmungs-UX mit: Der Agent fragt, bevor er Befehle ausführt, zeigt dir, welche Dateien er liest, und sperrt Webzugriffe vielleicht hinter eine Freigabe pro Domain. Das erzeugt einen starken Eindruck – ein Entwickler beschrieb ihn so, dass „das LLM nur auf Dinge zugreifen kann, die explizit einem Projekt hinzugefügt wurden“. Dieser Eindruck ist falsch, und der E-Mail-Vorfall beweist das gleich zweifach.

Erstens steuern Berechtigungssysteme, welche Tools laufen, nicht, was das Modell in die Requests schreibt, die diese Tools stellen. Wenn du „Ja, diese URL abrufen“ bestätigst, sagt dir das nichts über die Header, die das Modell für genau diesen Abruf zusammengestellt hat. Bei einem Bash-Aufruf, der curl ausführt, ist es noch weniger: Der Befehl rauscht vorbei, und niemand liest das -A-Flag. Zweitens arbeitet die Berechtigungs-UI pro Aktion, während das Leck eine Eigenschaft des Kontexts ist. Sobald deine Account-E-Mail in den Systemkontext eingespeist war – was Nutzer nie sahen und nicht abwählen konnten –, stand sie jedem Tool-Aufruf, jedem Subagenten und jedem curl-Einzeiler für die gesamte Sitzung zur Verfügung. Die Sandbox-Grenze wurde um das Dateisystem gezogen, aber der Abflussweg war die Textgenerierung des Modells selbst.

Das ist der Teil, bei dem ich deutlich werden will, weil er weit über den Bug eines einzelnen Anbieters hinausgeht: Alles, was im Kontext eines Agenten steht, ist nur eine plausibel klingende Anweisung davon entfernt, deinen Rechner zu verlassen. API-Schlüssel, interne Hostnamen, Dateiinhalte, dein Name, dein Arbeitgeber, deine E-Mail. Eine Absicherung auf Tool-Ebene hilft nicht, wenn das Modell selbst der Abflusskanal ist. Deshalb habe ich schon argumentiert, dass Containment und Monitoring bei KI-Agenten verschiedene Probleme lösen, und du musst wissen, was du tatsächlich bekommst. Ein Berechtigungsdialog ist Monitoring im Kostüm der Kontrolle. Er zeigt dir die Aktion, aber er kann dir nicht die Absicht zeigen, die in den Parametern der Aktion steckt.

Fazit: Die Sandbox hat in der ausgelieferten Form deine Dateien geschützt. Für deine Identität hat sie nichts getan, denn deine Identität wurde dem Modell als Rohmaterial übergeben.

Mythos 4: „Das ist eine Einstellung – Schalter umlegen, und du bist sicher“

Als das Problem öffentlich wurde, war die Forderung des ursprünglichen Melders eindeutig: Das sollte keine Opt-out-Einstellung sein, sondern müsse komplett aus dem Harness entfernt werden. Dieser Instinkt ist richtig, und die Art, wie der Fix schließlich ausfiel, zeigt gut, warum Einstellungen für diese Problemklasse das falsche Mittel sind.

Die Behebung kam in zwei Teilen. Erstens ein eingebautes Plugin (cc-plugin-privacy, ab v2.1.317 standardmäßig aktiviert), das das Verhalten deterministisch blockiert – eine harte Prüfung, kein Vorschlag an das Modell. Zweitens, und das ist wichtiger: Anthropic hat die Account-E-Mail komplett aus dem Kontext des Modells entfernt. Die Gewichtung ist hier aufschlussreich. Das Plugin ist ein Filter auf der Ausgabe, das Entfernen der E-Mail aus dem Kontext nimmt dem Modell die Fähigkeit. Ein Filter kann etwas übersehen. Ein Modell, das deine E-Mail nie kannte, kann sie nicht leaken, egal wie kreativ es Header zusammensetzt.

Du kannst eine Datenoffenlegung nicht wegprompten. Wenn das Modell es sehen kann, kann es es auch ausgeben. Die einzige verlässliche Schwärzung ist Weglassen.

Das ist ein Muster, das mir in Agenten-Tooling immer wieder begegnet, und es ähnelt dem, was wir bei der Prüfung von API-Clients begutachtet haben, die gleichzeitig als Credential-Tresore dienen: Sensibles Material landet am bequemsten dort, wo es gerade passt (im Kontext, in der Umgebung, in einer Konfigurationsdatei), weil ein Feature es einmal brauchte, und wird danach überallhin mitgeschleppt. Telemetrie-Schalter und Datenschutzeinstellungen regeln, was der Anbieter zu sammeln entschieden hat. Sie sagen nichts darüber, was das Modell mit dem Material anstellt, das ihm übergeben wurde. Einstellungen sind für Präferenzen da. Deterministische Kontrollen und Datenminimierung sind für Datenschutz da. Wenn dir ein Anbieter Ersteres als Lösung für Letzteres verkauft, frag nach.

Mythos 5: „Der Anbieter hat es gepatcht, also kann ich aufhören, mir Sorgen zu machen“

Wo es angebracht ist, muss man loben: Die Reaktionszeit war schnell, die technische Erklärung offen, und der Fix hat die Ursache angegangen statt nur das Symptom. Aber „gepatcht“ ist eine Aussage über ein bestimmtes Verhalten in einer bestimmten Version. Die Problemklasse – agentische Tools, die identifizierendes Material an beliebige Endpunkte senden – ist strukturell, und sie wird in diesem oder einem anderen Tool wieder auftauchen. Mehrere Nutzer wiesen darauf hin, dass dies nicht einmal das erste Mal war, dass die Account-Identität ungefragt im Kontext von Claude Code auftauchte; es war mindestens das zweite Mal.

Darunter liegt eine unbequemere Wahrheit: Du kannst die Abwesenheit eines Lecks von der Client-Seite aus nicht vollständig verifizieren. Ein sorgfältiger Nutzer lief mit einem Man-in-the-Middle-Proxy gegen die gepatchte Version und bestätigte, dass über das WebFetch-Tool nichts Identifizierendes den Rechner verließ – gute Arbeit und der richtige Instinkt. Doch wie er anmerkte, könnte die Identifizierung auch serverseitig passieren: Dein Client schickt eine anonyme Anfrage an die API des Anbieters, und die Infrastruktur dort leitet sie mit deinen Daten im Schlepptau an Dritte weiter. Dann sieht keine lokale Paketanalyse der Welt etwas davon. Du landest wieder beim Vertrauen in den Anbieter, und genau diese Position hat sich durch den Vorfall als unangenehm erwiesen.

Die dauerhafte Haltung ist daher nicht „Patch eingespielt, Fall abgeschlossen“. Sondern: Jedes agentische Tool als dauerhaft verdächtigen Netzwerkclient behandeln, den du regelmäßig prüfst – genau so, wie du jede Drittsoftware mit weitreichenden Rechten auf einem Entwicklerrechner behandeln würdest. Und damit kommen wir zum praktischen Teil.

So prüfst du den Netzwerkverkehr deines Agenten selbst

Dafür brauchst du kein Security-Team. Ein Nachmittag und etwas Standard-Tooling sagen dir mehr über das Verhalten deines Agenten als jede Datenschutzerklärung.

1. Den Verkehr abfangen. Leite den Agenten über mitmproxy und lass ihn eine echte Arbeitssitzung durchlaufen. Node-basierte CLIs respektieren Proxy-Umgebungsvariablen in der Regel, sobald sie deiner CA vertrauen:

mitmdump --listen-port 8080 -w agent-flows.mitm &
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem
# Now run your agent and do normal work.
# Afterwards, search every captured request for your identifiers:
mitmdump -nr agent-flows.mitm \
--flows \
| grep -iE 'you@company\.com|YourName|your-org'

Suche nicht nur nach deiner E-Mail, sondern auch nach deinem Namen, deinem Arbeitgeber, dem GitHub-Slug deiner Organisation, internen Hostnamen und Repository-Namen. Denk an die Subagenten-Logs: Das Modell hat Identifikatoren zusammengesetzt, nicht nur wiedergegeben. Suche daher auch nach Fragmenten.

2. Die Logs deiner eigenen Infrastruktur prüfen. Wenn du Webdienste betreibst, durchsuche deren Access-Logs nach User-Agent-Strings von Agenten. So wurden die zusammengesetzten Header aus Mythos 1 entdeckt. Das kostet nichts und fördert oft Subagenten-Traffic zutage, den die lokale Mitschnitt-Analyse übersieht.

3. Den Egress begrenzen. Die stärkste Kontrolle macht ganze Kategorien von Lecks unmöglich. Lass den Agenten in einem Container oder einer VM laufen, deren Netzwerkrichtlinie nur die Endpunkte erlaubt, die er wirklich braucht – die Modell-API, deine Paket-Registries, vielleicht GitHub. Mit Docker bedeutet das ein eigenes Netzwerk plus Egress-Firewall; auf dem Mac liefern Little Snitch oder Lulu Regeln pro Prozess. Wenn der Agent aus seiner Sandbox keine beliebigen Websites erreichen kann, kann er deine Identität auch nicht an beliebige Websites weitergeben. Dann muss er dich bitten, Dinge abzurufen. Das ist Reibung, aber genau die Reibung ist der Zweck.

4. Weniger preisgeben. Nutze für Tool-Accounts eine eigene, wertarme E-Mail-Adresse – nicht deine primäre Arbeitsadresse. Entferne identifizierende Angaben aus globalen Konfigurationsdateien, die der Agent liest (~/.gitconfig ist ein typisches Beispiel, das Agenten gerne einlesen). Wenn das Tool es unterstützt, betreibe es unter einem separaten OS-Nutzer mit eigenem Home-Verzeichnis. Weglassen schlägt Filtern, jedes Mal.

5. Auf Organisationsebene über einen verwalteten Proxy leiten. Wenn dein Unternehmen agentische Tools an Ingenieure ausgibt, zwinge deren Traffic über einen Egress-Proxy mit Logging und ergänze die Pipeline um Header-Inspektion. Allein DNS-Query-Logs hätten das Muster erkennen können, dass ein Agent Hunderte ungewöhnlicher Domains anspricht. Das ist dieselbe Haltung, die du für jeden CI-Runner oder jede Build-Maschine einnimmst, und genau der richtige Rahmen: Ein Agent ist Build-Infrastruktur mit eigener Meinung.

Der Bug mit der E-Mail im User-Agent wird in einem Monat vergessen sein, im Rauschen der Release Notes untergegangen. Die Lehre sollte nicht vergessen werden. Agentische Coding-Tools sind die privilegiertesten, netzwerkaktivsten und am wenigsten geprüften Programme, die die meisten von uns einsetzen, und sie improvisieren. Behandle sie entsprechend: Geh davon aus, dass alles in ihrem Kontext öffentlich ist, prüfe, was tatsächlich im Netz landet, und baue den Käfig, bevor du ihn brauchst – nicht erst, nachdem der Spam mit deinem Namen adressiert eintrudelt.