Enterprise MCP-Governance: Wie man den Zugriff auf MCP-Server im großen Maßstab kontrolliert, prüft und sichert

Fragen Sie Ihr Sicherheitsteam, wie viele MCP-Server derzeit in Ihrem Unternehmen laufen. Wenn sie diese Frage mit Zuversicht beantworten können, sind Sie den meisten Unternehmen voraus. Wenn nicht, haben Sie ein Governance-Problem, das bereits in Produktion ist.

Die Einführung von MCP ging schnell. Teams verbanden Agenten über MCP-Server mit GitHub, Slack, internen Datenbanken und Drittanbieter-APIs, oft ohne IT-Überprüfung, ohne Richtlinie für Anmeldeinformationen und ohne Möglichkeit für das Sicherheitsteam, zu sehen, worauf diese Server zugreifen konnten. Das Protokoll ist gerade deshalb nützlich, weil es Werkzeugverbindungen einfach macht. Diese Einfachheit ist es auch, die unkontrollierte MCP-Bereitstellungen zu einem echten Sicherheitsrisiko macht.

MCP-Server sind keine passiven APIs. Sie gewähren KI-Agenten direkten, programmatischen Zugriff auf sensible Systeme. Diese Agenten handeln auf der Grundlage autonomer Schlussfolgerungen, nicht auf überprüften Codepfaden. Wie ein führender Sicherheitsexperte bei Medtronic es ausdrückte: „MCP eröffnet viele Möglichkeiten, sehr schnell großen Schaden anzurichten.“ Gartner prognostiziert, dass 70 % der Softwareentwicklungsteams, die multimodale Anwendungen entwickeln, bis 2028 KI-Gateways nutzen werden, gegenüber 25 % im Jahr 2025. Die Teams, die jetzt Governance aufbauen, werden in der Lage sein, sicher zu skalieren.

Dieser Leitfaden behandelt, was MCP-Governance für Unternehmen erfordert, warum Standard-Sicherheitstools nicht ausreichen, wie man das Vier-Säulen-Framework aufbaut, auf das sich Compliance-Teams verlassen können, und wie TrueFoundry all dies in Ihrer eigenen Cloud implementiert.

Was MCP-Governance für Unternehmen erfordert

MCP-Governance für Unternehmen ist das vollständige operative Framework zur Verwaltung, welche MCP-Server in Ihrem Unternehmen existieren, wer darauf zugreifen kann, was sie tun dürfen und was bei ihrer Nutzung aufgezeichnet wird. Es ist kein Richtliniendokument. Es ist eine durchgesetzte Infrastruktur.

Die meisten Teams unterschätzen den Umfang. Governance umfasst jeden MCP-Server in der Umgebung: Drittanbieter-Tools, die Entwickler ohne IT-Überprüfung verbunden haben, interne Tools, die Produktteams entwickelt und bereitgestellt haben, und MCP-Server, die in IDE-Konfigurationen in Cursor, Claude Code und ähnlichen Tools eingebettet sind. Wenn ein MCP-Server ein Produktionssystem erreichen kann, fällt er in den Geltungsbereich.

MCP-Governance unterscheidet sich auch von der Standard-API-Governance in einer Weise, die für den Aufbau relevant ist. Ein REST-API-Aufruf führt einen deterministischen Codepfad aus, den ein Entwickler geschrieben und überprüft hat. Ein MCP-Tool-Aufruf ist eine autonome Entscheidung, die ein KI-Agent zur Laufzeit auf der Grundlage seiner Schlussfolgerungen trifft. Das Bedrohungsmodell, die Prüfanforderungen und die Kontrollen zur Aufrechterhaltung der Rechenschaftspflicht sind alle unterschiedlich. MCP wie eine konventionelle API-Integration zu behandeln, führt dazu, dass Unternehmen Prüflücken aufweisen, die sie einem Regulator nicht erklären können.

• Umfang: Alle MCP-Server. Dazu gehören interne Server, die von Produktteams erstellt wurden, Server, die in CI/CD-Pipelines laufen, und alles, was ein Entwickler lokal in seiner IDE konfiguriert hat.

• Mechanismus: Ein zentralisiertes Gateway zwischen allen Clients und allen MCP-Servern. Das Gateway setzt Richtlinien durch. Einzelne MCP-Server implementieren keine eigenen Zugriffskontrollen, was diesen Ansatz über Hunderte von Servern skalierbar macht.

