KI-Coding-Agenten sind keine privaten Experimente mehr. Sie tauchen in Unternehmensumgebungen auf, und genau deshalb ist Ubers offenes ADR-Repository ein wichtiges Signal. Es betrachtet Claude Code, Cursor, OpenAI Codex CLI, Cline, Claude Desktop, Warp Terminal und opencode nicht als normale Editoren mit Autocomplete. Es behandelt sie als Systeme, die Prompts lesen, Repositories sehen, Tools auswählen, Shell-Befehle starten, Dateien ändern, MCP-Server nutzen und manchmal auf material stoßen, das wie Zugangsdaten aussieht. Diese Kette bleibt unsichtbar, wenn Security nur Prozesse und Datei-Ereignisse beobachtet.

Security-Konsole zur Überwachung von KI-Coding-Agenten

Was Uber geöffnet hat

ADR bedeutet hier Agentic Detection and Response, nicht die übliche Abkürzung für Architekturentscheidungen. Das Repository beschreibt ein Enterprise-Sicherheitssystem für KI-Agenten und sagt, es sei bei Uber eingesetzt worden. Zum Veröffentlichungszeitpunkt stand es unter Apache-2.0, war überwiegend Python, hatte rund 1.334 Sterne und 112 Forks und wurde am 10. August 2026 aktualisiert. Die Zahlen sind nicht der Beweis, zeigen aber den Marktimpuls.

Das Projekt ist kein magischer Scanner. Die Architektur umfasst Observability, Benchmark, Detection und Prevention. Öffentlich enthalten sind Sensor, ADR-Bench und Detector. Die Präventionsschicht und Teile interner Explorer-Werkzeuge fehlen. Diese Grenze ist entscheidend: Das Projekt ist eine Referenzarchitektur, kein fertiges Produktionskontrollsystem.

Das zugehörige Paper, angenommen für den MLSys 2026 Industry Track, liefert den Kontext. Es nennt drei dauerhafte Probleme: begrenzte Beobachtbarkeit, unzureichende Robustheit und hohe Erkennungskosten. Außerdem berichtet es von mehr als zehn Monaten Einsatz bei Uber, über 7.200 eindeutigen Hosts und mehr als 10.000 Agentensitzungen pro Tag. Das sind von Uber berichtete Werte, keine allgemeine Garantie.

Warum EDR und SIEM zu wenig sehen

Klassisches EDR beantwortet Systemfragen: welcher Prozess schrieb eine Datei, welches Programm öffnete eine Verbindung, welcher Host kontaktierte eine verdächtige Domain. Das bleibt wichtig. Ein Agent fügt jedoch eine Schicht zwischen menschlicher Absicht und Systemereignis ein. Ein Shell-Befehl kann harmlos wirken, aber riskant sein, wenn er aus einer Prompt-Injection in einem Issue, Dokument oder MCP-Ergebnis stammt.

Die nützliche Frage ist breiter: Was bat der Nutzer, welchen Kontext las das Modell, welchen Plan zeigte es, welche Tool Calls wurden vorgeschlagen und ausgeführt, welche Policy galt und welches Ergebnis folgte? Ohne diese Sitzungskette sieht das SOC Symptome, aber nicht die Ursache.

Der Sensor README nennt Parser für Claude Code, Cursor IDE, Cline, Claude Desktop, OpenAI Codex CLI, Warp Terminal und opencode, mit Unterschieden zwischen macOS, Linux und Windows. Ereignisse werden mit Session ID, Timestamp, Chat History, Tools, Model, Project Path und Session Context normalisiert. Genau dieses Vokabular fehlt traditionellem EDR.

Tools und MCP als neue Grenze

Die Macht des Agenten liegt nicht im Chatfenster, sondern an der Tool-Grenze. Ein Coding-Agent wird operativ relevant, wenn er ein Repository lesen, git aufrufen, Tests starten, interne Dokumentation öffnen, Tickets anfassen, Deployment-Helfer nutzen oder MCP-Server ansprechen kann. Jeder Connector kann legitim sein; zusammen entsteht ein schwer sichtbarer Berechtigungsgraph.

ADR-Bench behandelt diesen Graphen als Erkennungsfläche. Die Dokumentation spricht von etwa dreihundert Szenarien, im Detection README von 303 Szenarien, davon 261 benign und 42 malicious, mit 17 Angriffstechniken und 133 MCP-Servern. Wichtiger als die exakte Zahl ist die Form: Agenten werden in arbeitsnahen Abläufen mit bösartigen Anweisungen, synthetischen Geheimnissen und verwundbaren Diensten getestet.

