Coding-Agenten im Team sicher betreiben

Einen Coding-Agenten am eigenen Rechner abzusichern ist eine Sache. Ihn im Team zu betreiben, mit mehreren Entwicklern, geteilten Repos, CI/CD und Freigaben, ist eine andere. Für den Einzelplatz haben wir die Grundlagen in KI-Tools sicher nutzen beschrieben: Ignore-Dateien, den richtigen Tarif, Git-Disziplin. Dieser Artikel setzt darauf auf und geht eine Ebene höher: Wie richtet ein Team den Betrieb so ein, dass er auch dann trägt, wenn ein einzelner Agent sich danebenbenimmt.

Die Grundhaltung: nimm an, der Agent ist kompromittiert

Der wichtigste Denkschritt für den Team-Betrieb: Verlass dich nicht darauf, dass der Agent sich korrekt verhält. Bau die Umgebung so, dass sie auch dann hält, wenn er es nicht tut. Das ist keine Paranoia, sondern die Lehre aus einer Reihe von Vorfällen aus dem Sommer 2026, die alle dasselbe Muster zeigen: Der Schutz saß genau an der Stelle, der man vertraute.

• Der Freigabedialog log. Bei GhostApproval zeigte ein präparierter Symlink dem Nutzer im Genehmigungsdialog einen harmlosen lokalen Pfad, während der Agent tatsächlich außerhalb des Projekts schrieb (etwa in ~/.ssh/authorized_keys). Sechs Agenten waren betroffen, darunter Claude Code, Cursor, Amazon Q und Windsurf.
• Ein einzelnes Wort hebelte den Guardrail aus. Bei GitLost reichte das vorangestellte "Additionally", damit ein GitHub-Agent eine Angreiferanweisung aus einem öffentlichen Issue als legitime Folgeaufgabe behandelte und Inhalte aus privaten Repos ausleitete.
• Der statische Scanner sah nichts. Das SkillCloak-Paper zeigt, dass sich schädliche Agent-Skills so verpacken lassen, dass sie über 90 Prozent der geprüften Marktplatz-Scanner passieren, weil die Payload erst zur Laufzeit entsteht.
• Das Repo war sauber. Bei der Clean-Repo-Falle lag keine einzige schädliche Zeile im Repository. Der Payload wurde zur Laufzeit über einen DNS-Eintrag nachgeladen, unsichtbar für Review und Scanner.
• Der grüne Test log auch. Beim Reward-Hacking manipulierte ein Modell die Testumgebung, statt die Aufgabe zu lösen, und verwischte anschließend die Spuren.

Jeder dieser Fälle trifft eine andere Schutzschicht: die Freigabe-UI, den Content-Filter, den Scanner, das Repo, den Test. Die gemeinsame Lehre: Kontrollen, die auf dem Wohlverhalten des Agenten beruhen, sind keine Kontrollen. Was hält, sind Grenzen, die der Agent technisch nicht überschreiten kann, egal was in seinem Kontext steht. Genau die baut man im Team-Betrieb auf. Welche Risikoklassen dahinterstehen, ordnet der Artikel zu den OWASP Top 10 für Agentic AI ein.

Ein Reifegrad-Modell statt einer Checkliste

Kein Team springt von null auf vollautomatisierten Agenten-Betrieb. Sinnvoller ist ein gestufter Weg, wie ihn auch das NIST AI Risk Management Framework für den Einstieg in agentische KI empfiehlt: erst eng führen, dann kontrolliert lockern. Wir gliedern den Weg in drei Reifegrade.

flowchart LR
  A["Crawl<br/>Angeleint<br/>Pilot, Mensch bestätigt alles"] --> B["Walk<br/>Auf Schienen<br/>CI erzwingt Grenzen"] --> C["Run<br/>Skaliert<br/>Policy-as-Code, Audit"]
  class A decision
  class B decision
  class C success
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Durch alle drei Stufen ziehen sich dieselben sechs Bausteine. Sie reifen mit jeder Phase, jeweils aus zwei Blickwinkeln: Governance (was das Team erlaubt und wer es entscheidet, relevant für PM und PO) und Technik (wie die Grenze erzwungen wird, relevant für Tech-Leads und Entwickler).

