Governance statt Allowlist Warum das Model Context Protocol im Unternehmen kein Auslaufmodell ist

Anbieter zum Thema

GitLab GmbH

Kestra S.A.S.

QUNIS GmbH

Fivetran Germany GmbH

Kaum ein Standard wird so schnell für tot erklärt wie das Model Context Protocol. In Entwicklerkreisen gilt MCP als überkomplex und überflüssig. Für das Einzelprojekt stimmt das. Sobald KI-Agenten aber über Team-, System- und Organisationsgrenzen hinweg arbeiten, kippt die Rechnung. Aus einer Komfortfrage wird eine Governance-Frage.

Alle paar Monate wird eine Technologie verfrüht zu Grabe getragen. Das Model Context Protocol (MCP) hat diese Phase gerade erreicht: Zu viel Overhead, zu komplex, lautet das Urteil in Teilen der Entwicklergemeinde. Für eng umrissene Anwendungsfälle trifft die Kritik zu. Sie trägt jedoch nicht mehr, sobald man das Einzelprojekt verlässt und zu den agentischen Systemen kommt, die Unternehmen derzeit aufbauen.

Wo die Skeptiker recht haben

Ist nur ein Nutzer beteiligt und Vertrauen implizit vorhanden, erzeugt ein MCP-Server tatsächlich unnötige Komplexität. Für die Anbindung eines lokalen KI-Assistenten, den Aufbau einer persönlichen Automatisierung oder ein isoliertes Skript auf der eigenen virtuellen Maschine ist der direkte API-Aufruf meist die einfachere und bessere Wahl. In diesem Kontext liegen die Skeptiker richtig.

Der Bruch in der Argumentation

Agentische Systeme im Unternehmen beruhen weder auf einem einzelnen Entwickler noch auf einer einzigen Vertrauensgrenze. Agenten arbeiten über Teams, Systeme und Organisationen hinweg, häufig im Auftrag von Nutzern, die von der Beteiligung eines Agenten gar nichts wissen. In solchen Umgebungen erzeugen direkte API-Aufrufe Probleme, die keine Allowlist zuverlässig löst.

Die Delegation von Zugangsdaten ist der erste Reibungspunkt. Wer eine Plattform betreibt, die Agenten im Auftrag von Unternehmenskunden ausführt, steht schnell vor Fragen nach der Identität des Agenten, der Vererbung von Berechtigungen und dem Betrieb unter einem Service-Account. Eine universell richtige Antwort gibt es nicht, doch falsche Entscheidungen haben Folgen.

Ein Agent mit zu weitreichendem Zugriff wird zum Audit- und Compliance-Risiko. Ein zu enger Zugriff führt dazu, dass der Agent unbemerkt scheitert und das Vertrauen in die Plattform über die Zeit untergräbt. Unternehmenskunden in regulierten Branchen bringen dieses Thema bereits vor dem formalen Security-Review zur Sprache.

Der Vermerk „das war die KI“ genügt in regulierten Umgebungen nicht als Audit-Eintrag. Teams müssen drei Fragen beantworten können: Was hat der Agent getan, in wessen Auftrag und mit welcher Berechtigung? Diese Informationen müssen im Systementwurf angelegt sein, denn nach einem Vorfall lassen sie sich aus Logs nicht sinnvoll rekonstruieren. Eine direkte API-Integration leistet das nicht. Eine sauber umgesetzte MCP-Architektur macht den erforderlichen Kontext dagegen auf Ebene des einzelnen Tool-Aufrufs sichtbar und erfasst, welcher Server, welche Zugangsdaten und welcher Berechtigungsumfang jede Aktion autorisiert haben.

Eine Allowlist ist noch keine Governance

Soll ein Agent nicht auf Ressourcen zugreifen, die für ihn nicht vorgesehen sind, liegt der Reflex nahe, zur Allowlist zu greifen: erlaubte Tools definieren, vor der Ausführung abgleichen, Aufgabe erledigen. Der Ansatz wirkt wie Governance, weil er einer Richtlinie ähnelt. Eine Richtlinie ist jedoch nur so belastbar wie das System, das sie durchsetzt. In der Praxis scheitern Allowlists an Fehlkonfigurationen, unerwartetem Agentenverhalten und Spezialfällen, an die bei der Erstellung niemand gedacht hat.