• Ergebnis: Jeder Tool-Aufruf wird gegen eine verifizierte Identität autorisiert und in einem strukturierten, abfragbaren Format protokolliert, das einer Compliance-Prüfung und Incident-Untersuchung standhält.

MCP-Sicherheitsrisiken, die Unternehmen nicht ignorieren können

MCP-Server operieren innerhalb der Denklogik eines KI-Agenten. Ein traditioneller API-Aufruf wird deterministisch durch Anwendungscode ausgelöst. Ein MCP-Tool-Aufruf hingegen wird ausgelöst, wenn ein Agent zur Laufzeit feststellt, dass ein Tool für eine bestimmte Aufgabe geeignet ist. Diese Entscheidung wird durch die Modelllogik und nicht durch einen explizit definierten Kontrollfluss beeinflusst, was die Sichtbarkeit reduziert, die Entwickler normalerweise darüber haben, wie und warum ein Tool aufgerufen wird. In diesem Modell wird die Denklogik effektiv Teil des Kontrollpfads, ist aber nicht direkt über Standard-Anwendungssicherheitstools beobachtbar.

Sicherheitsforscher haben dies in der Produktion dokumentiert. Prompt-Injection-Angriffe, die über MCP-Tool-Beschreibungen erfolgen, lenken das Agentenverhalten um, ohne eine einzige Codezeile zu berühren. Die Offenlegung von Anmeldeinformationen durch schlecht konfigurierte MCP-Server schafft Zugriffspfade, für die Perimeterkontrollen nie ausgelegt waren. Dies sind keine theoretischen Angriffsszenarien aus Forschungsarbeiten. Es sind dokumentierte Vorfälle aus realen Unternehmensbereitstellungen.

Shadow-MCP-Server-Bereitstellungen können Standard-Zugriffskontrollen umgehen

Wenn Entwickler MCP-Server ohne IT-Prüfung bereitstellen oder sich mit ihnen verbinden, umgehen sie jede Kontrolle, die normalerweise für eine neue Systemintegration gilt: Anbieter-Sicherheitsbewertung, Datenzugriffsklassifizierung und Zugriffs-Bereitstellungs-Workflows. Der Server geht ohne die Dokumentation, Überwachung oder Einschränkungen in Produktion, die jedes andere Unternehmenssystem mit sich bringt.

Ohne ein zentrales Register gibt es keine zuverlässigen Antworten auf grundlegende Sicherheitsfragen. Welche MCP-Server sind aktiv? Welche Anmeldeinformationen besitzen sie? Welche Datenbanken können sie abfragen? Welche externen Dienste können sie aufrufen? Diese Unsichtbarkeit schließt diese Server vollständig von Schwachstellenanalysen, Anbieter-Risikobewertungen und Penetrationstests aus.

Ein einzelner nicht genehmigter MCP-Server mit Lesezugriff auf ein internes CRM oder Code-Repository ist ein ungeprüfter Datenpfad, den Perimeterkontrollen nicht erfassen werden. Der Datenverkehr stammt aus dem internen Netzwerk, von einem Entwicklerrechner, der dort sein soll.

Vergiftung von Tool-Beschreibungen umgeht Abwehrmaßnahmen auf Netzwerkebene

Wenn ein Agent sich mit einem MCP-Server verbindet und tools/list aufruft, antwortet der Server mit Tool-Namen, Beschreibungen und Parameterschemata. Der Agent verwendet diese Metadaten, um zu entscheiden, welche Tools aufgerufen und wie sie verwendet werden sollen. Manipulieren Sie diese Metadaten, und Sie lenken das Verhalten des Agenten um, ohne eine Code-Schwachstelle auszunutzen.

Die Vergiftung von Tool-Beschreibungen bettet bösartige Anweisungen in Tool-Metadaten ein, die den Agenten dazu veranlassen, unbeabsichtigte Aktionen auszuführen: Daten zu exfiltrieren, Tools außerhalb ihres vorgesehenen Umfangs aufzurufen oder Sicherheitsprüfungen zu umgehen, während er scheinbar seine zugewiesene Aufgabe ausführt. Der bösartige Inhalt wird im HTTP-Antworttext vom MCP-Server übertragen, insbesondere innerhalb der tools/list-Nutzlast. Standard-Webanwendungs-Firewalls und API-Sicherheitstools haben zwar Einblick in HTTP-Antworttexte, können diesen Angriff jedoch nicht erkennen, da der bösartige Inhalt semantisch eingebettete natürliche Sprache ist und keine syntaktische Anomalie wie eine bekannte Exploit-Signatur oder ein fehlerhafter Header. Der Angriff ist auf der logischen Ebene erfolgreich, wo der Agent Tool-Beschreibungen als legitime Anweisungen interpretiert und entsprechend handelt.

