MCP Kein Konnektor – Ihre Governance-Oberfläche für das Agentenzeitalter

Das Framing-Problem: „Anschluss“ unterschätzt die Entscheidung, die Sie tatsächlich treffen

Als Anthropic im November 2024 das Model Context Protocol (MCP) als offenen Standard zur Anbindung von KI-Systemen an Datenquellen und Business-Tools einführte, verfuhr die Branche wie üblich bei neuen Integrationsspezifikationen: Sie ordnete MCP der Infrastruktur zu. Adapter, Transportprotokolle, eine elegante Möglichkeit, die Entwicklung individueller Schnittstellen für jedes Modell und jedes Tool zu vermeiden. Alles true und für CIOs, CTOs oder CISOs irrelevant.

Hier ist der entscheidende Punkt für Unternehmen: Sobald ein Mitarbeiter ein Tool aufrufen kann, das Ihre Kundendaten liest oder in Ihre Systeme schreibt, schaffen Sie einen neuen Kontrollpunkt – unabhängig davon, ob Sie ihn benannt haben oder nicht. MCP ist der Ort, an dem dieser Kontrollpunkt explizit definiert werden kann. Es geht nicht nur darum, wie der Mitarbeiter auf Ihre Tools zugreift; hier legen Sie fest, wer anruft, unter welcher Identität, welche Tools überhaupt sichtbar sind, wie jeder Anruf protokolliert wird und welche Kosten pro Anruf anfallen dürfen. Das sind Governance-Fragen, keine Fragen der Konnektivität.

Behandelt man MCP als Konnektivitätsfunktion, optimiert man das Falsche – Abdeckung, Anzahl der Integrationen, Zeit bis zum ersten Anruf. Behandelt man es als Governance-Oberfläche, optimiert man das, was tatsächlich darüber entscheidet, ob Agenten sicher in großem Umfang eingesetzt werden können: eine einheitliche, standardisierte, auditierbare Schnittstelle, auf der Richtlinien einmalig durchgesetzt und überall beachtet werden.

Warum „viele kundenspezifische Integrationen“ die Governance stillschweigend N-mal neu erschaffen

Die meisten Unternehmen starten nicht mit einem unbelasteten System in die Ära der Agenten. Sie bringen ein Portfolio an Punktintegrationen mit: einen maßgeschneiderten Konnektor hier, ein Servicekonto dort, einen API-Wrapper, den ein Team vor zwei Quartalen entwickelt hat und an den sich niemand mehr so ​​recht erinnert. Jede dieser Lösungen war lokal sinnvoll. Zusammengenommen stellen sie jedoch ein Governance-Problem dar, da jede einzelne Identität, Autorisierung, Protokollierung und Preis-/Kostenkontrolle in ihrer eigenen Sprache neu implementiert – oder einige davon komplett auslässt.

Es folgen vorhersehbar drei Fehlermodi. Erstens: Identitätsverschiebungen: Eine Integration läuft als gemeinsames Dienstkonto, eine andere imitiert den Endbenutzer, eine dritte verwendet einen langlebigen Schlüssel, der von jemandem geprägt wurde, der inzwischen das Team gewechselt hat – also „Wer hat das getan?“ hat N verschiedene Antworten, keine ist vollständig. Zweitens, Autorisierungsfragmente, weil die Regeln dafür, was ein Tool tun darf, in N Codebasen mit N Überprüfungsrhythmen leben; Eine Kontrolle, die Sie an einer Stelle festgezogen haben, bleibt an einer anderen stillschweigend locker. Drittens – das eine Finanz- und Prüfungsgefühl zuerst – schwanken die Zahlen, da die gleiche Frage, die über zwei Integrationspfade beantwortet wird, zwei Antworten liefert. Sobald die Stakeholder den Zahlen nicht mehr vertrauen, spielt das Agentenprogramm keine Rolle mehr.

Die standardisierte Alternative ist weder eine Zauberformel noch kostenlos, aber sie verändert die Arbeitsweise grundlegend. Anstatt N Integrationen N-mal zu verwalten, wird eine Schnittstelle nur einmal verwaltet und Tools werden darüber gezielt bereitgestellt. Die Identität wird zentral festgelegt. Die Autorisierung ist eine Eigenschaft der Schnittstelle, nicht eine Eigenart jedes einzelnen Konnektors. Die Protokollierung ist einheitlich, sodass der Prüfpfad tatsächlich lückenlos ist. Und die Zahlen verändern sich nicht mehr, da es nur einen Berechnungsweg gibt.

Identität und Mandantenkontext: Festlegung beim Zugriff, nicht im Tool

