Jede MCP-Session ist eine Kette von Vertrauensentscheidungen, die kaum ein Team systematisch prüft. Ein Agent entdeckt einen Server, liest dessen Tool-Beschreibungen ein, hängt Credentials an, fügt Konversationskontext hinzu und beginnt Anfragen zu senden. Jeder Schritt in dieser Kette bringt eine eigene Risikokategorie mit. Microsofts CISO-Team und Microsoft Digital haben im Februar 2026 ihr internes Framework veröffentlicht, mit dem sie diese Kette absichern. Es liest sich weniger wie ein Whitepaper und mehr wie ein Betriebshandbuch. Was davon für andere Unternehmen brauchbar ist, steht hier.
Das Conversation-Graph-Problem
Die meisten MCP-Sicherheitsdiskussionen drehen sich um einzelne Schwachstellen: ein CVE hier, ein Tool-Poisoning-Angriff dort. Microsoft denkt das Problem anders. Sie behandeln jede MCP-Session als Conversation Graph, in dem jeder Knoten (Server-Entdeckung, Tool-Beschreibung, Credential-Anhang, Request-Ausführung) ein potenzieller Fehlerpunkt ist, der sich mit den anderen aufschaukelt.
Eine manipulierte Tool-Beschreibung betrifft nicht nur eine Anfrage. Sie beeinflusst jede nachfolgende Entscheidung des Agents in dieser Session. Ein Credential mit zu breitem Scope gefährdet nicht nur die aktuelle Operation, sondern öffnet laterale Bewegung über alle Server, mit denen der Agent danach kommuniziert. Das Conversation-Graph-Framing erzwingt, dass man Risiken über den gesamten Session-Lebenszyklus betrachtet, nicht nur bei einzelnen Tool-Aufrufen.
Deshalb ist Microsofts Ansatz in Schichten organisiert, nicht als Checkliste. Checklisten verpassen die Wechselwirkungen. Vier Schichten, angewendet auf jede Stufe des Conversation Graph, fangen Fehler auf, die kein einzelnes Kontrollsystem allein erkennen würde.
Microsofts Vier-Schichten-Verteidigung
Microsoft strukturiert die MCP-Sicherheit in vier Schichten, die jeweils eine andere Fehlerdomäne adressieren. Das ist kein theoretisches Modell, sondern bildet den tatsächlichen internen Einsatz für Microsoft 365 Copilot-Agents ab.
Schicht 1: Applikationen und Agents
Die Mensch-Maschine-Schnittstelle, an der Agents, Clients und Entscheidungslogik sitzen. Hauptfehlermodi: Tool Poisoning, stille Metadaten-Änderungen und fehlende Einwilligungsgates.
Microsofts Kontrollen: clientseitige Consent-Validierung vor jeder Schreiboperation, verifizierte Tool-Contracts bei Verbindungsaufbau, Per-Tool-Allowlists und „Erst fragen, dann schreiben" als UX-Standard. Dazu laufen Liveness-Checks, die Live-Tool-Metadaten gegen den genehmigten Contract abgleichen. Ändert sich eine Tool-Beschreibung nach der Freigabe, wird sie pausiert.
Genau hier setzen Tool-Poisoning-Angriffe an: Metadaten werden nach der initialen Prüfung manipuliert. Microsofts Liveness-Checks fangen exakt dieses Szenario ab.
Schicht 2: KI-Plattform
Model-Runtime, Orchestrierungslogik und alles zwischen Benutzerintention und Tool-Aufruf. Fehlermodi: Model-Supply-Chain-Drift und Prompt Injection aus Tool-Antworten.
Kontrollen: Versions-Tracking gekoppelt an Verhaltens-Telemetrie, Content-Safety-Shields zur Laufzeit (nicht nur beim Testen) und automatisierter Rollback bei erkanntem Verhaltensdrift. Wenn ein Modell-Update dazu führt, dass Agents Tools anders als erwartet auswählen, wird zurückgerollt, bevor die Änderung Produktion erreicht.
Schicht 3: Daten
Dateien, Geschäftsdaten und Secrets, die während einer Konversation zugänglich sind. Die zwei großen Fehlermodi: Context Oversharing (unnötige sensible Daten an Drittanbieter-Server senden) und über-berechtigte Credentials, die laterale Bewegung ermöglichen.
Kontrollen: Context Trimming auf aufgabenbezogene Informationen, Blockierung der Übertragung vollständiger Transkripte an externe Server, kurzlebige Least-Privilege-Tokens mit korrekten Audience-Claims und Token-Proof-of-Possession-Binding. Das Prinzip: Der Agent sieht nur, was er für die aktuelle Aufgabe braucht, hält Credentials nur für die nötige Dauer, und diese funktionieren ausschließlich gegen den spezifischen Service, für den sie ausgestellt wurden.
Für Unternehmen im DACH-Raum ist das besonders relevant: Die DSGVO verlangt Datenminimierung. Context Oversharing bei MCP-Sessions, bei denen personenbezogene Daten an Drittserver fließen, ist ein direktes Compliance-Risiko.
Schicht 4: Infrastruktur
Compute, Netzwerk und Laufzeitumgebungen für MCP-Server und Clients. Fehlermodi: lokale Entwickler-Server mit übermäßigem Zugriff, Cloud-Endpunkte ohne Gateway, fehlendes TLS, keine Rate Limits.
Kontrollen: Alle Remote-MCP-Server müssen hinter einem API-Gateway sitzen. Dieses Gateway erzwingt TLS/mTLS, authentifiziert Anfragen, wendet Rate Limits an, loggt alles und beschränkt Egress auf genehmigte Ziele via Private Endpoints und Firewall-Regeln. Kein MCP-Server kommuniziert direkt mit dem Internet.
Drei Säulen: Architektur, Vetting und Inventar
Die vier Schichten beschreiben, was zu schützen ist. Die drei Säulen beschreiben, wie.
Säule 1: Secure-by-Default-Architektur
Jeder MCP-Server läuft über ein zentralisiertes API-Gateway. Nicht „sollte laufen". Läuft. Das Gateway ist der einzige Durchsetzungspunkt für Authentifizierung, Autorisierung, Rate Limiting, Logging und Egress-Kontrolle. Das erzeugt einen einzigen Engpass, an dem man Kontrollen anwenden und im Notfall Kill Switches umlegen kann.
Die Defaults sind entscheidend. TLS ist Pflicht. Tokens sind kurzlebig. Tool-Allowlists sind aktiv. Wer von einem sicheren Default abweichen will, braucht eine explizite Ausnahme mit dokumentiertem Verantwortlichen. Das kehrt das typische Muster um, bei dem Entwickler permissiv starten und später nachschärfen.
Säule 2: Gestuftes Vetting
Kein MCP-Server erreicht Produktion ohne einen gestuften Zertifizierungsprozess. Er beginnt mit einer Pflicht-Metadaten-Deklaration: Tools, Datenkategorien, Authentifizierungsmethoden, Runtime-Umgebung, On-Call-Kontakte. Dann folgen statische Prüfungen (Manifest-Verifizierung, SBOM-Vorhandensein, Erkennung eingebetteter Credentials), dynamische Tests (Prompt-Injection-Probing, Consent-Gating-Validierung für Operationen mit Seiteneffekten) und Resilienz-Validierung (Health Checks, Pinned-Host-Verifizierung, Container-Isolationstests).
Die Veröffentlichung ist an Security-, Privacy- und Responsible-AI-Reviews gebunden. Drei separate Teams geben ihr Okay. Das ist aufwändig, und genau das ist der Punkt: Die Kosten des Vettings fallen einmal pro Server an, während die Kosten eines Sicherheitsvorfalls sich über jede Agent-Session potenzieren.
Säule 3: Lebendiges Inventar
Microsoft pflegt ein einzelnes Registry für alle MCP-Server mit Pflicht-Metadaten pro Eintrag: Verantwortlicher, Exposure Score, Last-Seen-Timestamp, Review-Historie. Das Registry ist keine statische Tabelle. Es bezieht Telemetrie aus Endpunkten, Repos, CI-Pipelines, IDEs, Gateways und Low-Code-Umgebungen.
Erkennt das System einen MCP-Server, der nicht im Registry steht, erzeugt es automatisch einen Registrierungs-Stub und blockiert direkte Aufrufe, bis das Vetting abgeschlossen ist. So verhindert man Shadow-MCP: Server, die einzelne Entwickler oder Teams ohne Governance-Prozess aufsetzen.
Das Registry überwacht außerdem Drift. Ändern sich die Tool-Metadaten eines Servers nach der Genehmigung, werden risikoreiche Aktionen pausiert und zur erneuten Prüfung weitergeleitet, dann nach Freigabe automatisch fortgesetzt.
Governance im Entwicklerworkflow
Ein Muster aus Microsofts Ansatz, das andere Unternehmen sofort übernehmen können: Governance unterscheidet sich nach Entwicklungsoberfläche.
Low-Code-Oberflächen (Copilot Studio und ähnliche Tools) sind standardmäßig auf geprüfte First-Party-MCP-Server beschränkt. Maker können keine Verbindung zu beliebigen Drittanbieter-Servern herstellen. Das ist der richtige Kompromiss für Citizen Developer, die die Sicherheitsimplikationen einer MCP-Verbindung möglicherweise nicht einschätzen können.
Pro-Code-Workflows (VS Code, eigene Agent-Umgebungen) erlauben breiteren Connector-Zugriff, erfordern aber explizite Reviews, Service Ownership, Security- und Privacy-Assessments, Responsible-AI-Freigaben und Consent-Gating für Aktionen mit hohem Impact.
Die genehmigten Server leben in einem einzigen Katalog mit dokumentierten Verantwortlichen, Scopes und Datengrenzen. Runtime-Metadatenvergleiche pausieren riskante Aktionen, wenn das Verhalten eines Tools von seiner genehmigten Spezifikation abweicht.
Dieses Zwei-Stufen-Modell löst ein Problem, das die meisten MCP-Governance-Frameworks ignorieren: Man kann nicht die gleiche Reibung auf einen Citizen Developer anwenden, der eine Copilot-Action baut, und auf einen Platform Engineer, der eine Custom-Agent-Pipeline entwickelt. Die Kontrollen müssen zum Risikolevel passen, also zur Fähigkeit des Entwicklers, dieses Risiko einzuschätzen.
Observe, Detect, Respond: MCP als Live-Service
Microsofts Framework hört nicht beim Deployment auf. Das Betriebsmodell behandelt MCP wie jeden anderen kritischen Backend-Service, ergänzt um KI-spezifisches Monitoring.
Observe: Durchgängiges Tool-Call-Tracing via Correlation IDs, die Anfragen von Client über Gateway zum Server und zurück verfolgen. Einheitliche Log-Schemas erfassen Prompts, Tool-Auswahl, Auth-Entscheidungen und Ressourcenzugriffe. Metriken werden um Safety Signals angereichert: unerwartete Egress-Muster, nicht genehmigte Schreiboperationen.
Detect: Erkennung ungewöhnlicher Tool-Auswahlmuster, Spitzen bei Schreiboperationen und Kontextgrößen, die nicht zur Aufgabenstellung passen. Live-Tool-Metadaten werden bei Verbindungsaufbau gegen den genehmigten Snapshot verglichen. Automatisches Pausieren bei erkanntem Drift begrenzt den Blast Radius, bevor ein Mensch untersucht.
Respond: Abgestufte Antworten statt binärem Erlauben/Verbieten. Destruktive Writes blockieren, aber Reads erlauben. Laute Clients drosseln. Tokens selektiv widerrufen. Kill Switches auf Client- und Gateway-Ebene ermöglichen schnelle Eindämmung ohne vollständigen Ausfall.
Die Zukunftsrichtung ist Policy-as-Code: Allowlists, Consent-Regeln und Egress-Grenzen versioniert in der Quellcodeverwaltung und testbar in CI. Für den EU AI Act, der ab August 2026 durchgesetzt wird, ist das besonders relevant: Nachweisbare, versionierte Sicherheitsrichtlinien sind genau das, was Aufsichtsbehörden bei Hochrisiko-KI-Systemen sehen wollen.
Häufig gestellte Fragen
Was ist MCP-Sicherheits-Governance?
MCP-Sicherheits-Governance umfasst die Richtlinien, Kontrollen und Prozesse, mit denen Unternehmen MCP-Verbindungen zwischen KI-Agents und externen Tools absichern. Sie deckt Authentifizierung, Autorisierung, Audit-Logging, Server-Vetting und Runtime-Monitoring über den gesamten MCP-Konversationslebenszyklus ab.
Wie sichert Microsoft MCP intern ab?
Microsoft nutzt ein Vier-Schichten-Verteidigungsmodell (Applikationen, KI-Plattform, Daten, Infrastruktur) kombiniert mit drei Governance-Säulen: Secure-by-Default-Architektur mit API-Gateway-Pflicht, gestuftes Vetting mit Security/Privacy/Responsible-AI-Reviews und ein lebendiges Registry, das nicht registrierte Server automatisch erkennt und Operationen pausiert, wenn Tool-Metadaten vom genehmigten Stand abweichen.
Welche Mindestkontrollen braucht ein Unternehmen für MCP?
Enterprise-MCP-Deployments erfordern mindestens: OAuth 2.0-Authentifizierung mit Credentials außerhalb des KI-Kontexts, RBAC- und ABAC-Autorisierung pro Operation, attributbasiertes Audit-Logging, Pfad- und Scope-Kontrollen, Rate Limiting und Sensitivitätslabel-Auswertung. Microsoft ergänzt TLS-Pflicht, Egress-Pinning und Per-Tool-Allowlists als Baseline.
Was ist ein MCP Conversation Graph?
Ein MCP Conversation Graph ist die Kette von Vertrauensentscheidungen in jeder MCP-Session: Ein Agent entdeckt einen Server, liest Tool-Beschreibungen ein, hängt Credentials an, fügt Kontext hinzu und sendet Anfragen. Jeder Schritt bringt Risiken mit, die sich mit den nachfolgenden Schritten potenzieren. Deshalb evaluiert Microsoft die Sicherheit über vier Schichten statt nur bei einzelnen Tool-Aufrufen.
Warum ist MCP-Governance für die DSGVO-Compliance relevant?
MCP-Sessions können personenbezogene Daten an Drittanbieter-Server übertragen (Context Oversharing), was gegen das DSGVO-Prinzip der Datenminimierung verstößt. Ein MCP-Governance-Framework mit Context Trimming, Least-Privilege-Tokens und Audit-Logging stellt sicher, dass nur aufgabenbezogene Daten verarbeitet werden und jeder Datenzugriff nachvollziehbar dokumentiert ist.