Die MCP Pre Tool Guardrails von TrueFoundry prüfen Tool-Parameter und Aufrufargumente vor der Ausführung mithilfe einer modellbasierten Prompt-Injection-Erkennung. Wenn Tool-Aufrufargumente umgeleitete Anweisungen enthalten, wird die Ausführung blockiert, bevor das Tool ausgeführt wird, und die Erkennung wird im Anforderungs-Trace protokolliert.

Geteilte MCP-Server-Anmeldeinformationen machen Compliance-Verantwortlichkeit unmöglich

MCP-Server, die gemeinsame API-Schlüssel oder Dienstkonto-Tokens verwenden, können nicht die zuordenbaren Audit-Datensätze erstellen, die Compliance-Frameworks erfordern. Wenn zehn Agenten einen Satz von Anmeldeinformationen teilen, gibt es keine Möglichkeit, einen bestimmten Tool-Aufruf einem bestimmten Benutzer, einer Agenteninstanz oder einem Team zuzuordnen. In einem regulierten Umfeld ist diese Lücke keine Unannehmlichkeit. Es ist ein direkter Compliance-Verstoß.

HIPAA verlangt Audit-Trails, die einem identifizierbaren Benutzer oder Dienst für jeden Zugriff auf geschützte Gesundheitsinformationen zugeordnet werden können. SOC2 CC6 erfordert Zugriffskontrollen mit Nachweis der Durchsetzung. Das Rechenschaftsprinzip der DSGVO verlangt von Organisationen, nachzuweisen, dass die Datenverarbeitung autorisiert und dokumentiert wurde. MCP-Bereitstellungen mit gemeinsamen Anmeldeinformationen können keine dieser Anforderungen erfüllen. TrueFoundry ersetzt gemeinsame Anmeldeinformationen durch Personal Access Tokens, die an einzelne Benutzer gebunden sind, und Virtual Account Tokens für den Zugriff auf Anwendungsebene, sodass jeder Tool-Aufruf eine überprüfbare Identität trägt.

Die vier Säulen der Enterprise MCP-Governance

Ein vollständiges Enterprise MCP-Governance-Framework erfordert vier zusammenwirkende Funktionen: einen zentralisierten Katalog, identitätsbasierte Zugriffskontrollen, strukturierte Audit-Protokollierung und Echtzeit-Richtliniendurchsetzung. Jede hängt von den anderen ab. Sie können Zugriffsrichtlinien nicht durchsetzen, bevor Sie wissen, welche Server existieren. Sie können keinen Audit-Trail ohne Identitätszuordnung erstellen. Und nachträgliche Audit-Protokolle ohne Echtzeit-Durchsetzung sind forensische Aufzeichnungen, keine Sicherheitskontrollen.

Vier Säulen: Kernfunktion, TrueFoundry-Implementierung und Compliance-Abdeckung

Säule 1: Ein zentralisierter MCP-Server-Katalog

Der Katalog ist das maßgebliche Register aller genehmigten MCP-Server in Ihrer Organisation. Jeder Eintrag enthält die Informationen, die Sicherheitsteams zur Risikobewertung benötigen: Servername, Eigentümerteam, Datenzugriffsbereich, Authentifizierungsmethode, Genehmigungsstatus, Verbindungsparameter und alle Nutzungsbeschränkungen wie genehmigte Benutzergruppen oder Ratenbegrenzungen.

Neue Server durchlaufen einen Prüfungs-Workflow. Die Überprüfung der Tool-Beschreibung filtert Vergiftungsrisiken heraus, bevor der Server Entwicklerumgebungen erreicht. Eine Datenzugriffsbewertung bestimmt, worauf der Server zugreifen kann. Eine explizite Genehmigung steuert die Verteilung. Nichts davon erfordert Änderungen am MCP-Server selbst. Es geschieht auf der Katalogebene, und einzelne Serverimplementierungen bleiben unberührt.

Der Katalog übernimmt auch die Verteilung. Entwickler übernehmen vorab genehmigte Serverkonfigurationen direkt in ihre IDE-Integrationen, anstatt Server manuell zu konfigurieren. Nur vom Katalog genehmigte Server erreichen Entwicklerrechner. Die Virtual MCP Server-Funktion von TrueFoundry erweitert dies: Plattformteams stellen kuratierte Tool-Untergruppen aus mehreren registrierten Servern zusammen und legen nur das offen, was ein bestimmtes Team oder ein Anwendungsfall benötigt, ohne neue Infrastruktur bereitzustellen.

