Claude Code funktioniert nach dem Prinzip eines Harness, eines Orchestrators, der Nutzereingaben samt vollständigem Sitzungskontext an das Sprachmodell schickt. Das Modell selbst hält keinen Zustand vor. Befehle ausführen, sich bei Dritten authentifizieren und MCP-Server ansprechen – das alles erledigt der Harness, nicht das Modell. Im Bild des Autors: Das Gehirn läuft in Anthropics Cloud, die Hände laufen auf den Endpunkten des Unternehmens, und genau dort müssen Sichtbarkeit und Kontrolle liegen.
Als Durchsetzungsmechanismus dienen die Managed Settings. Jeder Endpunkt mit Claude-Code-Installation erhält einen entsprechenden Datensatz – unter Mac und Linux als JSON-Datei, unter Windows als Registry-Einträge. Deren Regeln haben Vorrang vor globalen, Projekt- und Benutzereinstellungen. Im Enterprise-Plan werden Richtlinien über die grafische Oberfläche verteilt, andernfalls kann ein MDM die Datensätze auf die Endpunkte schreiben. Möglich sind unter anderem Erlaubnis- und Sperrlisten für einzelne MCP-Server, reguläre Ausdrücke über Bash-Befehle sowie das Unterbinden von Befehlsausführung durch Skills. Statische Listen kennen aber weder Kontext noch Absicht – sie seien, so der Autor, ein großer Felsbrocken im Fluss, der die Strömung stört, aber nicht stoppt.
Die neuen Sitzungs-Endpunkte protokollieren alles, was das Modell erreicht, in drei Blocktypen: text, tool_use und tool_result. Damit sind Nutzereingaben, Bash-Befehle, Lese- und Schreibvorgänge sowie MCP-Kommandos erfasst. Da das Modell serverseitig keinen Zustand hält und Skill- und Plugin-Dateien nur lokal existieren, sendet der Harness den vollen Kontext bei jedem Zug erneut. Richtig ausgewertet lassen sich daraus ein Inventar der Agenten mit ihren Skills, MCP-Servern und Plugins aufbauen. Bash-Befehle erscheinen als tool_use mit dem Namen “Bash”, MCP-Aufrufe im Schema mcp__<Server>__<Befehl>; nutzerverbundene Server tauchen statt mit lesbarem Namen als UUID auf. Jeder davon steht für eine dauerhaft hinterlegte Zugangsberechtigung auf dem Endpunkt – und 35,1 Prozent der von Token Security gefundenen MCP-Server stammen aus der Community oder aus unbekannter Quelle.
Lücken bleiben. Aktionen, die das Modell nie erreichen, sieht die Compliance API nicht – am deutlichsten Hooks, die lokal zwischen Entscheidung des Modells und Ausführung des Werkzeugs laufen und Aufrufe oder Prompts blockieren können. OpenTelemetry protokolliert dagegen Entscheidungen über Werkzeugberechtigungen samt Urheber sowie Wechsel in den bypassPermissions- beziehungsweise Auto-Modus, die in der Compliance API fehlen. Eine harte Grenze: Wer Claude Code auf einem fremden Modell betreibt, etwa über Bedrock, Foundry oder Google Cloud, erhält keinerlei Abdeckung durch die Compliance API.
Was auf der Festplatte liegt, sehen beide Ebenen nicht: Konfigurationsdateien, installierte Skills und Plugins samt .md-Dateien sowie Prozesse außerhalb einer Sitzung. Token Security findet im Schnitt mehr als zehn Konfigurationsdateien pro lokalem Agenten. Claude Code speichert die Sitzungshistorie zudem standardmäßig 30 Tage lokal – wer Zugriff auf den Endpunkt erlangt, kann sie mitlesen. Transkripte können PII, Geheimnisse und Kundendaten enthalten und werden damit selbst zu einer sensiblen Datenquelle.
Eine von Token beauftragte Umfrage der Cloud Security Alliance unter 418 IT- und Sicherheitsfachleuten zeigt die Diskrepanz: 68 Prozent bewerteten ihre Sichtbarkeit auf KI-Agenten als hoch, 82 Prozent hatten im vergangenen Jahr einen Agenten entdeckt, von dessen Existenz Security, IT oder Governance nichts wussten. Ein Administrator, der Transkripte durchsieht, kann ein aus dem Netz gezogenes bösartiges Plugin nicht von einem selbst geschriebenen legitimen unterscheiden. Dazu braucht es laut Abramov Kontext von anderer Stelle – etwa den Abgleich der auf Endpunkten laufenden Skills und Plugins mit den intern verwalteten Repositories.