Die erste Frage, die eine Governance-Oberfläche beantworten muss, ist, wessen Berechtigung ein Anruf hat. In einer Multi-Tenant-SaaS-Umgebung ist dies komplex, da zwei unterschiedliche Faktoren eine Rolle spielen: die Identität des Anrufers (welcher Agent, welcher Benutzer oder Dienst agiert) und der Mandantenkontext, in dem der Anruf stattfindet (welche Kundendaten und -berechtigungen gelten). Werden diese Faktoren vermischt, entsteht der klassische „Confused-Deputy-Bug“, bei dem ein für einen bestimmten Zweck rechtmäßig authentifizierter Agent dazu gebracht wird, mit Berechtigungen zu agieren, die er niemals hätte erben sollen.

Es empfiehlt sich, den Mandantenkontext aus der serverseitigen Mandantenbindung abzuleiten, nicht aus den Angaben der Sitzung des Aufrufers. In unserer Implementierung wird die Kundenebene, die den Funktionszugriff steuert, aus dem Mandantenkontext ermittelt und niemals aus der Sitzung des Aufrufers ausgelesen – genau so, dass ein Aufrufer seinen Aktionsradius nicht durch eine scheinbar umfangreichere Sitzung vergrößern kann. Die Identität gibt an, wer fragt; der Mandantenkontext gibt an, in welchem ​​Daten- und Berechtigungsbereich die Antwort berechnet werden muss. Beides wird bereits vor dem Ausführen eines Tools festgelegt.

Hier stellen Sie auch fest, dass Agenten keine Benutzer sind. Ein Mensch in einer Konsole hat Augen, Zögern und einen Manager. Ein Agent hat eine Schleife. Die Identität und der Kontext, die Sie ihm gewähren, sollten widerspiegeln, dass er schneller und buchstäblicher agieren kann als jede von Ihnen bereitgestellte Person.

Autorisierung pro Tool: Die Offenlegung ist eine Entscheidung, keine Standardeinstellung

Die häufigste und gefährlichste Standardeinstellung bei frühen Agentenbereitstellungen ist die Alles-oder-Nichts-Offenlegung: Verbinden Sie den Agenten mit der Plattform und lassen Sie ihn alles erreichen, was die zugrunde liegenden Anmeldeinformationen erreichen können. Praktisch in einer Demo, unhaltbar in der Produktion. Eine Governance-Oberfläche behandelt die Sichtbarkeit und Erlaubnis jedes Tools als bewusste, überprüfbare Entscheidung.

Konkret sollte die Autorisierung mehrdimensional und nicht einfach per Ein/Aus-Schalter erfolgen. Wir verwenden ein dreidimensionales Modell – Umfang und Stufe, wobei die Stufe, wie oben beschrieben, vom Mandantenkontext abhängt. So wird ein bestimmtes Tool nur dann freigegeben, wenn der Umfang des Aufrufers dies zulässt und die Stufe des Mandanten es umfasst. Der Sinn der zweiten Dimension besteht darin, dass die Berechtigungen nicht nur vom Anfragenden, sondern auch von den aktiven Kundenberechtigungen abhängen. Dies sorgt für eine transparente Darstellung: Das Hinzufügen eines neuen Tools zum Katalog macht es nicht automatisch für jeden Agenten in jedem Mieter zugänglich.

Das mentale Modell, das Sie Ihren Architekten vermitteln sollten, ist ein Katalog, keine Schaltzentrale. Jedes Werkzeug im Katalog hat seinen Platz durch eine sorgfältige Entscheidung verdient, wer es unter welchen Mieterbedingungen einsetzen darf. Werkzeuge, die kein Makler aktuell benötigt, sind schlichtweg nicht im Katalog. „Alles oder nichts“ ist ein false Wirtschaftlichkeit; „bewusstes Vorgehen pro Werkzeug“ ist die einzige Haltung, die einer echten Prüfung standhält.

„Bei fehlgeschlagener Bearbeitung“: Die Asymmetrie zwischen Lesen und Handeln

Lese- und Schreibvorgänge sind nicht gleichwertig, und Ihre Governance-Oberfläche sollte dies nicht vortäuschen. Ein fehlerhafter Lesevorgang liefert veraltete oder leere Daten – wiederherstellbar, oft unsichtbar. Ein fehlerhafter Schreibvorgang verändert ein System, sendet eine Nachricht an einen Kunden oder transferiert Geld. Die Kosten eines Fehlers sind asymmetrisch, daher muss auch die Standardeinstellung asymmetrisch sein.

