Wohin telefoniert Ihr Coding-Agent? Vier Agenten, ein Proxy, ein DSGVO-Inventar

Ein kaum sichtbares Zeichen im System-Prompt hat gereicht, um Claude Code zum Spyware-Thema zu machen.

Der inzwischen entfernte Mechanismus markierte bestimmte China-bezogene Signale so unauffällig, dass Nutzer sie in normalen Logs kaum erkennen konnten. Anthropic erklärte, damit gegen unerlaubten Weiterverkauf und Modelldestillation vorgegangen zu sein. Ob man das „Backdoor“ nennen sollte, ist umstritten. Dass verstecktes Verhalten Misstrauen erzeugt, nicht.

Nur beantwortet die Debatte die wichtigere Frage nicht: Was senden Coding-Agenten im normalen Betrieb, ganz ohne spektakulären Skandal?

Ich habe vier von ihnen mitlesen lassen: Claude Code, Codex CLI, Gemini CLI und GitHub Copilot. Alle bekamen dieselbe Aufgabe, alle liefen durch denselben Proxy. Dabei zeigte sich neben dem bekannten Modell-Call ein zweiter Kanal aus Telemetrie, Error-Reporting und Hintergrundverkehr.

Dieser Kanal ist weniger spektakulär als eine angebliche Hintertür. Für den Datenschutz ist er wichtiger. Denn die zusätzlichen Datenströme können Empfänger und Verarbeitungsvorgänge sichtbar machen, deren Abdeckung in AVV, Subprozessorenliste, Toolprüfung und Verzeichnis von Verarbeitungstätigkeiten gesondert geprüft werden muss.

Ein Hinweis vorab: Dieser Beitrag ist keine Rechtsberatung. Er ist als empirischer Begleiter zu einer rechtlichen Frage zu verstehen, die ich an anderer Stelle ausführlicher behandle. Wer den juristischen Rahmen sucht (AVV, Inferenzregionen, „die Spur existiert“), findet ihn im Beitrag Coding Agents und DSGVO: Was darf der Agent sehen?.

Was bekannt ist und was gefehlt hat

Die Technik, um diese Daten mitzulesen, ist bekannt. Man klemmt einen abfangenden Proxy zwischen den Agenten und das Netz, terminiert TLS mit einem eigenen Zertifikat und liest mit, was sonst verschlüsselt vorbeirauscht. The Register hat im April 2026 genau das mit Claude Codes Telemetrie gemacht und die Endpunkte einzeln aufgelistet.

Was gefehlt hat, ist der Vergleich. Vier Agenten, ein Proxy, ein Datensatz, den ein Datenschutzbeauftragter tatsächlich lesen kann. Nicht „Tool X telefoniert nach Hause“, sondern ein technisches Empfänger- und Datenkategorien-Inventar pro Agent, quartalsweise wiederholbar, das sich versionieren und vergleichen lässt. Es unterstützt die Prüfung von AVV, Subprozessoren und Verzeichnis von Verarbeitungstätigkeiten, ersetzt sie aber nicht. Das ist der Beitrag, den dieser Text leistet, und die einzige Neuheit, die er für sich beansprucht.

Im Betrieb fallen bei einem Coding-Agenten drei Verkehrsklassen an. Klasse A ist der Modell-Call: Prompt, Kontext, Werkzeugdefinitionen, Konversationshistorie. Klasse B ist die First-Party-Telemetrie: Nutzungs- und Zuverlässigkeitsmetriken an den Hersteller selbst. Klasse C ist alles Übrige: Error-Reporting, Feature-Gates, Update-Checks, Rate-Limit-Poller, oft an Dritte. Ob Modell-Call, Telemetrie und Error-Reporting vertraglich abgedeckt sind, hängt von Anbieter, Tarif, Authentifizierungsweg und Vertrag ab. Der Mitschnitt zeigt, welche Datenströme gesondert geprüft werden sollten, und genau dort stecken die Überraschungen.