Die Open-Source-Hinweise warnen deshalb vor synthetischem Angriffsmaterial und fixierten Abhängigkeiten mit bekannten CVEs. Der Benchmark gehört in eine isolierte Umgebung, nicht in die Produktion.

Was Unternehmen ändern sollten

Für CTO, CISO und Plattformteams lautet die Antwort weder generelles Verbot noch blindes Installieren. Zuerst braucht es Inventar: erlaubte Agenten, Speicherorte ihrer Logs, unterstützte Betriebssysteme, erreichbare Repositories und Aktionen ohne ständige menschliche Prüfung.

Danach kommt Least Privilege. Ein Agent sollte nicht automatisch alle Zugangsdaten, Shell-Rechte und Browser-Sitzungen des Entwicklers erben. Credential Gateways, kurzlebige Tokens, Rechte pro Repository, getrennte Entwicklungskonten und klare Regeln für MCP werden Grundhygiene.

Drittens braucht es Auditierbarkeit. Logs müssen Prompt, Tool Call und Ergebnis verbinden. Gleichzeitig ist vollständiges Mitschneiden riskant. Agenten-Telemetrie kann Code, interne Tickets, Kundendaten und zufällig eingefügte Secrets enthalten. Ein ADR-ähnliches Programm braucht Redaction, Zugriffskontrolle, Verschlüsselung, begrenzte Aufbewahrung und vorsichtigen SIEM-Export.

Was Security-Teams lernen

Eine verdächtige Agentensitzung sieht nicht unbedingt wie Malware aus. Es kann eine normale Entwicklermaschine mit normalem Editor und legitimen Terminal sein. Die Anomalie liegt vielleicht in einer Tool-Reihenfolge, einem Prompt-Muster, dem Lesen von Credential-Pfaden, einem generierten Skript mit unerwarteter Netzwerkverbindung oder einem MCP-Server, der Dokumentation in Aktion verwandelt.

Regeln müssen Kontext kombinieren. Prozess-Telemetrie ist zu flach, Prompt-Scanning zu fragil, und Modellausgabe allein beweist nicht, was ausgeführt wurde. Die nützliche Einheit ist die Sitzung: Eingaben, Kontext, Werkzeuge, Datei- und Netzwerkeffekte, Policy-Entscheidungen. Reife Teams wollen Erkennungen, die Risiko erklären.

Auch Anbieter geraten unter Druck. IDEs, Cloud-Workspaces, Terminals, Agent-Frameworks und MCP-Plattformen werden strukturierte, exportierbare Logs liefern müssen. Private Formate erschweren Enterprise-Adoption und Incident Response.

Größer als ein Repository

Der direkte Hacker-News-Beitrag zu Uber ADR war klein, doch verwandte Diskussionen über Cloud-Coding-Agenten, Credential Gateways und Sandboxes waren deutlich lebendiger. Überall geht es um dieselben Fragen: Wo läuft der Agent, welche Secrets sieht er, wie isoliert ist der Workspace, wer haftet, wenn Automatisierung Grenzen überschreitet?

ADR gehört zu einem größeren Übergang hin zu verwalteter Agenten-Infrastruktur. Wie beim Cloud-Einsatz starten Teams oft informell; später folgen Identität, Logging, Kostenkontrolle, Policies und Incident Response. Agenten starten im Terminal des Entwicklers, aber das Risiko trägt das Unternehmen.

Praktisch kann ein Quartal reichen, um zu beginnen: genehmigte Tools kartieren, Umgebungs-Credentials reduzieren, vorhandene Logs aus Editor, Shell, MCP-Gateway, Git, Pull Requests und CI korrelieren, dann Tests mit synthetischen Secrets in einem isolierten Repository durchführen. Wenn niemand sieht, dass ein Agent eine sensible Datei las oder Code außerhalb des Auftrags änderte, ist die erste Sicherheitsaufgabe klar.

Der Kern lautet: KI-Coding-Agenten sind keine einfachen Editoren und keine Mitarbeiter. Sie sind delegierte Systeme, die Prompts und Kontext in Tool-Nutzung verwandeln. Die nächste Phase entscheidet sich daran, ob diese Arbeit beobachtbar, begrenzt, prüfbar und wiederherstellbar wird.