Bildquelle: extern
Model Context Protocol im Unternehmensbetrieb: Welche 5 Governance-Regeln sitzen müssen, bevor Agenten produktiv Tools ausführen
Das Model Context Protocol, kurz MCP, wird 2026 in vielen IT-Organisationen zum praktischen Bindeglied zwischen KI-Assistenten und operativen Systemen. Der Reiz ist offensichtlich: Ein Agent kann nicht nur antworten, sondern über standardisierte Server auf Dateien, Wissensquellen, Tickets, Datenbanken oder Drittsysteme zugreifen. Genau dort beginnt aber auch die eigentliche Führungsaufgabe. MCP ist ein Protokoll für Kontextaustausch, kein fertiges Sicherheits- oder Betriebsmodell. Wer produktive Agenten anbinden will, muss deshalb vor allem Governance-Fragen sauber klären.
Die offizielle MCP-Dokumentation beschreibt eine klare Client-Server-Architektur mit Host, Client und Server. Server können Tools, Resources und Prompts bereitstellen. Besonders relevant ist dabei der Unterschied zwischen Tools und Resources. Tools sind aktiv ausführbare Funktionen, etwa für Dateizugriffe, API-Aufrufe oder Änderungen an Systemen. Resources liefern dagegen Kontextdaten lesend an die Anwendung. Genau diese Unterscheidung ist im Unternehmensbetrieb entscheidend, weil damit die Grenze zwischen Informationszugriff und Handlungsmacht sichtbar wird.
Zusätzlich wird das Thema mit Remote-MCP-Servern sicherheitsrelevant. Die Spezifikation sieht für HTTP-basierte Transporte OAuth 2.1, Resource Metadata, Authorization Server Metadata und den Resource-Parameter nach RFC 8707 vor. Die Security Best Practices warnen außerdem ausdrücklich vor Risiken wie Confused-Deputy-Szenarien, unsauberer Redirect-URI-Prüfung und unkontrolliertem Token-Passthrough. Für IT-Leitungen heißt das: Nicht die Demo entscheidet, sondern das Betriebsmodell dahinter.
Fünf Governance-Regeln sind besonders wichtig, bevor Agenten über MCP im Alltag echte Systeme berühren.
1. Nicht jeder MCP-Server darf ein Tool-Server sein
Viele Teams behandeln MCP zunächst wie einen praktischen Universalstecker. Alles, was nützlich sein könnte, wird als Server angebunden. Genau das ist im Unternehmenskontext der erste Fehler. Die MCP-Dokumentation trennt sauber zwischen Tools, Resources und Prompts. Für die Governance heißt das: Diese drei Klassen brauchen unterschiedliche Freigabelogiken.
Ein Resource-Server, der einem Agenten nur Dokumentation, Inventardaten oder ein Konfigurationsschema lesend bereitstellt, ist organisatorisch anders zu bewerten als ein Tool-Server, der Tickets ändert, Nachrichten verschickt, Daten löscht oder Deployments anstößt. In der Praxis sollten Unternehmen deshalb zuerst ein Server-Inventar aufbauen: Welche MCP-Server liefern nur Kontext, welche führen Aktionen aus, welche kombinieren beides, und welche Systeme hängen dahinter? Erst danach lässt sich sinnvoll entscheiden, welche Server in welchem Nutzungsszenario überhaupt sichtbar sein dürfen.
Eine robuste Regel lautet: Standardmäßig zuerst lesende Ressourcen zulassen, schreibende oder auslösende Tools nur nach eigener Risikoprüfung. Wer diese Trennung nicht macht, gibt Agenten zu früh operative Reichweite.
2. Für Remote-MCP-Server muss die Identitätskette prüfbar und servergebunden sein
Sobald MCP nicht mehr lokal über STDIO läuft, sondern per HTTP mit entfernten Servern arbeitet, wird Authentisierung zum Kernproblem. Die Spezifikation ist hier erstaunlich konkret. MCP-Server sollen Protected Resource Metadata nach RFC 9728 bereitstellen, Clients sollen daraus den zuständigen Authorization Server entdecken, und in Autorisierungs- wie Token-Requests muss ein eindeutiger Resource-Parameter nach RFC 8707 mitgeführt werden. Der Sinn dahinter ist operativ wichtig: Ein Token soll für genau den vorgesehenen MCP-Server ausgestellt werden, nicht unspezifisch für irgendeinen späteren Weitertransport.
Für Unternehmen folgt daraus eine klare Prüfregel. Jeder Remote-MCP-Server braucht eine nachvollziehbare Identitätskette: Welcher Authorization Server steht dahinter, welche Scopes werden angefordert, welche Resource-URI ist gültig, und wie wird verhindert, dass Tokens serverübergreifend wiederverwendet werden? Wenn diese Fragen im PoC offenbleiben, ist das kein Detail, sondern ein Architekturfehler.
Besonders kritisch ist das bei Servern, die als Proxy zu Dritt-APIs arbeiten. Dort reicht ein „wir haben OAuth“ ausdrücklich nicht. Relevant ist, ob die Token wirklich an den richtigen Zielserver gebunden, sauber validiert und nicht einfach an nachgelagerte Systeme durchgereicht werden.
3. Per-Client-Consent und Freigabeschwellen dürfen nicht dem Modell überlassen bleiben
Die MCP-Dokumentation zu Server-Konzepten weist darauf hin, dass Tools Nutzereinwilligung vor Ausführung erfordern können. Genau dieses Können muss im Unternehmen zum Müssen werden, sobald ein Tool Außenwirkung hat. Die Security Best Practices beschreiben das Problem am Beispiel des Confused-Deputy-Angriffs sehr plastisch: Wenn ein MCP-Proxy mit statischer Drittanbieter-Identität arbeitet, aber neue MCP-Clients dynamisch registriert und Freigaben nicht pro Client sauber speichert, kann die Einwilligungslogik ausgehebelt werden.
Im Alltag heißt das: Nicht nur der Mensch muss einmal allgemein einem Agenten vertrauen, sondern jede relevante Client-Beziehung braucht einen klaren Freigabekontext. Wer fordert Zugriff an? Auf welchen Server? Mit welcher Redirect-URI? Für welche konkreten Rechte? Genau diese Angaben müssen auf einer MCP-eigenen Freigabeseite oder in einem internen Approval-Prozess sichtbar werden. Ein generelles „dieser Assistent darf das schon“ reicht nicht.
Zusätzlich sollten IT-Teams Ausführungsschwellen definieren. Lesende Suchanfragen können oft vorfreigegeben werden. Schreibende Aktionen, Exporte, Massenänderungen, Nachrichten an Dritte oder privilegierte Administrationsschritte brauchen dagegen einen expliziten menschlichen Bestätigungspunkt. Sonst wird aus Tool-Komfort schnell ein Governance-Leck.
4. Redirect-URIs, Zustandsdaten und Sitzungen brauchen dieselbe Strenge wie bei klassischen Geschäftsanwendungen
Gerade weil MCP oft als neue KI-Schicht wahrgenommen wird, geraten klassische Web-Sicherheitsdisziplinen schnell aus dem Blick. Das wäre fahrlässig. Die Security Best Practices verlangen für Redirect-URIs exakte Übereinstimmung statt Mustervergleichen oder Wildcards. Ebenso müssen OAuth-State-Werte kryptographisch sicher erzeugt, serverseitig gespeichert, nur einmal verwendet und erst nach expliziter Zustimmung gesetzt werden. Auch Consent-Cookies sollen eng gebunden und sicher konfiguriert sein.
Für den Unternehmensbetrieb ist das mehr als Implementierungsfeinheit. Viele Agentenprojekte entstehen derzeit in kleinen Produktteams oder Fachbereichen. Dort werden schnelle Integrationen gebaut, aber Redirect-Prüfungen, Session-Bindung oder CSRF-Schutz oft erst spät nachgezogen. Genau in dieser Phase entstehen später schwer erklärbare Lücken.
Die Governance-Regel sollte deshalb lauten: Ein Remote-MCP-Server durchläuft vor Produktivgang denselben Sicherheits- und Architekturcheck wie eine interne OAuth- oder SSO-Integration. Kein Sonderstatus, nur weil der Aufrufer ein Agent ist. Wer bei Redirect-URIs oder State-Handling locker wird, baut den Missbrauchspfad gleich mit ein.
5. Logging, Tool-Katalog und Notfallabschaltung müssen Teil des Betriebsmodells sein
MCP bringt Dynamik mit. Tools können gelistet, aufgerufen und in manchen Fällen auch verändert oder ergänzt werden. Die Dokumentation betont außerdem, dass Anwendungen verfügbare Tools im UI sichtbar machen, Einzelausführungen bestätigen und Aktivitäten protokollieren können. Im Unternehmensbetrieb sind diese Möglichkeiten kein Nice-to-have, sondern Pflicht.
Jede Organisation, die produktive Agenten mit MCP betreibt, sollte mindestens drei Dinge verbindlich einführen. Erstens einen versionierten Tool-Katalog mit Owner, Zweck, Risikoklasse, Zielsystem und erlaubten Nutzungsszenarien. Zweitens ein Audit-Logging, das nachvollziehbar macht, welcher Client welches Tool wann mit welchen Parametern aufgerufen hat und welche Wirkung daraus entstand. Drittens einen Kill-Switch, mit dem einzelne Server, Tool-Gruppen oder Tokenpfade kurzfristig deaktiviert werden können, ohne den gesamten Assistenten abzuschalten.
Gerade der Kill-Switch wird oft vergessen. Im Incident-Fall hilft es wenig, wenn Logs zwar zeigen, dass ein Agent unerwartet agiert hat, aber niemand den betroffenen MCP-Server schnell aus dem Pfad nehmen kann. Wer Agenten produktiv in Service-, Wissens- oder Administrationsprozesse hängt, braucht deshalb dieselbe Betriebsreife wie bei anderen kritischen Integrationen: Ownership, Änderungsdisziplin, Monitoring und einen klaren Rückzugshebel.
Was IT- und Service-Teams jetzt konkret tun sollten
- MCP-Inventar aufbauen: Alle angebundenen oder geplanten Server nach Resources, Tools, Zielsystemen und Risikoklassen erfassen.
- Remote-Server hart prüfen: OAuth-Discovery, Resource-Parameter, Redirect-URI-Validierung und Token-Bindung als Pflichtcheck einführen.
- Freigaben staffeln: Lesende Zugriffe, schreibende Tools und privilegierte Aktionen organisatorisch klar trennen.
- Auditierbarkeit sichern: Tool-Aufrufe mit Client, Nutzerbezug, Parametern und Resultat nachvollziehbar protokollieren.
- Abschaltpfade vorbereiten: Für riskante Server und Tool-Klassen einen sofort nutzbaren Kill-Switch definieren und testen.
MCP kann im Unternehmensbetrieb sehr nützlich sein, gerade weil es Agenten strukturiert an reale Systeme andockt. Genau deshalb darf das Protokoll nicht mit Governance verwechselt werden. Die operative Frage lautet nicht, ob ein Agent einen Server technisch erreichen kann. Die wichtigere Frage ist, unter welchen Regeln, mit welcher Identitätskette und mit welcher Rückholbarkeit er das im Produktionsalltag tun darf. Wer diese fünf Punkte vorab klärt, macht aus MCP einen belastbaren Integrationsbaustein statt eines neuen Schattenrisikos.
