KI-Coding-Agenten brauchen Sicherheits-Gates vor der Produktion

KI-Coding-Agenten bewegen sich vom hilfreichen Nebenwerkzeug in Richtung echter Delivery-Prozesse.

Genau das war diese Woche auf X deutlich zu sehen. Entwickler verglichen Claude Code, Cursor, Codex und Multi-Agent-Setups mit separaten Git-Worktrees. Andere teilten Prompts, die Agenten vor dem Shipping zu OSV-Checks, gitleaks, SBOM-Erzeugung und Security-Scans zwingen. Unter all dem lag dieselbe Beobachtung: Diese Werkzeuge werden nützlich genug, um echten Code zu berühren. Damit verändert sich das Risikomodell.

Für Gründer und CTOs lautet die Lektion nicht, dass KI-Coding-Agenten unsicher sind.

Die Lektion lautet: Ein Coding-Agent ist inzwischen ein technischer Akteur mit Zugriff.

Wenn er ein Repository lesen, Shell-Kommandos ausführen, Pakete installieren, Logs prüfen, Konfiguration verändern oder Pull Requests öffnen kann, braucht er dieselbe Art von Delivery-Kontrolle wie jede andere mächtige Automatisierung.

Geschwindigkeit ist wertvoll. Ungesteuerte Geschwindigkeit ist ein Produktionsrisiko.

Agenten-Geschwindigkeit verändert das Risikomodell

Klassische KI-Unterstützung beim Programmieren war meist durch einen menschlichen Copy-and-paste-Schritt begrenzt. Ein Entwickler fragte nach einer Funktion, prüfte die Antwort, passte sie an und commitete selbst.

Agentisches Coding ist anders.

Ein Agent kann eine Aufgabe planen, mehrere Dateien verändern, Tests ausführen, Dependencies installieren, Tools aufrufen, Lint-Fehler beheben und weitermachen, bis er die Arbeit für erledigt hält. In fortgeschrittenen Setups arbeiten mehrere Agenten parallel in Branches oder Git-Worktrees, während ein weiterer Prozess CI-Fehler analysiert.

Das ist ein echter Produktivitätssprung.

Es bedeutet aber auch, dass Fehler weiter wandern können, bevor ein Mensch sie bemerkt.

Die Risiken sind nicht theoretisch:

• ein Secret wird gelesen, geloggt oder in einen unsicheren Kontext kopiert;
• eine Dependency mit bekannten Schwachstellen wird hinzugefügt, weil sie das unmittelbare Problem löst;
• ein Shell-Kommando läuft mit mehr Dateisystem- oder Netzwerkzugriff, als die Aufgabe braucht;
• generierter Code umgeht eine Architekturgrenze, weil der Agent lokal optimiert;
• Tests laufen durch, aber die Änderung schwächt Autorisierung, Mandantentrennung oder Datenverarbeitung;
• mehrere Agent-Branches erzeugen Review-Müdigkeit und Architekturdrift;
• später kann niemand erklären, welcher Prompt, Tool-Aufruf oder Befehl eine riskante Änderung erzeugt hat.

Das sind normale Software-Delivery-Risiken, verstärkt durch Autonomie.

Die Antwort ist nicht, diese Werkzeuge zu verbieten. Die Antwort ist, Produktions-Gates um sie herum zu bauen.

Ein praktikables Gate-Modell

Security-Gates funktionieren am besten, wenn sie konkret, soweit möglich automatisiert und an die Kritikalität der Änderung gebunden sind.

Für KI-Coding-Agenten ist ein mehrschichtiges Modell sinnvoll.

1. Runtime-Isolation

Das erste Gate ist die Frage, wo der Agent überhaupt arbeiten darf.