Im DSGVO-Beitrag steht die Behauptung, dass diese zweite Spur existiert. Die Mitschnitte selbst veröffentliche ich nicht: Selbst bereinigte Flow-Dateien können Kontokennungen, lokale Pfade, Prompts und Quellcode enthalten. Stattdessen gibt es das vollständige Research-Kit zum Nachbauen (ZIP, 28 KB) – mit Test-Fixture, Methodik, mitmproxy-Skripten, Analyseanleitung und leerem Endpunkt-Inventar.

So lässt sich der Test nachbauen

Der Aufbau kostet wenig und steht in einer halben Stunde. mitmproxy installieren, den Agenten per Umgebungsvariable über den Proxy laufen lassen, dem selbstsignierten Zertifikat vertrauen, den Verkehr aufzeichnen. Die Stunden gehen fürs Zertifikatsvertrauen drauf, weil jede Laufzeitumgebung ihre eigene Vorstellung davon hat, wo eine vertrauenswürdige CA liegt.

pipx install mitmproxy
mitmdump --mode regular@8082 -s addons/classify.py -w raw.flows

export HTTPS_PROXY=http://localhost:8082 HTTP_PROXY=http://localhost:8082
export NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem   # Claude Code, Gemini CLI (Node)
export CODEX_CA_CERTIFICATE=~/.mitmproxy/mitmproxy-ca-cert.pem  # Codex (Rust)
export SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem         # Codex, Fallback

Node-basierte Tools lesen NODE_EXTRA_CA_CERTS. Rust-basierte Tools wie Codex ignorieren das und brauchen CODEX_CA_CERTIFICATE oder SSL_CERT_FILE. Editor-basierte Werkzeuge wie GitHub Copilot ignorieren beide und erwarten die CA im Vertrauensspeicher des Betriebssystems, weil ihr Verkehr durch den Electron-Prozess von VS Code läuft, nicht durch eine CLI, die Sie steuern.

Ein Detail, das leicht Stunden kostet und einen Fehlbefund produziert: Die Schwärzung, die Ihre eigenen Schlüssel aus dem Mitschnitt streicht, sollte nicht während der Weiterleitung laufen. Ein Addon, das den Authorization-Header entfernt, bevor mitmproxy die Anfrage weiterleitet, schickt eine Anfrage ohne Authentifizierung an den Server und provoziert einen 401, der aussieht wie eine echte Authentifizierungssperre. Also roh aufzeichnen, offline schwärzen, dann die Rohdatei löschen:

mitmdump -n -r raw.flows -s addons/redact.py -w capture.flows && rm raw.flows

Damit die vier Läufe vergleichbar sind, dieselbe Aufgabe in einem Wegwerf-Repository: add a docstring to the function in sample.py, eine sample.py mit genau einer undokumentierten Funktion. Vier Durchläufe pro Agent: kalter Start, warme Sitzung, fünf Minuten Leerlauf ohne Eingabe (das fängt Hintergrund-Poller), und ein Lauf mit gesetztem Kill-Switch. Getestet im Juli 2026, die exakten Versionen stehen im Anhang, und das ist keine Formalität: Endpunkte verschieben sich pro Version. Claude Code ab Version 2.1.116 nutzt downloads.claude.ai statt storage.googleapis.com, Codex hat den unten beschriebenen Poller zwischen zwei Minor-Versionen umgebaut.

Vier Grenzen gehören vor die Ergebnisse, nicht dahinter: Gemini erreichte wegen UNSUPPORTED_CLIENT gar keinen Modell-Call, die Codex-Läufe scheiterten früh an Authentifizierung oder Quota, der ChatGPT-Auth-Verkehr von Codex war nicht vollständig lesbar, und das Copilot-Profil hatte weitere KI-Erweiterungen aktiv (Cline, Roo Code). Das sind vier unterschiedliche Produkt- und Auth-Situationen, kein Satz sauber abgeschlossener Standardläufe. Und ein Proxy sieht nur, was über ihn läuft: Verbindungen mit Zertifikat-Pinning oder über QUIC können fehlen. Wo unten „Hosts“ stehen, sind „im Proxy beobachtete Hosts“ gemeint.

