Governance für agentische KI, MCPs und KI-Code-Assistenten

Bei der KI-Code-Vervollständigung war das menschliche Review von Anfang an eingebaut. Jemand tippt, ein Vorschlag erscheint, ein Mensch nimmt ihn an oder verwirft ihn. Vor dem Ausliefern sah ein Mensch jede Zeile.

Agentische KI durchbricht diese Schleife. Ein Agent öffnet einen Merge Request, ruft ein Tool auf, ändert eine CI/CD-Konfiguration und pusht eine Änderung, manchmal ohne dass jemand jeden einzelnen Schritt prüft. Hinzu kommt das Model Context Protocol (MCP), über das Agenten sich selbstständig mit externen Tools und Datenquellen verbinden. Damit verschiebt sich die Frage, die Engineering-Verantwortliche stellen: nicht mehr "Welches Modell schreibt den besten Code?", sondern "Was darf dieser Agent tun, und wie lässt sich belegen, was er getan hat?"

Eine eigene Untersuchung von GitLab unter mehr als 1.500 Entwickelnden und Technologieverantwortlichen zeigt, wie verbreitet diese Sorge ist: 73 % der Befragten sehen die langfristige Wartbarkeit von Code kritisch, und 86 % stimmen zu, dass KI-generierter Code ohne klare Governance technische Schulden schneller anhäufen kann als die klassische Entwicklungspraxis.

Dieser Artikel zeigt, wie sich einige der Herausforderungen, die Organisationen bei der Governance agentischer KI zu sehen beginnen, vorausschauend angehen lassen. Er stellt ein Governance-Framework für agentische KI in der Softwareentwicklung vor und behandelt, was zu steuern ist, wo menschliches Review weiterhin hingehört, wie sich eine Einführung messen lässt und welche Checkliste Teams hilft, die auf die GitLab Duo Agent Platform standardisieren.

Warum agentische KI eine andere Governance braucht

Bei einem interaktiven Coding-Assistenten bleibt das Sicherheitsmodell überschaubar, weil an jedem Schritt ein Mensch beteiligt ist: Eine Frage wird gestellt, ein Vorschlag geprüft, angenommen oder verworfen.

Anders liegt der Fall bei agentischer KI in automatisierten Workflows. Kann ein Agent Tests ausführen, Konfigurationen ändern und mehrstufige Aktionen über den Software-Lebenszyklus hinweg vornehmen, ohne dass ein Mensch jeden Schritt prüft, verschieben sich die relevanten Fragen:

• Worauf kann dieser Agent zugreifen?
• Wozu ist er berechtigt?
• Welche Aktionen hat er ausgeführt, und lässt sich das im Nachhinein belegen?

Die meisten Teams spüren das bereits. 92 % der DevSecOps-Fachleute berichten von mindestens einer Governance-Herausforderung bei KI-generiertem Code, und die konkreten Sorgen zielen genau auf die Fragen oben.

Zu den größten Sorgen zählen:

• Code-Zuordnung: überhaupt unterscheiden zu können, welcher Code von einer KI und welcher von Menschen stammt.
• Rückverfolgbarkeit zur Absicht: KI-generierten Code mit der Geschäftsanforderung verbinden, die er erfüllen soll.
• Dokumentation, die mitwächst: Manuelle Dokumentation hält nicht stand, sobald Agenten einen wachsenden Teil der Codebasis erzeugen.

Ist ein Agent für ein Projekt freigegeben, kann er in der Regel schreiben, löschen und pushen, ohne dass die einzelne Aktion vorab geprüft wird. An der Verantwortung für das, was in der Codebasis landet, ändert das nichts, ganz gleich ob Mensch oder Agent die Änderung vorgenommen hat.

Governance für agentische KI ist kein Aufsatz auf die Governance der Code-Vervollständigung. Sie ist ein eigener Ansatz, aufgebaut auf Identität, Berechtigungen und Nachvollziehbarkeit.

