Dein Blog zum Thema digitales Business

Wenn ein Mensch einen Commit vorbereitet, steckt in diesem Vorgang eine eingebaute Reibung. Er tippt den Befehl selbst, sieht den Diff im Terminal, hat oft einen kurzen Moment des Zögerns, bevor er den Push tatsächlich auslöst. Diese Reibung ist kein Zufall. Sie ist in vielen Teams der eigentliche Kontrollpunkt, auch wenn ihn niemand so nennt.

Ein KI-Agent, der autonom Code schreibt und committet, hat dieses Zögern nicht. Es gibt kein Terminal, an dem ein Mensch innehält, und keinen weitergereichten Auth-Kontext, der eine Rückfrage erzwingt. Der Agent erzeugt einen Commit, prüft ihn nach seiner eigenen Logik und pusht, sobald seine Kriterien erfüllt sind. Ob ein Schlüssel im Diff steht oder eine Datei versehentlich mitgenommen wurde, hängt dann allein davon ab, was zwischen Commit und Push technisch geprüft wird. Nicht davon, ob jemand kurz gezögert hätte.

Ein Mensch zögert, ein Agent nicht

Genau an diesem Punkt setzen lokale Git-Hooks an. Ein pre-commit-Hook läuft, bevor git den Commit überhaupt erzeugt. Ein pre-push-Hook läuft, bevor die Commits das lokale Repository verlassen. Beide laufen in derselben Umgebung wie der Agent, auf demselben Dateisystem, mit demselben Zugriff auf den noch nicht übertragenen Diff. Der Agent kann den Hook nicht stillschweigend umgehen, denn der Hook ist Teil der Repository- oder Umgebungskonfiguration, kein optionaler Schritt, den man einfach auslässt.

Ein konkretes Beispiel: ein Secret im Commit

Ein pre-commit-Hook, der einen Secret-Scanner wie gitleaks oder detect-secrets aufruft, prüft den staged Diff auf bekannte Muster. AWS-Zugriffsschlüssel beginnen mit einem festen Präfix, Slack-Tokens und private Schlüssel haben ein erkennbares Format, und generische Regeln schlagen zusätzlich bei langen, hochentropischen Zeichenketten in Variablen mit Namen wie API_KEY oder SECRET an. Findet der Scanner einen Treffer, bricht der Hook mit einem Exit-Code ungleich null ab, und git verweigert den Commit. Die Zeile mit dem Schlüssel existiert dann nur im Arbeitsverzeichnis, nie im Repository, nie in einer Historie, die irgendjemand klonen könnte.

Ein pre-push-Hook mit derselben Prüfung setzt einen Schritt später an. Er läuft über alle Commits, die ein Push tatsächlich überträgt, und kann auch dann noch stoppen, wenn ein Secret an einem einzelnen pre-commit-Lauf vorbeigerutscht ist, etwa weil der Agent mehrere Commits in einem Rutsch erzeugt hat, bevor der Hook zum ersten Mal griff. Zwischen Commit-Erzeugung und Push bleibt damit ein zweiter, unabhängiger Prüfpunkt, der ausschließlich lokal funktioniert.

Warum serverseitige Kontrollen zu spät kommen

GitHub Secret Scanning, GitLab Secret Detection oder ein Gate in der CI-Pipeline prüfen ähnliche Muster, teils mit größeren Regel-Sets und Anbindung an Partnerprogramme, die bekannte Token-Typen melden. Das ist wertvoll, setzt aber strukturell an einem anderen Punkt an: nach dem Push. Zu diesem Zeitpunkt steht der Commit bereits in der Historie des Remote-Repositories. Wer zwischenzeitlich einen Fetch oder Clone gemacht hat, hat den Schlüssel bereits auf der eigenen Platte, unabhängig davon, ob der Commit später zurückgezogen oder die Historie umgeschrieben wird. Ein CI-Gate kann einen Merge blockieren, aber die Pull-Request-Benachrichtigung an den Reviewer ist oft schon raus, bevor der Scan durchgelaufen ist.

Aus „verhindern, dass der Schlüssel je sichtbar wird“ wird damit „erkennen, dass er sichtbar war, und ihn jetzt rotieren“. Das ist ein anderer, spürbar teurerer Vorgang: der alte Schlüssel muss ungültig gemacht, ein neuer ausgerollt werden, und alle Stellen, die den alten Schlüssel referenzieren, müssen gefunden und aktualisiert werden. Bei einem Menschen am Terminal ist Rotation eine Möglichkeit unter mehreren, weil in den meisten Fällen ohnehin nichts passiert. Bei einem Agenten, der in Sekunden mehrere Commits und Pushes hintereinander ausführen kann, ist Rotation der einzige verbleibende Ausweg, wenn die lokale Kontrolle gefehlt hat.

Was das für den Einsatz von Agenten bedeutet

Wer einem Agenten Schreibrechte auf ein Repository gibt, verschiebt damit auch die Frage, wo Kontrolle tatsächlich sitzt. Serverseitige und CI-Kontrollen bleiben sinnvoll. Sie fangen ab, was lokal durchrutscht, und sie sind der einzige Ort, an dem sich teamweit einheitliche Regeln durchsetzen lassen, weil lokale Hooks je nach Entwickler- oder Agenten-Setup unterschiedlich konfiguriert sein können. Als alleinige Kontrolle für einen autonom committenden Agenten reichen sie aber nicht, weil der Schaden, den sie noch verhindern könnten, zu dem Zeitpunkt, an dem sie laufen, oft schon entstanden ist.

Die Konsequenz daraus ist keine neue Technologie, sondern eine Reihenfolge: lokale Hooks zuerst, weil sie vor dem Push laufen. Serverseitige Kontrollen zusätzlich, nicht ersatzweise.

Implementation heißt, Delivery und Nachweis modulweise in bestehende Pipelines zu ziehen, AI Governance wird relevant, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, und Maintenance ist zuerst eine Übergabefrage: wem gehört ein System nach dem Go-Live, und woran merkt man, dass es niemandem gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de.