Eine Grenze noch, die für dieses Publikum zählt: Alle vier liefen in persönlichen oder API-nahen Konfigurationen (Claude-Max-Subscription, Gemini OAuth-Personal, Codex per ChatGPT-Login und API-Key, Copilot Individual). Business-, Enterprise- und Data-Residency-Tarife können andere Endpunkte, Standardwerte und Verträge verwenden; die Ergebnisse lassen sich nicht ohne Weiteres darauf übertragen.

Zum Rahmen in einem Satz, weil er wichtig ist und dann erledigt: Für diesen Test wurde ausschließlich eigener, autorisierter Verkehr auf einer eigenen Testmaschine untersucht. Bei Unternehmenssystemen, Fremddaten oder gemeinsam genutzten Konten sind interne Freigaben und rechtliche Vorgaben gesondert zu prüfen.

Claude Code: die dokumentierten Verdächtigen schwiegen, ein undokumentierter nicht

Erwartet hatte ich statsig.anthropic.com und cdn.growthbook.io, die beiden Telemetrie-Hosts, die frühere Reverse-Engineering-Analysen genannt haben, dazu einen Sentry-Treffer aus der Fehlerberichterstattung. Keiner der drei tauchte im Mitschnitt auf.

Über eine volle Sitzung (Bootstrap, Feature-Auswertung, MCP-Registry-Abruf, vier Telemetrie-Batches, drei Inferenz-Roundtrips) ging keine einzige Anfrage an einen *.sentry.io-Host. Das sagt weniger, als es scheint: Die Doku führt Sentry als standardmäßig aktives Error-Reporting, aber ein Fehlerberichtsdienst sendet in einer fehlerfreien Sitzung nichts. Der Mitschnitt zeigt also nur, dass in dieser nicht abstürzenden Sitzung kein Sentry-Verkehr auftrat, kein Beleg für und keiner gegen die dokumentierte Nutzung. Wer das prüfen will, muss gezielt einen berichtspflichtigen Fehler provozieren. Die Feature-Flag-Auswertung wiederum, die eine Payload im GrowthBook-Format trägt, kam nicht von GrowthBooks CDN, sondern von api.anthropic.com/api/eval/sdk-<id>, also über Anthropics eigene Domain durchgereicht. Mit Claude-Max-Subscription als Authentifizierung wirkt die frühere „kontaktiert cdn.growthbook.io direkt“-Behauptung in Version 2.1.205 veraltet.

Der interessante Fund stand in keiner Hersteller-Doku als Telemetrie-Empfänger. classify.py markierte ihn als unbekannten Host: http-intake.logs.us5.datadoghq.com. Er sendete dreimal während eines einzigen warmen Turns, POST /api/v2/logs, und spiegelte dieselben tengu_feature_ok-Events, die auch an Anthropics eigenen Telemetrie-Endpunkt gingen: gleiche session_id, gleiches Modell, gleiche Felder. Authentifiziert über einen DD-API-KEY-Header mit einem eingebetteten clientseitigen Datadog-Schlüssel. Datadog ist ein Drittanbieter; die aktuelle Claude-Code-Doku nennt als Empfänger Anthropics eigene Metrics-Telemetrie und Sentry, aber kein Datadog. Ein echter dritter Empfänger, der dieselben Betriebsereignisse mit gleicher session_id erhält wie Anthropics eigener Telemetrie-Endpunkt. Eine Prüfung, die nur den Modell-Endpunkt betrachtet, übersieht ihn leicht. Ganz neu ist der Datadog-Kontakt nicht: Issue #16433 meldete wiederkehrende datadoghq.com-Aufrufe schon im Januar 2026. Was dieser Lauf hinzufügt, ist der Blick in die Payload und die Sitzungszuordnung, nicht die Erstsichtung.

Noch eine Beobachtung für die Datenkategorien-Liste, ohne Wertung: Der globale Inhalt Ihrer CLAUDE.md reist in der ersten Nutzernachricht jeder Sitzung mit, auch in einem Wegwerf-Repo ohne eigene Projekt-CLAUDE.md. Was Sie dem Agenten als Dauerkontext mitgeben, verlässt die Maschine mit dem ersten Turn jeder Sitzung.