Säule 2: SSO und MCP-Server-Zugriffskontrolle auf der Gateway-Ebene

Der MCP-Zugriff muss über denselben Identitätsanbieter erfolgen, der alles andere in der Organisation regelt. TrueFoundry unterstützt OAuth2 Two-Legged- und Three-Legged-Flows, SAML 2.0 und die direkte Integration mit Okta, Azure Active Directory, Auth0, Cognito und jedem JWKS-kompatiblen IdP. Der MCP-Zugriff wird über dieselben Onboarding- und Offboarding-Workflows bereitgestellt und entzogen, die E-Mail, Repositories und Cloud-Konsolen abdecken. Wenn ein Entwickler das Unternehmen verlässt, wird der MCP-Zugriff automatisch entzogen.

Das Gateway unterstützt drei eingehende Authentifizierungsmethoden, je nachdem, wer den Aufruf tätigt. Personal Access Tokens (PATs) werden in der TrueFoundry UI unter Einstellungen > API-Schlüssel generiert, sind an einzelne Benutzer gebunden und die Standardwahl für Entwicklungs-Workflows. Virtual Account Tokens (VATs) sind Dienstkonten mit definierten Berechtigungen, geeignet für Produktionsagenten und Server-zu-Server-Workflows. Externe IdP-Tokens ermöglichen es Benutzern ohne TrueFoundry-Konten, sich über ihren eigenen Identitätsanbieter zu authentifizieren, was B2B SaaS und kundenorientierte Agenten-Bereitstellungen abdeckt.

Für die ausgehende Authentifizierung zu nachgelagerten MCP-Servern verwaltet TrueFoundry den gesamten Lebenszyklus der Anmeldeinformationen über sechs Muster hinweg. OAuth-Autorisierungscode-Flows regeln den benutzerbezogenen Zugriff auf Dienste wie GitHub und Slack, wobei das Gateway die Zustimmung, die Token-Speicherung und die automatische Aktualisierung verwaltet. OAuth-Client-Credentials-Flows regeln den Server-zu-Server-Zugriff. Gemeinsame und individuelle API-Schlüsselmodi decken einfachere Fälle ab, bei denen das Gateway die richtigen Anmeldeinformationen pro Anfrage injiziert. Token-Passthrough leitet das eingehende Token unverändert weiter, wenn der MCP-Server es direkt validieren kann. Die Token-Weiterleitung über den x-tfy-mcp-headers-Header behandelt Szenarien, in denen der MCP-Server ein separates Anmeldeinformationssystem verwendet.

MCP-Server-Zugriffskontrolle: Authentifizierungsmuster in gängigen Unternehmensszenarien

RBAC-Richtlinien legen fest, welche Teams oder Einzelpersonen welche Server und Tools aufrufen können. Diese Richtlinien befinden sich am Gateway, nicht auf einzelnen MCP-Servern, sodass eine Richtlinienaktualisierung sofort für alle Clients wirksam wird, ohne dass der Server neu bereitgestellt werden muss. Ein Data-Science-Team erhält Zugriff auf Analysetools, aber nicht auf Bereitstellungsserver. Ein Sicherheitsteam erhält Lesezugriff auf alle Server zu Prüfzwecken.

Säule 3: Strukturiertes Audit-Logging verknüpft mit jedem Tool-Aufruf

Jeder MCP-Tool-Aufruf benötigt einen Log-Eintrag, der den vollständigen Aufrufkontext erfasst: Zeitstempel, Anruferidentität, MCP-Server-Identifikator, Tool-Name, Eingabeparameter, Antwortzusammenfassung, Richtlinienentscheidung mit Begründung, Guardrail-Ergebnisse pro Hook mit Ausführungszeit und Ergebnissen sowie die Gesamt-Latenz. Diese Felder müssen als strukturiertes JSON vorliegen, damit SIEM-Systeme und Compliance-Reporting-Tools sie abfragen können.

TrueFoundry steuert die Protokollierung auf zwei Ebenen. Auf Anfrageebene erfasst der Header X-TFY-LOGGING-CONFIG mit enabled: true die vollständige Anfrage. Auf Gateway-Ebene bei selbst gehosteten Bereitstellungen legt die Umgebungsvariable REQUEST_LOGGING_MODE das globale Verhalten fest: ALWAYS protokolliert jede Anfrage unabhängig von Headern, was die richtige Einstellung für regulierte Produktionsumgebungen ist. HEADER_CONTROLLED berücksichtigt die Einstellungen pro Anfrage. NEVER unterdrückt die gesamte Protokollierung für Umgebungen, in denen dies angemessen ist.