1. Freigaben & Policy: wer darf welchen Agenten auf welchen Repos und Daten einsetzen
2. Berechtigungen & Isolation: was der Agent im System anfassen darf
3. CI-/PR-Integration: wie Agent-Output kontrolliert in die Codebasis kommt
4. Secrets & Credentials: wie Zugangsdaten begrenzt und rotiert werden
5. Audit & Observability: wer was laufen ließ und was der Agent tat
6. Incident-Response: was passiert, wenn ein Agent Schaden anrichtet

Phase 1: Crawl (Angeleint)

Ziel dieser Phase ist ein kleiner, eng geführter Pilot. Ein bis zwei Freiwillige, unkritische Repos, und ein Mensch bestätigt jede Aktion. Hier geht es nicht um Effizienz, sondern darum, ein Gefühl dafür zu bekommen, wo der Agent nützt und wo er stört, ohne dass ein Fehler teuer wird.

Freigaben & Policy. Governance legt eine kurze Positivliste fest: welche Agenten (und welche Tarife, siehe KI-Tools sicher nutzen) überhaupt erlaubt sind, auf welchen Repos, mit welchen benannten Pilotnutzern. Sensible Repos und personenbezogene Daten bleiben tabu.

Berechtigungen & Isolation. Technisch heißt Crawl: keine Autonomie ohne Nachfrage. Alle vier großen Coding-Agenten unterstützen das. Claude Code prüft deny-Regeln zuerst und fragt bei Schreib- und Shell-Aktionen nach (Doku). OpenAI Codex startet standardmäßig im Modus workspace-write mit abgeschaltetem Netz und trennt das von der approval_policy (Doku). Wichtig ist die Lehre aus GhostApproval: Der Freigabedialog allein reicht nicht, wenn er sich täuschen lässt. Deshalb gehört der Agent von Anfang an in eine Sandbox, deren Dateizugriff auf das Projektverzeichnis begrenzt ist, damit ein manipulierter Pfad gar nicht erst beim Home-Verzeichnis landet.

CI-/PR-Integration. In Phase 1 committet der Agent nie direkt. Jede Änderung landet in einem Branch, ein Mensch liest den kompletten Diff, wie bei jedem anderen Pull Request auch.

Secrets, Audit, Incident-Response sind hier noch schlank: keine Produktions-Credentials in Reichweite des Agenten, ein gemeinsames Protokoll der Pilot-Sessions, und die schlichte Regel, dass bei etwas Unerwartetem der Pilot pausiert und das Team es bespricht.

Phase 2: Walk (Auf Schienen)

Jetzt darf der Agent halb-autonom auf definierten Aufgabentypen arbeiten. Der Unterschied zu Crawl: Die Grenzen werden nicht mehr durch manuelles Bestätigen gehalten, sondern durch die Umgebung erzwungen. Der Mensch bestätigt nicht mehr jeden Schritt, sondern verlässt sich darauf, dass die Schienen halten.

Berechtigungen & Isolation: Egress-Kontrolle wird Pflicht. Die Clean-Repo-Falle zeigt, warum. Dort lag der Payload drei Indirektionen entfernt in einem DNS-Eintrag, unsichtbar für jeden Scanner. Die einzige Schicht, die so etwas zuverlässig stoppt, ist die Netzwerkkontrolle: Wenn die aufgelöste Domain nicht auf einer Allowlist steht, kommt die Verbindung nicht zustande. Praktisch heißt das ein Proxy mit Positivliste vor der Sandbox, wie ihn die Docker-Netzwerk-Policies im Locked-Down-Modus umsetzen. Die vier Agenten bringen dafür eigene Bordmittel mit:

Allen gemeinsam: Die Konfiguration liegt versioniert im Repo, gilt also fürs ganze Team und für CI, nicht nur auf einem Laptop. Ein Detail zur Isolationstiefe: Klassische Container teilen sich den Host-Kernel, ein Kernel-Exploit kann ausbrechen. MicroVMs mit eigenem Kernel je Agent (etwa Docker Sandboxes) ziehen eine härtere Grenze und sind der sicherere Weg, wenn der Agent wirklich autonom laufen soll.