MCP-Server sind ein weiterer ausgehender Kanal, den Teams übersehen, wenn auch ein konfigurationsabhängiger: Claude Code spricht beim Sitzungsstart alle konfigurierten MCP-Server an, unabhängig von der aktuellen Aufgabe. Auf dieser Maschine traf das einen global konfigurierten PostHog-Server und zwei Google-Workspace-Presets (gmail.mcp.claude.com, gcal.mcp.claude.com), die in keiner lokalen Konfiguration standen. Was ein MCP-Server macht und wie man ihn prüft, steht im Beitrag MCP-Server erklärt.

Die brauchbaren Schalter: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 schaltet die nicht-essenzielle Klasse ab, DISABLE_TELEMETRY=1 die Metriken. Und CLAUDE_CODE_USE_BEDROCK beziehungsweise _USE_VERTEX leiten die Inferenz über die jeweils konfigurierte Bedrock- oder Vertex-Region und deaktivieren nicht-essenziellen Verkehr standardmäßig mit. Wie diese EU-Inferenz-Konfiguration in der Praxis aussieht, behandelt der Beitrag Claude Code im Team: Kosten, Datenschutz, Grenzen.

Codex: sauberer als sein Ruf, aber Git-Metadaten reisen mit

Codex über ChatGPT-Auth ist nicht sauber mitzuschneiden: Cloudflare blockiert vor chatgpt.com/backend-api/* den über mitmproxy vermittelten Zugriff. Der veränderte TLS-Fingerprint (JA3/JA4), der den Handshake nicht wie einen Browser aussehen lässt, ist die plausible Ursache, ließ sich im Test aber nicht eindeutig als das ausschlaggebende Bot-Schutzsignal nachweisen. api.openai.com liegt nicht hinter diesem Schutz. Der Weg zu lesbaren Bodies ist deshalb API-Key-Auth: Dort beantwortet wss://api.openai.com/v1/responses den Handshake mit 101, die Verbindung bleibt offen, Request- und Response-Bodies sind vollständig lesbar.

Zwei ältere Behauptungen über Codex musste ich nach dem Capture zurücknehmen, beide zugunsten von Codex. Die erste: Der wham/usage-Poller, der in früheren Analysen alle 60 Sekunden nachfragte, ob der Nutzer noch darf, ist repariert. Codex-Issue #10869 und der zugehörige PR #10973, seitdem ist der Poller an ChatGPT-Auth gebunden. Die getestete Version 0.142.5 enthält den Fix, und der Leerlauftest bestätigt ihn. Er war einmal ein 60-Sekunden-Takt, jetzt läuft er nur noch unter ChatGPT-Auth. Die zweite: Frühere Quellen sprachen von zeilenweisen Fingerprints des akzeptierten Codes. Der aktuelle Quellcode setzt die zeilenweisen Hashes vor dem Upload auf null. Was die Maschine verlässt, sind aggregierte Zähler für hinzugefügte und gelöschte Zeilen, ein repo_hash (SHA-1 der Git-Remote) und Turn- und Thread-IDs. Ihre Diffs werden in diesem Build nicht zeilenweise übertragen.

Womit nicht gesagt ist, dass nichts Interessantes mitreist. Der Header x-codex-turn-metadata steht in jeder WebSocket-Nachricht und trägt eine installation_id (persistente UUID pro Installation), Session-, Thread- und Turn-IDs und ein Feld workspaces: eine Zuordnung, deren Schlüssel absolute lokale Dateipfade sind und deren Werte den letzten Git-Commit-Hash enthalten. Ein echter Commit-SHA und der absolute Pfad Ihres Arbeitsverzeichnisses verlassen die Maschine als Metadaten, auch wenn der Turn selbst mit insufficient_quota scheitert. Hinzu kommen bei jedem Turn 14 Werkzeug-Schemata als vollständige JSON-Definitionen.

Der Statsig-OTel-Exporter (ab.chatgpt.com/otlp/v1/metrics) tauchte in keinem der beiden Läufe auf, was aber nichts beweist: Beide Läufe scheiterten nach wenigen Sekunden an Authentifizierung oder Quota, und Metriken werden in größeren Intervallen gebündelt. „Nicht beobachtet“ ist hier nicht „aus“. Die Kill-Switches stehen fest: [analytics] enabled = false schaltet die Produkt-Events ab, [otel] metrics_exporter = "none" die Metriken. Die EU-Inferenz läuft über eine Azure-OpenAI-base_url.

Gemini: OTel ist aus, die separate Nutzungsstatistik ist an

Bei Gemini muss man zwei Kanäle auseinanderhalten. Die dokumentierte OpenTelemetry-Telemetrie ist standardmäßig aus (telemetry.enabled=false), und sie blieb aus. Nichts ging an einen OTel-Collector, dokumentiertes Verhalten also bestätigt. Daneben läuft aber ein zweiter, standardmäßig aktiver Kanal, und der ist der eigentliche Befund dieses Abschnitts.

play.googleapis.com/log ist Googles Clearcut/CONCORD-Pipeline, eine Infrastruktur, die viele Google-Produkte gemeinsam nutzen. Sie lief mit Event-Namen wie startup_stats und new_prompt. Die Payload trug die authentifizierte Google-Konto-E-Mail im Klartext, eine Liste von rund 70 CLI-Konfigurationsflags, CLI- und Node-Version, OS-Plattform und eine Sitzungs-UUID. Das ist nicht der OTel-Exporter, den die Doku als opt-in beschreibt, sondern die Nutzungsstatistik über privacy.usageStatisticsEnabled, die laut Config-Referenz standardmäßig aktiv ist und einen eigenen Schalter hat. Die Dokumentation führt diesen Kanal als „Usage Statistics“. Der Quellcode der getesteten Version 0.50.0 hängt dem Event aber ein Feld client_email an, befüllt mit der zwischengespeicherten Google-Konto-Adresse (clearcut-logger.ts, mit dem Kommentar, man solle „entweder E-Mail oder Install-ID loggen, nicht beides“). Genau diese Adresse stand im Klartext im Mitschnitt. Implementierung und beobachteter Verkehr stimmen hier überein, und beide tragen mehr als eine anonyme Kennung. OTel und Clearcut gehören im technischen Inventar getrennt erfasst und dann darauf geprüft, wie sie im VVT und in der Empfängerdokumentation abzubilden sind.

Eine Randnotiz mit Folgen gehört noch ins Protokoll: Auf diesem Client kommt die kostenlose persönliche OAuth-Anmeldung gar nicht mehr bis zum Modell. loadCodeAssist gibt für die Individual-Stufe reasonCode: UNSUPPORTED_CLIENT zurück, mit dem Verweis, zur Antigravity-Suite zu migrieren. Der Stichtag vom 18. Juni 2026 ist damit bestätigt: Die kostenlose Anmeldung endet an der Berechtigungsprüfung, vor jedem Inferenz-Call. Wenn telemetry.enabled aus bleibt, bleibt die dokumentierte Pipeline aus; die separate Nutzungsstatistik braucht ihren eigenen Schalter. Die EU-Inferenz läuft über eine Vertex-AI-Region.

Copilot: die Standard-Telemetrie sendet den Prompt, nicht nur Metadaten

Der stärkste Befund der Runde kommt von GitHub Copilot, und er ist kein bloßes Metadaten-Detail. telemetry.individual.githubcopilot.com sendet in der Standardkonfiguration nicht bloß aggregierte Betriebszahlen. Die bereinigten Mitschnitte enthalten den wörtlichen Test-Prompt, den umgebenden Quellcode, den absoluten lokalen Pfad des Wegwerf-Repos und den generierten Docstring, und zwar in Telemetrie-Feldern, nicht im Modell-Kanal. Im warmen Lauf waren es sieben Batches. Die Feldzuordnung ist eindeutig: conversation.messageText trägt den Nutzer-Prompt, engine.messages trägt Prompt, Quellcode, absoluten Pfad und generierten Text.

Der Leerlauf macht den Befund schärfer. Nach fünf Minuten mit fokussiertem Editor und ohne Eingabe gingen trotzdem sieben Copilot-Telemetrie-Batches raus, und die trugen Quellcode, Pfad und generierten Inhalt aus der vorangegangenen Inline-Aktivität mit. Niemand tippt etwas, und der Kanal redet weiter.

Ein zweiter Telemetrie-Strom lief parallel: mobile.events.data.microsoft.com, Microsofts 1DS/OneCollector, mit 12 POSTs im warmen und 3 im Leerlauftest. Die Event-Namen waren überwiegend GitHub.copilot-chat/*, die Felder enthielten aber nur Metadaten (Device-, Machine- und Session-IDs, Modell- und Request-IDs, Sprach- und Zeilenzähler, A/B-Zuordnung). Anders als beim GitHub-Host fand eine Klartext-Suche hier keinen Prompt und keinen Quellcode.

Hier wurde die Zuordnung zur Detektivarbeit, und die ehrliche Antwort lautet an einer Stelle: unsicher. VS Code selbst und andere installierte Erweiterungen (auf dieser Maschine waren Cline und Roo Code sichtbar) erzeugen Update-, Marketplace-, OpenRouter- und Application-Insights-Rauschen. Einen Host schreibe ich Copilot nur zu, wenn Pfad oder Event-Namespace es belegen. Die OneCollector-Batches mit GitHub.copilot-chat/*-Namen gehören Copilot. Die generischen Application-Insights-Batches an westus-0.in.applicationinsights.azure.com, die auch nach dem Abschalten noch feuerten, nannten keinen Copilot-Event. Ich führe sie deshalb als Editor-Grundrauschen mit unsicherer Zuordnung, nicht als Copilot-Umgehung.

Der Kill-Switch funktioniert, und zwar als echter Verkehrsstopp: Mit "telemetry.telemetryLevel": "off" in den VS-Code-Benutzereinstellungen verschwanden beide beobachteten Telemetrie-Ströme vollständig, während Inline-Vervollständigung und Agent-Inferenz weiter mit 200 antworteten und der Edit durchlief. Das ist getrennt von der Trainingsdaten-Einstellung bei GitHub. Die EU-Anbindung läuft über Copilot Data Residency (Enterprise, opt-in). GitHub dokumentiert, dass darunter neben Code, Prompts und Antworten auch Copilot-bezogene Logs und Telemetrie regional gespeichert werden. Zu prüfen bleibt, ob die hier beobachteten Telemetrie-Endpunkte und mögliche vorgelagerte Dienste vollständig unter diese Zusage fallen, und genau diese Frage gehört in die Prüfung.

Was jeder Agent sendet, nebeneinander

Das ist das wichtigste Artefakt. Vier Agenten, acht Kriterien, Stand Juli 2026. Werte aus dem Capture, wo nichts anderes vermerkt ist; Doku-Stände, Konfig-Optionen (etwa der EU-Inferenz-Pfad) und nicht beobachtete Ziele sind als solche markiert.

Die Zeile, auf die es ankommt, ist „Prompt in Telemetrie“. Nur bei Copilot wurden unter den getesteten Bedingungen Prompt- und Codeinhalte in einem zusätzlich beobachteten Telemetriekanal gefunden. Die Codex- und Gemini-Läufe erlauben keine gleich starke Gegenaussage: Bei Gemini wurde der aktivierte Zustand nicht getestet, bei Codex scheiterten die Läufe zu früh, um ausbleibende gebündelte Telemetrie zu bewerten. Daten, die der Modell-Kanal ohnehin sieht, tauchen bei Copilot also ein zweites Mal auf, in einem Kanal, der separat geprüft werden muss.

Der zweite Kanal

Die juristische Sorgfalt richtet sich mit voller Präzision auf den Modell-Kanal: AVV nach Art. 28, Inferenzregion, technische und organisatorische Maßnahmen, Drittlandtransfer. Alles nötig, aber alles auf Klasse A bezogen. Der zweite Kanal geht daneben zur Tür hinaus, weil eine Prüfung, die beim Modell-Endpunkt endet, ihn nicht erfasst. Ob der AVV den Datadog-Empfänger, den Clearcut-Kanal oder die Copilot-Telemetrie mit abdeckt, hängt von Anbieter, Tarif und Vertrag ab und ist genau die Prüffrage: teils andere Empfänger, teils derselbe Anbieter mit einem anderen Verarbeitungsvorgang als dem Modell-Call. In ein technisches Empfänger- oder Subprozessoren-Inventar gehört deshalb nicht ein Empfänger pro Agent, sondern die Summe der Hosts, die der Agent im Mitschnitt kontaktiert. Der Mitschnitt liefert diese Liste. Das ist der Zweck der Übung.

Vom Capture zur Prüfliste

Aus dem Mitschnitt wird eine Prüfzeile pro Agent: nüchtern, mit Feldern aus dem, was der Mitschnitt zeigt. Das ist kein Rechtsrat, ich bin kein Anwalt, sondern eine Grundlage für das Gespräch mit dem Datenschutzbeauftragten.

„US" bezeichnet dabei den Anbietersitz; der konkrete Verarbeitungsort lässt sich aus dem Capture nicht ableiten.

Der nächste Schritt ist die Minderung, weil ein Befund ohne Schalter nur Beunruhigung ist. Jeder Befund bekommt eine konkrete Abschaltmöglichkeit:

Angrenzende Themen, nur als Verweis: die Dokumentationspflichten aus NIS2, die Rollenfrage aus der KI-Verordnung und die Betriebskosten dieser Kanäle im Beitrag KI-Coding-Tools-Kosten 2026.

Quartalsweise, als Datensatz

Ein Mitschnitt ist eine Momentaufnahme, und die Tools ändern sich im Wochentakt: Poller werden umgebaut, Installer-Hosts wandern. Wer heute prüft und in einem Quartal wieder prüft, braucht keinen neuen Blogpost, sondern einen Vergleichslauf.

Deshalb ist das eigentliche Artefakt nicht dieser Text, sondern das Endpunkt-Inventar dahinter: eine domains.yaml, ein Host pro Zeile, mit Verkehrsklasse und Standardverhalten. Ein Klassifizierer gleicht jeden neuen Mitschnitt mit dieser Liste ab und markiert jeden nicht gelisteten Host. Ein neuer Host im Vergleich ist die Frage fürs nächste DPO-Gespräch. Genau so hat dieser Lauf den Datadog-Host gefunden: nicht durch Suchen, sondern weil ein unbekannter Host aus der Reihe fiel.

Der AVV deckt das erwartete Gespräch. In dieser Übung geht es darum, das zweite Gespräch in derselben Leitung hörbar zu machen, das eine Prüfung, die beim Modell-Endpunkt endet, leicht überhört. Jetzt hört jemand quartalsweise zu und schreibt den Empfänger auf.

Quellen und Testumgebung

Getestet am 9. Juli 2026 auf macOS. Proxy: mitmproxy 12.2.3, per pipx installiert, eigene CA unter ~/.mitmproxy/. Die getesteten Versionen, weil alle Aussagen oben an diese Stände gebunden sind:

• Claude Code 2.1.205 · Auth: Claude-Max-Subscription
• Codex CLI 0.142.5 · Auth: API-Key und ChatGPT-Login, beide geprüft
• Gemini CLI 0.50.0 · Auth: OAuth-Personal
• GitHub Copilot · IDE-Erweiterung in VS Code, keine CLI, über den Editor aufgezeichnet

Externe Bezugspunkte, auf die sich der Text stützt: die Telemetrie-Analyse von The Register zu Claude Code (April 2026); Codex-Issue #10869 und der zugehörige PR #10973 unter github.com/openai/codex; die Hersteller-Dokumentation zu Claude Code Data Usage, zur Gemini-CLI-OpenTelemetry und zu den VS-Code-Telemetrie-Einstellungen. Endpunkte verschieben sich pro Version; ein Lauf mit anderen Versionsständen kann andere Hosts zeigen. Das Research-Kit enthält deshalb ein leeres domains.yaml-Inventar und die Skripte, mit denen sich eigene Mitschnitte klassifizieren und vergleichen lassen.