Anfragelogs sind in der TrueFoundry-Benutzeroberfläche unter AI Gateway > Monitor > Requests sichtbar. Individuelle Guardrail-Ausführungsspannen erscheinen unter AI Gateway > Monitor > Request Traces und zeigen, welche Guardrails auf welchem Hook ausgeführt wurden, den Pass/Fail-Status, die Ausführungszeit und angewendete Mutationen. Für Organisationen, die Logs an ihre eigene Infrastruktur weiterleiten, exportiert TrueFoundry über OpenTelemetry an Grafana, Datadog, Splunk und jedes OTLP-kompatible Ziel. Bei selbst gehosteten Bereitstellungen werden Log-Daten in Ihrem eigenen AWS S3, GCS oder Azure Blob Storage im Parquet-Format gespeichert und sind über Spark, DuckDB oder Athena abfragbar.

HIPAA schreibt die Aufbewahrung sicherheitsrelevanter Dokumentation für sechs Jahre vor. In der Praxis werden Audit-Logs oft für eine ähnliche Dauer aufbewahrt, um Compliance und die Untersuchung von Vorfällen zu unterstützen. Viele Finanzunterlagen folgen einem siebenjährigen Aufbewahrungsstandard. Logs müssen manipulationssicher sein, mit Zugriffskontrollen, die eine Änderung durch die Teams, die sie generieren, verhindern. Die selbst gehosteten Bereitstellungsoptionen von TrueFoundry halten alle Log-Daten innerhalb des Cloud-Kontos des Kunden und unterstützen so sowohl die Aufbewahrungs- als auch die Manipulationssicherheitsanforderungen.

Säule 4: Echtzeit-MCP-Richtliniendurchsetzung, bevor das Tool ausgeführt wird

Zu protokollieren, was passiert ist, ist nicht dasselbe wie es zu verhindern. Die Richtliniendurchsetzung muss zum Zeitpunkt des Aufrufs erfolgen, bevor der Tool-Aufruf den MCP-Server erreicht, damit unbefugter Zugriff blockiert und nicht erst nachträglich dokumentiert wird.

Das Guardrail-System von TrueFoundry implementiert zwei Hooks pro Tool-Aufruf. MCP Pre-Tool-Guardrails werden ausgeführt, bevor das Tool ausgeführt wird. Wenn einer von ihnen fehlschlägt, wird das Tool niemals ausgeführt, wodurch Kosten, Nebenwirkungen und Datenexposition eines fehlerhaften Aufrufs vollständig vermieden werden. Integrierte Pre-Tool-Guardrails umfassen: SQL Sanitizer, der DROP, TRUNCATE, DELETE und UPDATE ohne WHERE sowie String-Interpolationsmuster, die ein Injektionsrisiko anzeigen, abfängt; Prompt-Injection-Erkennung mittels modellbasierter Analyse für Jailbreak- und Injektionsversuche in Tool-Aufrufparametern; Secrets Detection, die API-Schlüssel, AWS-Anmeldeinformationen, JWT-Token und private Schlüssel abfängt, bevor sie Backend-Dienste erreichen; sowie Cedar- und OPA-Richtlinien-Guardrails für deklarative, fein granulare Zugriffskontrolle bis hin zu spezifischen Tool-Argumenten.

MCP Post-Tool-Guardrails werden ausgeführt, nachdem das Tool zurückkehrt, bevor das Ergebnis den Agenten erreicht. Integrierte Post-Tool-Guardrails umfassen: Code Safety Linter, der eval, exec, os.system, Subprocess-Aufrufe und gefährliche Shell-Befehle in der Tool-Ausgabe kennzeichnet; PII-Erkennung, die persönliche Informationen mit konfigurierbaren Entitätskategorien findet und redigiert; und Regex-Musterabgleich für benutzerdefinierte Muster, die Zahlungskarten, interne Identifikatoren und domänenspezifische sensible Daten abdecken. Externe Anbieter wie AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike und Google Model Armor integrieren sich alle über dasselbe Hook-System.