Die Regel, an die wir uns halten, ist, dass Schreibwerkzeuge im geschlossenen Zustand fehlschlagen. Wenn die Autorisierung nicht eindeutig ist, der Mandantenkontext nicht sauber aufgelöst werden kann oder ein Wächter nicht ausgewertet werden kann, findet der Schreibvorgang nicht statt. Dies ist das Gegenteil der komfortorientierten Standardeinstellung, die viele Integrationen übernehmen und bei der eine nicht ausgewertete Prüfung zu „Zulassen“ führt, sodass der glückliche Weg reibungslos bleibt. Beim Fail-Open stellen Sie Wochen später fest, dass ein Agent unter Bedingungen geschrieben hat, die niemand jemals genehmigt hat. Für alles, was den Staat verändert oder einen Kunden berührt, ist die sichere Standardverweigerung, und die Beweislast liegt bei der Entscheidung, nachzuweisen, dass dies zulässig ist.

Es gibt hier eine kulturelle Dimension. Entwickler optimieren für reibungsloses Funktionieren; Sicherheitsexperten optimieren, um schwerwiegende Fehler zu vermeiden. Eine Governance-Oberfläche legt fest, dass der schlimmste Fall – ein unbemerkter, unautorisierter Schreibvorgang – inakzeptabel ist, selbst wenn dies bedeutet, gelegentlich einen ansonsten zulässigen Schreibvorgang zu verweigern.

Budgetkonten und der Not-Aus-Schalter: Kostenkontrolle als zentrales Kontrollinstrument.

Agenten bergen eine Risikokategorie, die bei herkömmlichen Integrationen meist nicht auftrat: autonome Ausgaben. Eine Schleife, die Tools aufruft, kann – aufgrund eines Fehlers oder einer manipulierten Eingabeaufforderung – diese viel häufiger aufrufen als beabsichtigt. Dies kann das Budget API belasten, Folgekosten auslösen oder Kunden mit zu vielen Anfragen überfordern. Kostenkontrolle gehört daher in die Governance-Struktur und darf nicht nachträglich als Abrechnungsalarm hinzugefügt werden, der erst bei entstandenem Schaden auslöst.

Unser Mechanismus verwendet ein Budgetbuch, das vor jeder Ausgabe geprüft wird, mit Limits pro Lauf, pro Tag und rollierenden 30-Tage-Limits sowie einem vor der Ausführung aktivierten Not-Aus-Schalter. Beachten Sie die Reihenfolge: Budget und Abschaltmechanismus werden vor den Ausgaben geprüft, nicht erst danach abgeglichen. Eine Warnung vor Budgetüberschreitungen dient der Fehleranalyse; ein Konto, das die Budgetüberschreitung ablehnt, ist eine Kontrollmaßnahme. Die drei Zeithorizonte sind wichtig, da Fehlerarten unterschiedliche Auswirkungen haben: Eine Endlosschleife überschreitet das Limit pro Lauf, ein falsch konfigurierter Zeitplan das Limit pro Tag, und schleichende Kostensteigerungen werden erst im 30-Tage-Zeitraum sichtbar.

Der Not-Aus-Schalter verdient eine eigene Zeile im Design. Er ist die Steuerung, die Sie verwenden, wenn Sie noch nicht verstehen, was passiert, und die Aktivität sofort stoppen müssen. Er wird vor der Ausführung geprüft und ist ein Schutzschalter, kein Aufräumwerkzeug. Jedes Agentenprogramm sollte eine Frage sofort beantworten können: Wie stoppen wir es? Wenn die Antwort darin besteht, drei Teams zu kontaktieren und Schlüssel manuell zu entziehen, haben Sie keinen Not-Aus-Schalter – aber eine Chance.

Audit und Schwärzung: begrenzt, zeitlich begrenzt und nachvollziehbar

Governance, die nicht beobachtbar ist, ist keine Governance, sondern Absicht. Die letzte Ebene der Oberfläche ermöglicht es, alles darüber liegende nachträglich nachzuweisen. Agentenschlüssel sollten auf die tatsächlich benötigten Tools beschränkt und zeitlich begrenzt sein, sodass der Einflussbereich einer Berechtigung planmäßig auf null sinkt, anstatt unbegrenzt zu bestehen. Ein Schlüssel, der unbegrenzte Möglichkeiten bietet, ist das häufigste Artefakt, das bei der Untersuchung von Sicherheitsvorfällen gefunden wird.

Ebenso muss der Prüfpfad selbst die aufgezeichneten Daten respektieren. Wir wenden eine Anruf-spezifische Schwärzung an, sodass das Protokoll den Ablauf – welches Tool, unter welcher Identität und in welchem ​​Mandantenkontext, mit welchem ​​Ergebnis – erfasst, ohne dabei eine zusätzliche Kopie der hochsensiblen Daten zu erstellen, die durch die Kontrollen geschützt werden sollen. Ein Prüfprotokoll, das unbemerkt Kundendatensätze im Klartext speichert, ist keine Kontrollmaßnahme, sondern ein neues Risiko mit einem harmlos klingenden Namen.