Kontrollen für MCPs, Agenten, Modellzugriff und Tool-Berechtigungen setzen

Sobald Agenten Tools aufrufen und sich über Protokolle wie MCP mit externen Systemen verbinden, entscheidet die Rechtevergabe. Ein brauchbares Governance-Modell beantwortet drei Fragen, bevor ein Agent überhaupt läuft:

1. Welche Agenten und Flows sind erlaubt?
2. Wo dürfen sie tätig werden?
3. Welche Modelle dürfen sie nutzen?

In der Praxis greifen dafür mehrere Ebenen ineinander:

• Ein zentraler Katalog für Agenten und Flows: Statt dass jedes Team eigene Agenten-Integrationen aufsetzt, bestimmt ein gemeinsamer AI Catalog, was veröffentlicht wird, abgestimmt auf die bestehenden Rollen und die Gruppenstruktur der Organisation.
• Composite Identity: Die Identität jedes KI-Agenten bleibt mit dem Menschen verknüpft, der die Aktion angefragt hat, damit Aktivität nie allein dem Agenten zugerechnet wird. Beim Zugriff auf eine Ressource müssen beide authentifiziert und autorisiert sein, der Agent und der Mensch hinter ihm.
• Tool-Approval-Guardrails: Einzelne Agenten-Tools laufen autonom, pausieren für ein menschliches Review oder bleiben ganz blockiert. Eine sensible Aktion wie das Schreiben einer Datei oder das Löschen einer Ressource wartet damit auf eine Freigabe, bevor sie ausgeführt wird.
• Prompt-Guardrails: Agenten verarbeiten auch nicht vertrauenswürdige Eingaben, etwa eine Webseite, einen Issue-Kommentar oder eine von Angreifenden kontrollierte Datei. Deshalb muss die Plattform Versuche erkennen, das Agentenverhalten mitten im Workflow zu kapern, und nicht erst im Nachhinein protokollieren.

Ziel ist eine Kontrollebene, die Agenten-Berechtigungen genauso behandelt wie längst die menschlichen: rollenbasiert, nachvollziehbar und über alle Projekte hinweg konsistent.

Drei Fragen zum Datenumgang, die vorab geklärt sein sollten

Quellcode zählt zu den sensibelsten Werten eines Unternehmens, und jede KI-Funktion, die ihn liest, wirft eine Frage zum Datenumgang auf. Vor einer breiten Einführung agentischer KI wollen Technik- und Sicherheitsverantwortliche deshalb meist drei Punkte geklärt haben:

• Trainiert der Anbieter Modelle mit unserem Code?
• Wem gehören Eingaben und Ausgaben?
• Wo sitzen die Subprozessoren, und gibt es eine Benachrichtigung, wenn sich diese Liste ändert?

In regulierten Branchen lautet die Antwort auf die dritte Frage oft: nirgends außerhalb der eigenen Infrastruktur. Damit wird Self-Hosting zum Governance-Hebel und nicht bloß zur Deployment-Vorliebe. Self-Hosting-Optionen erlauben es, KI-Agenten vollständig auf selbst kontrollierter Infrastruktur zu betreiben, die Nutzung im Team weiterhin genau zu erfassen und regulatorische Anforderungen zu erfüllen.

Bring-your-own-Model geht einen Schritt weiter. Intern bereits validierte Modelle lassen sich anbinden und einzelnen Agenten-Flows zuordnen. Ein sensibler Workflow bleibt so an ein Modell gebunden, dem die Organisation vertraut, während weniger sensible Abläufe eine verwaltete Option nutzen.

Wo Autonomie endet und Review beginnt

Governance heißt nicht, Agenten das autonome Handeln zu verwehren. Sie heißt, bewusst festzulegen, wo Autonomie endet und Review beginnt. Eine praktikable Richtlinie unterscheidet dazu zwei Modi:

• Interaktive Arbeit, bei der ein Mensch anwesend ist, jeden Vorschlag sieht und direkt entscheidet. Diesen Modus kennen die meisten Teams bereits aus der KI-Code-Vervollständigung.
• Automatisierte Arbeit im Hintergrund, etwa Agenten in CI/CD-Pipelines, die niemand in Echtzeit beobachtet. Hier findet das Review entweder vor der Aktion statt, über Tool-Approval-Guardrails, oder unmittelbar danach, über einen Audit-Trail, den ein Mensch prüfen kann.

Entscheidungspunkte, die es zu definieren gilt

Code-Review, Tests und Validierung sowie Deployment-Freigabe lassen sich über zwei Fragen bestimmen:

• Was davon kann ein Agent eigenständig erledigen?
• Was verlangt eine namentliche menschliche Freigabe, bevor die Änderung weitergeht?

Jeder Checkpoint braucht in der Praxis seinen eigenen Durchsetzungsmechanismus. Das kann so aussehen:

• Merge-Request-Approval-Policies legen fest, wer freigeben muss, bevor ein Merge Request landet, unabhängig davon, ob ein Agent oder ein Mensch ihn geöffnet hat.
• Tool-Approval-Guardrails entscheiden Tool für Tool, ob die Aktion eines Agenten autonom läuft, für ein Review pausiert oder blockiert bleibt.
• Scanner-Durchsetzung hält eine Änderung auf Pipeline-Ebene zurück, bis sie die geforderten Sicherheits- und Qualitätsprüfungen besteht.

Wir empfehlen eine organisationsweite KI-Governance-Richtlinie, statt die Regeln den Normen einzelner Teams zu überlassen. Das schafft konsistente Nutzung und erleichtert Auditoren die Prüfung des KI-Einsatzes.

Zusätzlicher Kontext aus der Entscheidungsebene

Diese Freigaben als strukturierte Datensätze festzuhalten, zahlt sich langfristig aus, denn in einem Chat-Thread oder im Gedächtnis einer prüfenden Person gehen sie verloren. Eine im letzten Quartal gewährte Ausnahme, die Richtlinienversion, unter der sie erteilt wurde, und wer sie freigegeben hat: Genau diese organisatorische Einschätzung müssen Auditoren wie künftige Agenten nachschlagen können.

Wer Entscheidungen als dauerhafte, abfragbare Ereignisse behandelt, gewinnt zusätzlich, dass die nächste Prüfung mit Kontext beginnt statt bei null, ob sie von einem Menschen oder einem Agenten kommt.

Mehr über die Entscheidungsebene und darüber, wie festgehaltene Entscheidungsereignisse die Softwareentwicklung prägen.

Fünf Metriken, die eine KI-Einführung messen

Fünf Kategorien lohnen sich von Anfang an, und zwar zusammen betrachtet statt isoliert: Ein Anstieg der Adoption ohne begleitenden Blick auf die Risiko-Metriken ist selbst schon ein Warnsignal.

1. Adoption: aktive Nutzende von KI-Funktionen Woche für Woche, Zahl der ausgeführten Flows oder Agenten und welche Teams agentische Funktionen aktiviert haben und welche nicht.
2. Akzeptanz und Qualität: nachgelagerte Signale wie die Revert-Rate bei KI-unterstützten Änderungen und wie oft KI-erstellte Merge Requests das Review ohne Nacharbeit bestehen. Eine einzelne Akzeptanzrate ist für sich ein schwacher Näherungswert, weil sie nichts darüber sagt, was mit dem Code nach der Annahme geschieht.
3. Risiko: wie oft Tool-Approval-Guardrails eine Aktion für ein Review pausieren, wie oft daraus eine blockierte oder geänderte Aktion wird und ob eine Agenten-Aktivität einen Policy-Verstoß auslöst.
4. Remediation: die Scanner-Abdeckung über Projekte hinweg, der Anteil automatisch behobener Schwachstellen gegenüber manuell triagierten und die Dauer bis zur Behebung markierter Findings.
5. ROI: Sobald die Daten eines vollen Quartals vorliegen, lohnt der Blick auf den ROI der KI-Investition. Dazu erfassen, wie viel Aufwand Entwickelnde bei Aufgaben sparen, die Agenten nun übernehmen, und das gegen die Kosten pro behobenem Issue oder gemergter Änderung abwägen, in Credits oder Compute. Ein ausführlicher Blick auf den KI-ROI zeigt, wie sich Rohdaten zur Nutzung in belastbare Geschäftserkenntnisse und ROI-Berechnungen überführen lassen.