Durchsetzungsstrategien sind pro Guardrail konfigurierbar. „Enforce“ blockiert bei Verstößen und bei Guardrail-Fehlern. „Enforce But Ignore On Error“ blockiert bei Verstößen, lässt aber Anfragen durch, wenn der Guardrail-Anbieter nicht verfügbar ist, was der empfohlene Standard für die Produktion ist. „Audit“ protokolliert Verstöße ohne zu blockieren, der richtige Modus während der ersten Einführung. Die empfohlene Reihenfolge ist zuerst Audit, dann Enforce But Ignore On Error und dann vollständiges Enforce, wenn das Vertrauen wächst.

Bereitstellung eines Enterprise MCP Gateways: Ein vierstufiger Implementierungsplan

MCP-Governance ist ein sequenzielles Programm. Jeder Schritt baut auf dem vorherigen auf. Sie können keine Zugriffsrichtlinien durchsetzen, bevor Sie wissen, welche Server existieren. Sie können keinen aussagekräftigen Audit-Trail erstellen, bevor die Identitätszuweisung erfolgt ist.

Schritt 1: Inventarisierung aller bestehenden MCP-Bereitstellungen

Beginnen Sie mit einer vollständigen Prüfung jedes laufenden MCP-Servers in Entwicklerumgebungen, CI/CD-Pipelines, Produktionsagenten-Bereitstellungen und IDE-Konfigurationen. Dies umfasst Server, die Entwickler lokal in Cursor oder Claude Code ohne Beteiligung der IT konfiguriert haben. Die Kombination aus automatisiertem Scannen von Cloud-Umgebungen und einem Selbstberichtsprozess für lokale Entwicklerkonfigurationen liefert das vollständigste Bild für große Organisationen.

Erfassen Sie für jeden Server: Name und Zweck, Eigentümerteam, Datenzugriffsbereich, Authentifizierungsmethode (falls vorhanden) und wie lange er bereits läuft. Ziel ist ein genaues Bild dessen, was vor der Einführung der Governance existierte, und keine kuratierte Liste bereits genehmigter Elemente.

Schritt 2: Erstellen des genehmigten MCP-Serverkatalogs

Bevor Sie Server migrieren, definieren Sie das Metadaten-Schema und den Genehmigungsworkflow. Wichtige Entscheidungen: wer die Genehmigungsbefugnis für verschiedene Risikostufen hat, was die Prüfliste abdeckt und welche Ergebnisse die Katalogregistrierung blockieren. Legen Sie diese Kriterien fest, bevor Sie Server kategorisieren, damit sie konsistent angewendet werden.

Gehen Sie das Inventar durch und kategorisieren Sie jeden Server als für den Katalog genehmigt, zur Überprüfung ausstehend oder bis zur Behebung blockiert. Legen Sie einen festen Termin fest, bis zu dem alle Produktionsserver im Katalog registriert sein müssen, und kommunizieren Sie klar, dass nicht katalogisierte Server nach diesem Datum am Gateway blockiert werden. Die Frist schafft die Dringlichkeit, die Teams zum Handeln bewegt.

Schritt 3: Das MCP-Gateway bereitstellen und SSO durchsetzen

Leiten Sie den gesamten MCP-Verkehr über das Gateway, bevor Sie Blockierungsrichtlinien durchsetzen. Beginnen Sie mit REQUEST_LOGGING_MODE auf ALWAYS gesetzt. Der gesamte Verkehr wird durchgeleitet, alle Aufrufe werden aufgezeichnet, noch nichts wird blockiert. Der Betrieb in diesem Modus für zwei bis vier Wochen liefert Ihnen eine Basislinie der realen Verkehrsmuster, bevor die Durchsetzung beginnt.

Integrieren Sie das Gateway mit Ihrem Unternehmens-IdP über Zugriff > Externe Authentifizierung > Identitätsanbieter in der TrueFoundry-Benutzeroberfläche. Für Okta mit dem Standard-Autorisierungsserver lautet die JWKS-URI https://your-org.okta.com/oauth2/v1/keys. Organisationen, die einen benutzerdefinierten Okta-Autorisierungsserver verwenden, sollten stattdessen https://your-org.okta.com/oauth2/{authServerId}/v1/keys verwenden. Für Azure AD ist es https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, wobei die Tenant ID und Client ID als Issuer und Audience konfiguriert sind. Vergewissern Sie sich, dass jeder Aufruf im Audit-Log eine spezifische Benutzer- oder Agentenidentität anzeigt, bevor Sie zur Durchsetzung übergehen. Geteilte Dienstkonto-Identitäten in den Logs bedeuten, dass die Identitätszuordnung unvollständig ist.