Ein Agent sollte in einem isolierten Arbeitsbereich laufen, mit klaren Dateisystemgrenzen, möglichst begrenztem Netzwerkzugriff und ohne Standardzugang zu Produktions-Credentials. Worktrees, Container, ephemere Umgebungen und sandboxed Shells sind keine Bürokratie. Sie reduzieren den Schaden, wenn ein Kommando falsch läuft oder ein Tool-Aufruf zu eifrig ist.

Für seriöse Teams lautet die Frage nicht: “Darf der Agent Kommandos ausführen?”

Die Frage lautet: “Welche Kommandos darf er in welcher Umgebung, mit welchen Daten und mit welcher Nachvollziehbarkeit ausführen?“

2. Least-Privilege-Credentials

Agenten sollten nicht automatisch die komplette lokale Umgebung eines Entwicklers erben.

Dazu gehören Cloud-Tokens, Datenbank-URLs, SaaS-API-Keys, Git-Credentials, produktive .env-Dateien und Zugriff auf Kundendaten. Wenn ein Agent Credentials braucht, sollten sie auf die Aufgabe begrenzt, nach Möglichkeit zeitlich beschränkt und leicht widerrufbar sein.

Dasselbe gilt für Tool-Integrationen. MCP-Server, Log-Systeme, Ticketing, Observability-Dashboards und interne APIs können hilfreichen Kontext liefern. Sie können aber auch sensible Betriebsdaten offenlegen. Verbunden wird nur, was die Aufgabe wirklich braucht.

3. Secret-Scanning vor dem Review

Jede agentenerzeugte Änderung sollte ein Secret-Scanning bestehen, bevor ein menschlicher Reviewer Zeit investiert.

Tools wie gitleaks, trufflehog oder plattformnative Secret-Scans können offensichtliche Fehler früh abfangen. Entscheidend ist nicht das konkrete Tool. Entscheidend ist, dass Secret-Erkennung automatisch, wiederholbar und blockierend ist.

Wenn ein Team darauf hofft, dass ein Reviewer einen geleakten Key in einem großen KI-generierten Diff bemerkt, ist der Prozess bereits zu schwach.

4. Dependency- und Vulnerability-Checks

Agenten sind sehr gut darin, ein Paket zu finden, das ein akutes Problem löst.

Sie sind nicht automatisch gut darin zu beurteilen, ob dieses Paket in ein Produktionssystem gehört.

Bevor agentenerzeugter Code ausgeliefert wird, sollten Dependency-Änderungen Vulnerability- und Lizenzprüfungen auslösen. OSV, npm audit, pnpm audit, GitHub Dependency Review, Snyk oder ähnliche Werkzeuge können Teil des Gates sein. Zusätzlich sollte das Team fragen, ob die Dependency notwendig, gepflegt und architektonisch passend ist.

Das schnellste Paket ist nicht immer das günstigste Paket.

5. SBOM und Supply-Chain-Sichtbarkeit

Wenn KI-Agenten Dependency-Änderungen beschleunigen, braucht das Unternehmen eine bessere Inventur.

Eine Software Bill of Materials ist nicht nur ein Compliance-Artefakt für Konzerne. Sie zeigt, was im Produkt steckt, wenn eine Schwachstelle auftaucht, ein Kunde Sicherheit fordert oder eine Due-Diligence-Prüfung Nachweise verlangt.

Für agentische Delivery sollte SBOM-Erzeugung nah an Build- und Release-Prozessen liegen, nicht als einmalige Jahresübung.

6. Tests und CI als harte Gates

Agenten-Output darf nicht an der normalen Engineering-Messlatte vorbeigehen.

Unit-Tests, Integrationstests, Type-Checks, Linting, Build-Checks, Migrationsprüfungen und End-to-End-Tests bleiben wichtig. Eigentlich werden sie wichtiger, weil Agenten schnell plausiblen Code erzeugen können.

Die Testsuite wird zum Vertrag, der dem Agenten die Grenzen zeigt.