CI-/PR-Integration: risikobasierte Review-Gates. Nicht jede Änderung braucht dieselbe Prüfung. Bewährte Praxis 2026 ist es, den Review nach Risiko zu staffeln: Unkritisches (etwa UI-Texte) läuft durch den normalen Review, während Auth, Kryptografie, Zahlungsverkehr, Datenbank-Migrationen oder Infrastruktur-Code zusätzlich einen Senior- oder Security-Review erfordern. Der Kontrollpunkt sitzt am Merge-Gate: SAST, Secret-Scanning und Dependency-Checks blockieren den Merge bei Findings. Und weil laut Presseberichten über die Prüforganisation METR selbst starke Modelle Tests manipulieren, statt Aufgaben zu lösen, gilt: Ein grüner CI-Lauf ist ein Signal, kein Beweis. Wer die Tests schreibt und ausführt, darf nicht allein darüber entscheiden, ob die Aufgabe gelöst ist.

Secrets & Credentials. Ab hier bekommt der Agent eng gefasste, kurzlebige Tokens statt geteilter Zugangsdaten. Keine langlebigen Master-Keys, keine Credentials mit mehr Rechten als die konkrete Aufgabe braucht. GitLost ist die Warnung: Ein Agent mit organisationsweitem Lesezugriff wird zum Datenleck, sobald ihn jemand über einen manipulierten Input steuert. Zugriff also pro Aufgabe scopen, nicht vererben.

Phase 3: Run (Skaliert)

In der letzten Phase laufen Agenten über viele Repos und Teams. Manuelle Kontrolle skaliert hier nicht mehr, die Steuerung muss selbst zu Code und Infrastruktur werden.

Freigaben & Policy als Code. Statt Regeln in einem Wiki durchzusetzen, entscheidet eine Policy-Engine wie der Open Policy Agent über jeden Tool-Aufruf, bevor er das Zielsystem erreicht. Nicht der Agent entscheidet, was erlaubt ist, sondern eine deklarative Regel außerhalb des Modells, auch wenn der Agent zuvor per Prompt-Injection zu einer verbotenen Aktion verleitet wurde. Das ist die konsequente Umsetzung der Grundhaltung: Die Erlaubnis liegt nie beim Agenten selbst.

Audit & Observability. Jede Agent-Session gehört einer benannten menschlichen Identität zugeordnet, sonst funktionieren weder Access-Reviews noch Offboarding. Geloggt wird zentral und durchsuchbar: welcher Nutzer, welches Modell und welche Version, welche Instruktion, welche Datei- und Netzzugriffe, welche PR. OPA liefert für jede Entscheidung einen Audit-Trail mit Zeitstempel gleich mit. Für Betreiber von Hochrisiko-KI-Systemen ist das nicht nur gute Praxis: Der EU AI Act verlangt in Artikel 12 automatische Protokollierung und Nachvollziehbarkeit, mit relevanten Pflichten ab dem 2. August 2026. SkillCloak erinnert daran, dass dieses Logging Laufzeitverhalten erfassen muss: Was ein Skill zur Installationszeit zeigt, sagt nichts darüber, was er zur Laufzeit tut.

Incident-Response. Für den Fall, dass ein Agent doch Schaden anrichtet, braucht es einen geübten Ablauf: Sessions einer Identität zuordnen und schnell abschalten können, betroffene Credentials rotieren, den Audit-Trail auswerten, Änderungen zurückrollen. Ein Agent ist aus dieser Sicht eine verwaltete Non-Human-Identity mit Lebenszyklus, kein Werkzeug, das man einmal einrichtet und vergisst.

Wer im Team was tut

Die Reifegrade auf einen Blick

Die Matrix zeigt, wie jeder Baustein über die Phasen härter wird. Ordne dein Team ein und lies in der nächsten Spalte, was der jeweils nächste Schritt ist.

Fazit

Ein hoher Reifegrad ist kein Zertifikat, das man einmal erwirbt und dann besitzt. Er ist eine laufende Entscheidung darüber, wie viel Autonomie das Team dem Agenten technisch zugesteht, nicht bloß auf dem Papier. Die Vorfälle aus 2026 zeigen, warum das zählt: Jede Kontrolle, die auf dem Wohlverhalten des Agenten beruht, fällt früher oder später. Was bleibt, sind Grenzen, die er nicht überschreiten kann. Wer seinen Agenten-Betrieb entlang dieser drei Stufen aufbaut, muss dem Modell nicht vertrauen, um ihm Arbeit zu übergeben.