Schritt 4: Durchsetzung aktivieren und Benachrichtigungen konfigurieren

Nach der Basislinienperiode aktivieren Sie die Richtliniendurchsetzung: Blockieren Sie nicht katalogisierte MCP-Server, aktivieren Sie RBAC-Richtlinien und wenden Sie Ratenbegrenzungen an. Teilen Sie den Entwicklerteams das Durchsetzungsdatum mit ausreichend Vorlaufzeit mit, um legitime Tools schnell durch die Katalogregistrierung zu bringen.

Richten Sie Benachrichtigungen für die exportierten OpenTelemetry-Daten bei anomalen Mustern ein: ungewöhnliche Anrufvolumen von einer einzelnen Agentenidentität, Zugriff auf hochsensible Tools außerhalb der genehmigten Zeiten, Richtlinienverstöße von Identitäten, die keinen MCP-Zugriff haben sollten. Die Guardrail-Ergebnisse unter AI Gateway > Monitor > Request Traces liefern Ihnen die Details, die Sie benötigen, um Schwellenwerte im Laufe der Zeit anzupassen. Überprüfen Sie die Alarmregeln vierteljährlich, wenn Ihre MCP-Bereitstellung wächst.

MCP-Sicherheitsanforderungen für Unternehmen nach Branche

Drei Anforderungen treten in allen regulierten Umgebungen konsistent auf: zuordenbare Zugriffsaufzeichnungen, die mit verifizierten Identitäten verknüpft sind, Datenresidenzkontrollen, die sensible Daten innerhalb definierter Grenzen halten, und Anbieter-Risikodokumentation für die Governance-Infrastruktur selbst.

• Gesundheitswesen (HIPAA): Jeder MCP-Server, der geschützte Gesundheitsinformationen in Parametern oder Antworten empfangen kann, erfordert ein VPC-isoliertes Gateway. Tool-Aufrufe, die PHI betreffen, benötigen Logs, bei denen Patientenidentifikatoren durch Referenz-Tokens ersetzt werden, und der Zugriff muss über ein klinisches Identitätsmanagement bereitgestellt werden. Die selbst gehostete Bereitstellung von TrueFoundry auf AWS GovCloud unterstützt HIPAA-konforme Workloads. Innovaccer verarbeitet monatlich etwa 17 Millionen klinische KI-Inferenzanfragen vollständig innerhalb ihrer AWS GovCloud-Grenzen unter Verwendung von TrueFoundry, wobei OpenTelemetry Grafana-Dashboards speist und keine sensiblen Daten ihren Cloud-Perimeter verlassen.

• Finanzdienstleistungen (SOC2, FINRA): Die MCP-Governance-Infrastruktur fällt in den Geltungsbereich von SOC2 Typ II-Audits, wenn sie Finanzdaten verarbeitet oder Zugriff auf führende Systeme hat. Erforderliche Kontrollen umfassen Verschlüsselung während der Übertragung und im Ruhezustand, vierteljährliche Zugriffsüberprüfungen mit dokumentierten Nachweisen und Incident-Response-Verfahren, die MCP-spezifische Fehlerfälle abdecken. TrueFoundry besitzt die SOC2 Typ II-Zertifizierung und exportiert strukturierte MCP-Audit-Logs in dem Format, das Auditoren zur Erstellung von CC6-Kontrollnachweisen benötigen.

• Versicherungen und globale Unternehmen (DSGVO, Datenresidenz): DSGVO-pflichtige Organisationen müssen gemäß Artikel 30 ein Verzeichnis von Verarbeitungstätigkeiten führen, das KI-gestützte Verarbeitungen, einschließlich MCP-Tool-Aufrufe, abdeckt. Dieses Verzeichnis ist ein strukturiertes Compliance-Dokument, das Verarbeitungszwecke, Datenkategorien, Übermittlungen und Schutzmaßnahmen beschreibt. MCP-Gateway-Audit-Logs liefern die zugrunde liegenden Ereignisdaten, die dieses Verzeichnis speisen, aber das RoPA selbst muss von der Datenschutzfunktion der Organisation separat gepflegt werden. Gateway-Logs müssen auch ausreichende Metadaten erfassen, um Anfragen von betroffenen Personen zu unterstützen und grenzüberschreitende Übermittlungen zu dokumentieren, die durch Tool-Aufrufe erfolgen. Datenresidenzanforderungen können den MCP-Verkehr daran hindern, bestimmte geografische Regionen zu verlassen, was regionale Gateway-Bereitstellungen erforderlich macht.