Diese Eigenschaften – Bereichsschlüssel, Zeitgrenzen, Anruf-Redaktion, einheitliches Audit – ermöglichen es einem CISO, die Fragen zu beantworten, die nach einem Vorfall tatsächlich gestellt werden: Was konnte diese Berechtigung bewirken? Wie lange konnte sie dies bewirken? Was hat sie tatsächlich bewirkt? Und können wir dies beweisen, ohne dabei weitere Informationen preiszugeben?

Verknüpfung mit kontinuierlichem Risiko – und Ehrlichkeit hinsichtlich der verbleibenden Möglichkeiten.

Nichts davon ist eine einmalige Angelegenheit. Das NIST AI Risk Management Framework (AI RMF 1.0) stellt ausdrücklich klar, dass das Management von KI-Risiken ein kontinuierlicher Prozess ist und keine Checkliste, die man abarbeitet und dann beiseitelegt. Eine zentrale Steuerungsoberfläche ist gerade deshalb wertvoll, weil sie diesem kontinuierlichen Prozess eine zentrale Anlaufstelle bietet: Wenn ein neues Risiko auftritt, können Sie Berechtigungen, Budgets, Risikopositionen oder Audits über eine einzige Schnittstelle anpassen, anstatt die Änderungen in unzähligen Integrationen nachzuverfolgen. Die Standardisierung macht kontinuierliche Steuerung praktikabel und nicht nur zu einem Wunschtraum. Deshalb zahlt sich eine wohlüberlegte Risikopositionsentscheidung gleich doppelt aus – einmal bei ihrer Umsetzung und jedes Mal, wenn sie überprüft werden muss.

Seien Sie ehrlich bezüglich des Restrisikos, denn Ihr Vorstand wird es sein. Eine Governance-Oberfläche verringert die Angriffsfläche und macht Aktivitäten überprüfbar; sie macht die Mitarbeiter jedoch nicht unfehlbar. Eine schnelle Einschleusung kann immer noch versuchen, einen rechtmäßig autorisierten Mitarbeiter zu einem scheinbar legitimen Missbrauch zu verleiten. Ein bewusst offengelegtes Tool kann innerhalb seiner Berechtigungen missbraucht werden. Budgets begrenzen die Kosten, aber nicht die Urteilsfähigkeit. Die Deloitte-Studie „State of AI in the Enterprise“ hat wiederholt die Kluft zwischen den KI-Ambitionen und der operativen Reife zur Steuerung dieser KI aufgezeigt – und genau in dieser Kluft liegen die Restrisiken. Die richtige Reaktion ist nicht zu behaupten, die Kluft sei geschlossen, sondern sie zu verringern, sichtbar zu machen und kontinuierlich zu managen.

Auf dieser Überzeugung basiert unsere Plattform. SocialHub.AI stellt semantische Layer-Tools über MCP mittels HTTP-Streaming bereit. Diese sind über Agenten wie Claude, GitHub Copilot und Microsoft 365 Copilot erreichbar. Die hier beschriebenen Kontrollen werden direkt in der Schnittstelle implementiert und nicht über verschiedene Konnektoren verteilt: dreistufige Autorisierung mit Ebenen aus dem Mandantenkontext, fehlgeschlagene Schreibvorgänge, ein Budgetbuch pro Lauf/pro Tag/30 Tage mit einem Kill-Switch vor der Ausführung sowie zeitlich begrenzte Agentenschlüssel mit Anruf-Redaktion und -Auditierung. Dieselbe Governance-Disziplin bildet die Grundlage für unsere Loyalitätsarbeit, in deren Rahmen wir den GMV-Beitrag der Mitglieder von McDonald's China von etwa 5 % auf 85 % steigern konnten. Ergebnisse dieser Größenordnung sind nur möglich, wenn die Schnittstelle zu den Daten von Grund auf vertrauenswürdig ist.

Wenn Sie entscheiden, wie Ihre Mitarbeiter auf Ihre Systeme zugreifen, sollten Sie Ihrem Team nicht die Frage stellen: „Welcher Konnektor?“, sondern: „Wo werden Identität, Autorisierung, Protokollierung und Kosten festgelegt, und erfolgt dies an einem zentralen Ort oder an mehreren?“ Wenn Sie sehen möchten, wie eine Governance-orientierte Oberfläche MCP in der Praxis aussieht, buchen Sie eine Demo oder erfahren Sie mehr über unseren Ansatz unter /platform/ai-frontier.