Fünf Fragen, die vor dem Produktivbetrieb von MCP zu beantworten sind

MCP hat den langweiligen Teil standardisiert, einem Agenten Werkzeuge zu geben: ein HTTP-Endpunkt, ein list_tools-Aufruf, und die Werkzeuge erscheinen in der aufrufbaren Liste des Modells. Als wir intern das erste Mal eines angebunden haben, dauerte das einen Nachmittag, und dieser Teil ist tatsächlich gelöst. Dann wollten wir es in Produktion bringen, jemand aus der Sicherheit stellte fünf Fragen, und keine davon hatte eine Antwort. Dieser Beitrag sind jene fünf Fragen und wie sie am Ende in SOIT beantwortet wurden, einer quelloffenen Agent-Laufzeit, deren Governance mitten im Aufrufpfad sitzt. Jede Aussage verweist auf eine Datei im Repository, denn Texte dieser Art lassen sich ungewöhnlich leicht als Foliensatz statt als Software schreiben.

Die erste Frage lautet, wer ein bestimmtes Werkzeug aufrufen darf. MCP hat dazu keine Meinung: Was list_tools zurückgibt, kann das Modell aufrufen, Sichtbarkeit ist also gleich Berechtigung. In einer mandanten- und arbeitsbereichsfähigen Installation reicht das nicht, deshalb installiert SOIT einen MCP-Server als Plugin-Artefakt und nicht als Konfigurationseintrag. Werkzeugreferenzen tragen einen Namensraum, und jede Auflösung führt einen Anfragekontext mit Mandant, Arbeitsbereich und Benutzer mit sich. Daraus folgt zweierlei: Aus Sicht des Agenten sehen ein Plugin-Werkzeug, ein MCP-Werkzeug und ein eingebauter Adapter gleich aus, mit typisierten und versionierten Bindungen; und Berechtigungsprüfung, Secret-Injektion, Egress-Grenzen, Audit, Kostenzuordnung, Tracing und Wiederholung gelten für MCP-Werkzeuge automatisch, sodass niemand den Governance-Pfad zweimal schreibt. Jede Agent-Version trägt zudem eine Freigabeliste über Modelle, Wissensbasen, Workflows, Werkzeuge, Plugins und MCP-Server, womit die Frage, was Version drei eines Agenten aufrufen darf, vergleichbar und zurückrollbar wird.

Die zweite Frage ist, wo die Zugangsdaten liegen. Die meisten Integrationsbeispiele legen ein Token im Klartext in eine Konfigurationsdatei, und so landet es in git, in Logs und in der Konfigurationssicherung, die jemand auf einen Laptop exportiert hat. SOIT lehnt das rundweg ab: Beim Bau der Authentifizierung wird geprüft, ob ein wörtliches Token- oder Wertfeld vorliegt, und ein Fehler ausgelöst, der besagt, dass Zugangsdaten eine Secret-Id verwenden müssen. Akzeptiert wird nur eine Referenz, die zur Aufrufzeit über den Secrets-Port aufgelöst wird, und API-Schlüssel sind nur in Headern zulässig, niemals in der Query, weil diese über Logs und Referrer ausläuft. Der echte Wert existiert nur für die Dauer des Aufrufs im Speicher; was in Datenbank, Audit und Traces landet, ist eine geschwärzte Kopie, die im selben Durchgang entsteht und nur Secret-Id und Signaturrichtlinienreferenz behält. Drei Authentifizierungsarten werden unterstützt, und OAuth folgt der 2.1-Form mit Discovery des Autorisierungsservers und ressourcengebundenen Token über Client Credentials. Eine Einschränkung sei klar benannt: Der browserbasierte Authorization-Code-Fluss ist nicht implementiert, weil SOIT MCP-Server im eigenen Namen aufruft und nicht im Namen eines Benutzers vor einem Browser.

Die dritte Frage sollte am meisten beunruhigen: Wohin darf das Ding sich verbinden. Ein MCP-Server stellt Netzwerkanfragen in Ihrem Namen; schreiben Sie eine URL in die Argumente, holt er sie ab, und die klassische Form dieses Angriffs ist die Bitte um die Cloud-Metadatenadresse mit den temporären Zugangsdaten. Die Egress-Richtlinie von SOIT verweigert standardmäßig, in drei Schichten. Die erste ist die Domänenrichtlinie, die das Ziel gegen mandanten- und arbeitsbereichsbezogene Freigabe- und Sperrlisten prüft, wobei die Sperrliste gewinnt; die Freigabeliste ist standardmäßig leer, es geht also nichts durch, bis Sie es sagen, und wirft die Richtlinienabfrage selbst einen Fehler, lautet die Antwort Ablehnung statt Erlaubnis. Fail-closed ist kein Slogan, sondern das, was Sie tatsächlich in jeden Ausnahmezweig geschrieben haben. Die zweite Schicht prüft jede Adresse nach der Auflösung, denn DNS-Rebinding lässt einen freigegebenen Namen auf eine Loopback- oder private Adresse zeigen: Der Wächter löst den Namen auf und verlangt, dass jede zurückgegebene Adresse global routbar ist, und lehnt die gesamte Anfrage ab, wenn eine es nicht ist; ebenso werden Nicht-HTTP-Schemata und URLs mit eingebetteten Zugangsdaten abgelehnt und ein DNS-Fehler als Ablehnung behandelt. Die dritte Schicht autorisiert jeden Sprung, denn eine URL, die beide Prüfungen bestanden hat, kann immer noch eine Weiterleitung in Ihr internes Netz zurückgeben. Die Autorisierung hängt deshalb am Request-Event-Hook des ausgehenden HTTP-Clients, sodass jede tatsächlich hinausgehende Anfrage geprüft wird, Weiterleitungssprünge eingeschlossen, und Weiterleitungen werden standardmäßig nicht verfolgt. Der MCP-Adapter baut seine Sitzungen mit diesem Client, also liegen Initialisierung, Auflistung und jeder Aufruf innerhalb dieser Schranken.