Wie TrueFoundry die MCP-Governance für Unternehmen bereitstellt

TrueFoundrys MCP Gateway bietet alle vier Governance-Säulen von einer einzigen Steuerungsebene aus, die im eigenen Cloud-Konto des Kunden bereitgestellt wird. Plattformteams verwalten den gesamten Governance-Stack über eine einzige Schnittstelle, ohne individuelle MCP-Server-Implementierungen ändern zu müssen. Kein MCP-Traffic verlässt die Unternehmensgrenzen.

Unternehmen wie NVIDIA, Zscaler, Siemens Healthineers und Automation Anywhere nutzen TrueFoundry, um von Ad-hoc-MCP-Bereitstellungen zu kontrollierten, regulierten Umgebungen überzugehen. Für Unternehmen, die KI-Agenten-Workloads in großem Umfang betreiben, haben die richtliniengesteuerten Kostenkontrollen, Budgetlimits und der Caching-Layer von TrueFoundry zu erheblichen Reduzierungen der monatlichen Ausgaben für Inferenz und Tool-Aufrufe geführt. Kontaktieren Sie TrueFoundry für fallspezifische Zahlen, basierend auf Ihrem tatsächlichen Aufrufvolumen und Modellmix.

• Zentralisierter MCP-Katalog mit Prüfprozess: Die TrueFoundry-Steuerungsebene pflegt das maßgebliche Register genehmigter MCP-Server mit Metadaten, Genehmigungsstatus und Verbindungsparametern. Neue Server durchlaufen einen Prüfprozess, der eine Überprüfung der Tool-Beschreibung auf Vergiftungsrisiken umfasst, bevor sie an Entwickler-IDE-Konfigurationen verteilt werden. Die Funktion „Virtueller MCP-Server“ ermöglicht es Plattformteams, kuratierte Tool-Teilmengen aus mehreren registrierten Servern zusammenzustellen, wobei nur das offengelegt wird, was ein bestimmtes Team benötigt, ohne neue Infrastruktur bereitzustellen.

• OAuth2 und RBAC bei jedem Tool-Aufruf: Jeder MCP-Aufruf wird über OAuth2 mit der Unternehmensidentität des Aufrufenden authentifiziert. Das Gateway verarbeitet alle sechs ausgehenden Authentifizierungsmuster und verwaltet den gesamten Token-Lebenszyklus für Autorisierungscode-Flows, Client-Credentials-Flows und API-Schlüssel-Injektion. Am Gateway durchgesetzte RBAC-Richtlinien werden bei Aktualisierung sofort auf alle Clients angewendet, ohne dass eine erneute Serverbereitstellung erforderlich ist.

• Konfigurierbare Metadatenrichtlinien pro Aufruf: TrueFoundry wendet Datenmaskierung über PII-Erkennung und Regex-Schutzmechanismen, Ratenbegrenzungen pro Team, Kostenobergrenzen pro Agenten-Sitzung und Blockierungsregeln für eingeschränkte Tool-Kategorien über Cedar- oder OPA-Richtlinien an. Alles konfigurierbar in der Verwaltungsoberfläche. Keine Änderungen am MCP-Servercode erforderlich.

• Audit-Logs gestreamt an Ihr SIEM: Strukturierte JSON-Audit-Logs für jeden MCP-Aufruf werden über OpenTelemetry an Grafana, Datadog, Splunk oder jedes OTLP-kompatible Ziel exportiert. Bei selbst gehosteten Bereitstellungen werden Logs in Parquet-Format in Ihren eigenen AWS S3-, GCS- oder Azure Blob-Speicher geschrieben und sind über Spark, DuckDB oder Athena abfragbar. REQUEST_LOGGING_MODE: ALWAYS gewährleistet eine vollständige Erfassung für regulierte Umgebungen.

• VPC-isolierte Bereitstellung mit vier Optionen: Vollständig verwaltetes SaaS ohne Infrastruktur-Overhead; SaaS-Gateway mit kundeneigenem Datenspeicher; selbst gehostete Gateway-Ebene mit TrueFoundry-Steuerungsebene zu Infrastrukturkosten von ca. 600 $ pro Monat; vollständig selbst gehostete Steuerungsebene plus Gateway zu ca. 800 $ bis 1.000 $ pro Monat. Die letzten beiden Optionen stellen sicher, dass kein MCP-Aufruf-Traffic Ihre Perimeter verlässt, um die TrueFoundry-Infrastruktur zu erreichen.

‍