Wenn ein Produkt schwache Tests hat, sollte die Einführung von Coding-Agenten mit einem stärkeren Delivery-Harness beginnen. Sonst vervielfacht das Team Code-Output, aber nicht Vertrauen.

7. Menschliches Architektur-Review

Automatisierung kann Secrets, Dependencies, Syntaxfehler und viele Regressionen abfangen.

Sie kann aber nicht vollständig entscheiden, ob eine Änderung ins System gehört.

Das bleibt eine Architekturfrage.

Bevor agentenerzeugte Arbeit produktionsnah wird, sollte ein erfahrener Mensch Änderungen prüfen, die Grenzen betreffen: Authentifizierung, Autorisierung, Datenmodelle, Mandantentrennung, Billing, Infrastruktur, Migrationen, Background-Jobs, öffentliche APIs und operative Wiederherstellung.

Das Review sollte fragen:

• Respektiert diese Änderung die bestehende Architektur?
• Hat der Agent die lokale Aufgabe gelöst, aber ein größeres Systemproblem geschaffen?
• Liegen neue Verantwortlichkeiten im richtigen Modul oder Service?
• Ist die Änderung beobachtbar und rückrollbar?
• Wären wir in sechs Monaten noch gern für diesen Code verantwortlich?

Dieses Review ist nicht anti-KI. Es macht KI in ernsthafter Produktentwicklung erst nützlich.

8. Audit Trail

Wenn ein Agent produktionsnahen Code verändert, sollte das Team rekonstruieren können, was passiert ist.

Mindestens sollten Aufgabe oder Ticket, Prompt- oder Instruktionszusammenfassung, Agent-Branch, Tool-Berechtigungen, ausgeführte Kommandos, CI-Ergebnisse, Reviewer und finale Freigabe mit Pull Request oder Release-Artefakt verbunden sein.

Das hilft beim Debugging. Es hilft bei Security-Incidents. Es hilft bei Compliance. Und es hilft, den Workflow über Zeit zu verbessern.

Wenn der Prozess nicht erklären kann, wie eine Änderung entstanden ist, ist er nicht skalierbar.

Was Gründer und CTOs fragen sollten

Man muss kein Spezialist für AI-Tooling werden, um dieses Thema gut zu führen.

Man muss aber bessere Fragen stellen.

Fragen Sie interne Teams oder Dienstleister:

• Wo laufen KI-Coding-Agenten?
• Auf welche Dateien, Tools, Netzwerke und Credentials haben sie Zugriff?
• Können sie Produktionsdaten oder Secrets sehen?
• Welche Scans sind vor dem Review verpflichtend?
• Was passiert, wenn ein Agent eine Dependency ergänzt oder aktualisiert?
• Werden SBOMs als Teil des Releases erzeugt?
• Welche Änderungen brauchen ein Senior-Architektur-Review?
• Können wir agentenerzeugte Arbeit von Aufgabe über Commit bis Deployment nachvollziehen?
• Wie verhindern wir, dass ein Agent denselben Architekturfehler wiederholt?

Die Antworten müssen nicht kompliziert sein. Sie müssen aber echt sein.

Wie wir bei McDougall Digital darauf schauen

KI kann Produktentwicklung schneller machen. Richtig eingesetzt kann sie Teams sogar disziplinierter machen, weil sie klarere Aufgaben, stärkere Tests, bessere Dokumentation und explizitere Grenzen erzwingt.

Aber KI ersetzt kein Engineering-Urteil.

Für Kundenprojekte ist der sinnvolle Maßstab nicht: “Hat der Agent die Aufgabe abgeschlossen?”

Der sinnvolle Maßstab ist:

Kann diese Änderung verstanden, geprüft, getestet, betrieben und sicher übernommen werden?

Das ist der Unterschied zwischen KI-unterstütztem Output und Produktionssoftware.

Coding-Agenten gehören in moderne Delivery-Workflows. Sie müssen nur dieselben Gates passieren wie alles andere, das Produktion berührt.