Die vierte Frage lautet, ob sich hinterher feststellen lässt, was geschehen ist. Werkzeugaufrufe sind die einzige Stelle, an der ein Agent echte Seiteneffekte erzeugt: Ein Modell, das etwas Falsches sagt, kann man erneut fragen, aber ein Werkzeug, das eine Zeile in der Produktionsdatenbank geändert hat, hat sie geändert. SOIT persistiert jeden Aufruf als Schritt eines Laufs und schreibt zwei Nachweise. Das Gateway-Audit hält auf der Anfrageseite Werkzeugreferenz, geschwärzte Parameter und Egress-Entscheidung fest, auf der Antwortseite Erfolg, Ergebnistyp, Metadaten und Fehler; auch der Fehlerpfad schreibt, und das Absetzen dieses Eintrags ist das Erste, was der Ausnahmezweig tut — genau der Teil, den man vergisst und den man braucht, wenn etwas schiefgegangen ist. Daneben erfassen Schrittmetriken Latenz, Erfolgskennzeichen, zusammengefasste Argumente und Ergebnisse sowie Fehlercode und Details. Derselbe Aufruf schreibt einen Kosteneintrag mit Anbieter und Quellport, sodass die Frage, was die MCP-Werkzeuge eines Agenten in diesem Monat gekostet haben, eine Abfrage ist, die sich nach Agent, Workflow, Werkzeug und Quellart aufschlüsseln lässt. Darüber liegt ein OpenTelemetry-Span mit Mandanten-, Arbeitsbereichs-, Lauf- und Schritt-Ids für das APM, das Sie ohnehin betreiben.

Die fünfte Frage ist die nach der Wiederholbarkeit. Die frustrierendste Eigenschaft der Agent-Fehlersuche ist, dass sie nicht reproduziert: gleiche Eingabe, andere Argumentation. Auf der Werkzeugebene kann man immerhin deterministisch sein. Jeder Aufruf trägt einen Idempotenzschlüssel, standardmäßig aus Lauf- und Aufruf-Id gebildet, und beansprucht einen Ausführungsdatensatz mit Lease; trifft der Anspruch auf einen bereits abgeschlossenen Datensatz, kommt die zwischengespeicherte Antwort direkt zurück und das externe Werkzeug wird nicht erneut aufgerufen. Die Wiederholungsstrategie ändert sich entsprechend und fällt auf einen einzigen Versuch, sobald ein Idempotenzschlüssel vorliegt; der Kommentar im Code sagt es besser als ein Absatz: Dauerhafte Agent-Aufrufe sind an dieser Grenze höchstens einmalig, weil nicht jeder nachgelagerte Adapter Ihren Schlüssel achtet. Einmal zu wenig aufzurufen ist besser als einmal zu viel, und bei Schreibvorgängen ist dieser Handel keine echte Wahl. Ratenbegrenzungen und Tageskontingente kommen mit, geschlüsselt nach Werkzeugreferenz plus Mandant, Arbeitsbereich und Benutzer, damit ein außer Kontrolle geratener Agent nicht das Drittanbieter-Budget eines ganzen Mandanten verbrennt.

Die ehrliche Liste dessen, was das nicht leistet: Der Transport ist ausschließlich streamendes HTTP gegen die v1-Linie des MCP-SDK, die zustandslose Protokollrevision vom 28. Juli 2026 wird noch nicht unterstützt; OAuth beschränkt sich auf Client Credentials; ein Marktplatz für die Installation eines MCP-Werkzeugs per Klick steht auf der Roadmap, heute installiert man Plugin-Artefakte von Hand; und die standardmäßig leere Egress-Freigabeliste bedeutet, dass Ihr erster MCP-Server abgelehnt wird, bis Sie seine Domäne ausdrücklich eintragen, was gewollt ist, dem Schnellstart aber einen Schritt hinzufügt. Eine weitere Dauerfrage lautet, wie sich all das zu den Agent-Frameworks verhält. Es sind nicht dieselben Schichten. Ein Framework beantwortet, wie ein Aufruf orchestriert wird; eine Laufzeit beantwortet, unter wessen Identität er lief, mit wessen Zugangsdaten, was er erreichen konnte, welche Nachweise er hinterließ und ob er wiederholbar ist. Das Erste beschäftigt Sie beim Schreiben des Codes, das Zweite nach dessen Auslieferung, wenn ein anderer fragt. Man kann Berechtigungsprüfungen selbstverständlich in ein Framework legen, aber dann implementiert jede neue Werkzeuganbindung die Governance-Logik erneut, während ihre Verlagerung in die Port-Schicht der Laufzeit genau der Grund ist, weshalb MCP-Werkzeuge, Plugin-Werkzeuge und eingebaute Werkzeuge denselben Weg nehmen. SOIT steht unter Apache-2.0, der Code liegt auf github.com/soit-ai/soit, Schnellstart und eine zwanzigminütige Governance-Demo im Dokumentationsverzeichnis. Wenn Sie MCP gerade in Richtung Produktion schieben: Die schwerste der fünf Fragen ist meist keine technische, sondern die, wer entscheiden darf, was auf die Freigabeliste kommt.