Belastbarer ist ein strukturelles Least-Privilege-Prinzip. Gibt die MCP-Verbindung eines Agenten ausschließlich die Tools frei, die er für seine konkrete Aufgabe benötigt, kann der Agent diesen Rahmen nicht überschreiten. Für Sicherheitsteams in regulierten Umgebungen sind „der Agent kann seinen Berechtigungsumfang strukturell nicht überschreiten“ und „der Agent hält sich an die Regeln“ zwei sehr unterschiedliche Zusicherungen.

Governance auf der Plattformebene

Wie sich diese Prinzipien umsetzen lassen, zeigt das niederländische Softwareunternehmen und GitLab-Partner Cube aus Oldenzaal. Das Unternehmen stellt GitLab-Kontext über einen MCP-Server bereit, sodass externe KI-Tools wie Claude von Anthropic auf dieselben Projektdaten zugreifen können, wenn eine Aufgabe außerhalb der Plattform beginnt, etwa bei der Projektaufnahme oder der projektübergreifenden Analyse.

Entscheidend für die Governance-Frage ist die Architektur: Unabhängig davon, ob ein Agent nativ auf der Duo Agent Platform läuft oder ein externes Tool über MCP angebunden ist, werden Berechtigungen an derselben Stelle vergeben, Aktionen protokolliert und Kontext kontrolliert. Jeder Schritt erscheint im Audit-Trail neben dem übrigen Verlauf der Softwarebereitstellung. Das verdeutlicht den größeren Zusammenhang: Mit wachsenden agentischen Systemen wird die Steuerung des Kontexts hinter dem Zugriff genauso wichtig wie die Steuerung des Zugriffs selbst.

Zwei offene Baustellen

An zwei Stellen erzeugt MCP weiterhin Reibung.

Die Provisionierung von Servern, die nur die jeweils benötigten Funktionen freigeben, erfolgt noch zu manuell. Verlangt eine korrekte Konfiguration tiefes Infrastrukturwissen, überspringen Administratoren den Schritt häufig und greifen zu breit angelegten Verbindungen, abgesichert allein durch eine Allowlist. Solange die Branche die Provisionierung nicht auch für Nicht-Spezialisten zugänglich macht, wird die Verbreitung stocken.

Auch die operative Ebene für die Verwaltung von MCP-Verbindungen muss Sicherheits- und Plattformteams offenstehen, nicht allein den Entwicklern, die die Integration ursprünglich gebaut haben. Administratoren sollten jede aktive Verbindung in ihrer Umgebung einsehen, deren Freigaben nachvollziehen und die Nutzer identifizieren können, ohne dafür eine Konfigurationsdatei zu lesen oder den damaligen Entwickler ausfindig zu machen. Für Organisationen, die Agenten im großen Maßstab betreiben, sind das Grundvoraussetzungen.

Was Governance im Enterprise-Maßstab erfordert

Ein schwaches Governance-Modell zeigt sich im Vorfall, denn autonome Agenten im Unternehmensmaßstab finden die Lücken früher als die Verantwortlichen selbst. Wo die ehrliche Antwort noch „wir haben eine Allowlist“ lautet, ist der nächste Schritt klar: prüfen, worauf die eigenen Agenten zugreifen können, diesen Zugriff mit dem tatsächlichen Bedarf abgleichen und die strukturellen Kontrollen aufbauen, bevor aus Lücken Vorfälle werden.

Über die Autorin

Amanda Rueda ist Staff Product Managerin bei GitLab. Sie beschäftigt sich damit, wie Agents Aufgaben ausführen, und mit den Laufzeitfunktionen, die einen zuverlässigen Einsatz von Agents in unterschiedlichen Umgebungen ermöglichen.

(ID:50949203)