Werden alle fünf Metriken gemeinsam verfolgt, fallen Probleme der Einführung früh auf. Eine Einführung kann bei Adoption und Akzeptanz erfolgreich aussehen und dabei Risiko anhäufen, das erst ein Audit ein halbes Jahr später zutage fördert. Erst zusammen ergeben die Metriken ein belastbares Bild vom Wert der KI für die Organisation.

Governance-Checkliste für die GitLab Duo Agent Platform

Für Teams, die auf die GitLab Duo Agent Platform standardisieren, dient diese Checkliste als Ausgangspunkt, bevor agentische KI über einen Pilotbetrieb hinaus ausgeweitet wird:

• Das AI Transparency Center durchgehen und das eigene Verständnis von Datennutzung, Modellanbietern und Subprozessor-Zusagen bestätigen.
• Auf Plattformebene entscheiden, welche Agenten und Flows freigegeben sind, und sie über GitLabs AI Catalog veröffentlichen, statt Teams eigene konfigurieren zu lassen.
• Tool-Approval-Guardrails je nach Sensibilität des Tools auf "immer erlauben", "immer nachfragen" oder "immer verweigern" setzen.
• Composite Identity einrichten, damit jede Agenten-Aktion mit dem Menschen verknüpft ist, der sie angefragt hat, und der Zugriff die Autorisierung beider verlangt.
• Für regulierte Workloads Self-Hosting-Deployment und Bring-your-own-Model-Optionen gegen die eigenen Anforderungen an den Datenstandort abwägen.
• Explizite Human-in-the-Loop-Checkpoints für Code-Review, Tests und Validierung sowie Deployment-Freigabe dokumentieren.
• Audit-Event-Streaming für Agenten-Aktivität aktivieren, sodass jede Aktion in demselben Audit-Trail landet, den die Organisation bereits prüft.
• Die Metriken der Einführung (Adoption, Akzeptanz, Risiko, Remediation, ROI) festlegen, bevor der Pilotbetrieb ausgeweitet wird, und sie gemeinsam in wiederkehrendem Rhythmus prüfen.

Die Checkliste in jedem Release-Zyklus erneut durchgehen: Governance für agentische KI ist keine einmalige Einrichtung. Neue Agenten, neue Tools und neue Modelle werfen die Fragen oft neu auf.

Wo agentische KI auf Enterprise-Kontrolle trifft

Agentische KI verändert, was zu steuern ist. Die Code-Vervollständigung fragte einen Menschen, ob ein Vorschlag gut ist. Agentische KI fragt, was ein Agent anfassen darf, wer es freigegeben hat und ob sich das später belegen lässt.

Diese Fragen vollständig zu beantworten verlangt Governance, die in der Plattform selbst steckt und nicht nachträglich darübergelegt wird. Die GitLab Duo Agent Platform stellt AI Catalog, Approval-Guardrails und Audit-Event-Streaming direkt dort bereit, wo die Arbeit stattfindet. Teams erhalten damit KI-Unterstützung und Enterprise-Kontrolle zugleich, weil die Guardrails Teil des Workflows sind und kein separater Prozess daneben.

Jetzt eine kostenlose Testversion der GitLab Duo Agent Platform starten. Im Free-Tier lässt sich in wenigen Schritten anmelden. Wer bereits GitLab Premium oder Ultimate nutzt, kann die Duo Agent Platform aktivieren und die im Abonnement enthaltenen GitLab Credits nutzen.