MCP ist keine Sicherheitsgrenze: So schützt du den Datenzugriff von KI-Agenten

MCP ist nicht tot. MCP ist aber auch nicht deine Sicherheitsgrenze. Der erste Satz korrigiert die zugespitzte Schlagzeile. Der zweite korrigiert den teureren Architekturfehler.

Das Model Context Protocol, nicht „Model Content Protocol“, standardisiert, wie eine KI-Anwendung Tools, Ressourcen und Prompts findet und aufruft. Das erleichtert Integrationen und Governance. Es beweist nicht, dass ein Aufrufer die Telefonnummer eines bestimmten Kunden lesen, eine Rechnung ändern oder ein Dokument exportieren darf. Kann ein codefähiger KI-Agent dasselbe System mit breiteren Credentials per Shell, SDK oder direkter API erreichen, ist das schmale MCP-Tool nur der bevorzugte Weg, nicht die Grenze.

Diese Unterscheidung ist wichtig, wenn du Agenten-Infrastruktur auswählst oder freigibst. Ein Protokoll kann sicheres Verhalten erleichtern. Unsicheres Verhalten zuverlässig verhindern kann nur ein Enforcement Point, den der Workload nicht umgehen kann. Die OAuth- und Multi-Tenant-Details findest du in unserer separaten Referenzarchitektur für Enterprise-MCP-Authorization. Hier klären wir die vorgelagerte Frage: Wo muss die Trust Boundary tatsächlich liegen?

Was ist die kurze Antwort?

MCP ist eine Schnittstellengrenze. Autorisierung ist eine Policy-Entscheidung. Deine Sicherheitsgrenze besteht aus den unvermeidbaren Enforcement Points zwischen einer Identität und jeder geschützten Aktion oder Datenressource.

Der Praxistest ist einfach: Kann der Agent dieselben Daten oder denselben Seiteneffekt über einen anderen Weg erreichen? Falls ja, ist der MCP-Server nicht die vollständige Grenze. Jeder alternative Pfad braucht gleich starke oder stärkere Kontrollen. Dazu zählen direkte APIs, Datenbankverbindungen, Browser-Sessions, lokale Dateien, Queues und Cloud-SDKs.

Soll MCP die Aktionen eines KI-Agenten begrenzen?

MCP kann die sichtbare Oberfläche eingrenzen. Das ist nicht dasselbe wie eine erzwungene Begrenzung. MCP-Tools haben Input-Schemas, und Clients können einem Agenten eine kleinere, auf die Aufgabe zugeschnittene Oberfläche anbieten als eine breite REST-API. Das aktuelle MCP-Schema kennt außerdem Annotationen wie readOnlyHint und destructiveHint. Die Spec bezeichnet diese Eigenschaften ausdrücklich als Hints. Ein Client darf daraus keine Sicherheitsentscheidung ableiten, wenn sie von einem nicht vertrauenswürdigen Server kommen.

Die HTTP-Authorization-Spec von MCP ergänzt wertvolle OAuth-Kontrollen. Resource Indicators sorgen dafür, dass ein Token für einen bestimmten MCP-Server bestimmt ist. Die Security Guidance verbietet Token-Passthrough zu Downstream-APIs. Diese Kontrollen beantworten: „Ist dieses Token für diesen Server ausgestellt?“ Sie beantworten noch nicht vollständig: „Darf dieses Subjekt für diesen Support-Fall das Feld contact_email von Kunde 42 sehen?“

Für die zweite Frage brauchst du Business- und Ressourcenkontext. Sie gehört in ein deterministisches Authorization-System, nicht in einen Prompt und nicht in das Urteil des Modells.

Kann ein codefähiger Agent MCP umgehen?

Ja, wenn seine Ausführungsumgebung einen anderen nutzbaren Pfad samt Credentials bereitstellt. Nein, wenn das umgebende System diese Pfade entfernt oder begrenzt.

Ein Agent, der Code schreiben kann, bekommt dadurch nicht automatisch Zugriff auf jede API. Er braucht weiterhin Netzwerkzugang, Credentials, ausführbare Tools und Berechtigungen. Genau hier greift die Aussage „MCP ist tot“ zu kurz. Codegenerierung verändert das Threat Model. Eine Sandbox, eine Egress-Allowlist, eine Workload Identity und Least-Privilege-Credentials können generierten Code außerhalb des freigegebenen Pfads wirkungslos machen.

Die richtige Schlussfolgerung lautet daher nicht „MCP ist nutzlos“. Sie lautet: Verwechsle eine bequeme Schnittstelle nie mit einer nicht umgehbaren Kontrolle. MCP bleibt wertvoll für typisierte Discovery, einheitliche Tool-Aufrufe, die Trennung bestimmter Credentials und Audit Hooks. Ein glaubwürdiger Enforcement Point wird es erst, wenn die Runtime nicht daran vorbeikommt und die Downstream-Ressource die Autorisierung trotzdem erneut prüft.

Wo sollte die Zugriffskontrolle für KI-Agenten liegen?

So nah wie praktikabel an der geschützten Ressource. Frühere Ebenen sollen das Risiko bereits reduzieren. „Data-Level Access Control“ ist kein einzelnes magisches Datenbank-Feature. Es bedeutet, dass die finale Entscheidung das konkrete Objekt, die Operation und die Datenklassifizierung umfasst und dass jeder Pfad zu diesem Objekt abgedeckt ist.

Dieses Schichtenmodell folgt etablierter Security-Praxis. Die Zero Trust Architecture des NIST rückt Ressourcen statt Netzwerkstandorte ins Zentrum. Die ABAC-Guidance des NIST bewertet Attribute von Subjekt, Objekt, Operation und Umgebung. Ein Agent ist eine nicht menschliche Entität, die in einem Kontext handelt. Bewahrst du diesen Kontext, funktioniert das bewährte Modell weiterhin.

Wie sieht Data-Level Access Control in einem echten Support-Fall aus?

Nimm das Beispiel aus dem viralen Argument:

retrieve_customer_by_email(email)

Ein schmaler Tool-Name klingt sicherer als ein allgemeiner GET /customers-Endpoint. Ausreichend ist er nicht. Der E-Mail-Parameter kann einen Kunden außerhalb des Mandanten bezeichnen. Das Tool kann Felder zurückgeben, die für die Aufgabe unnötig sind. Ein codefähiger Agent kann die zugrunde liegende API direkt aufrufen. Ein gemeinsames Service-Credential kann Admin-Rechte haben.

Eine belastbare Anfrage trägt einen Decision Envelope:

subject: user_184
actor: support_agent_7
purpose: resolve_ticket
action: customer.read
resource: customer_42
requested_fields: [name, plan, last_invoice_status]
tenant: acme_eu
ticket: ticket_912
environment: production

Die Durchsetzung läuft deterministisch:

1. Leite Tenant, Subjekt und Actor aus verifizierter Identität ab, nie aus modellgeschriebenen Argumenten.
2. Prüfe die Beziehung zum Ticket und die Berechtigung des Nutzers für dieses Kundenobjekt.
3. Erlaube nur die Felder, die für den Support-Zweck notwendig sind.
4. Wiederhole dieselbe Prüfung in API und Datenebene, auch wenn das MCP-Gateway den Tool Call bereits erlaubt hat.
5. Gib mit der Antwort eine Policy Decision ID für Audit und Widerrufsanalyse zurück.

Bei relationalen Daten kann Row-Level Security in PostgreSQL festlegen, welche Zeilen eine Datenbankrolle sehen oder ändern darf. Ist RLS aktiv und es gibt keine passende Policy, gilt Default Deny. Bei geteilten Dokumenten und verschachtelten Organisationen kann ein feingranulares Beziehungsmodell wie OpenFGA beantworten, ob dieser Nutzer oder delegierte Agent diese Aktion auf diesem Objekt ausführen darf. Das sind Beispiele, keine Kaufempfehlungen.

Macht Feldverschlüsselung die Daten selbst zur Grenze?

Verschlüsselung kann die Grenze stärken. Sie ersetzt keine Autorisierung.

Kann dieselbe überprivilegierte Agent Runtime beim Key Service jede E-Mail-Adresse entschlüsseln lassen, hat Ciphertext at Rest die effektive Berechtigung nicht verändert. Der Gewinn entsteht erst, wenn Key Release oder Re-Identifikation selbst an verifizierte Identität, Zweck, Objekt, Feld und Zeit gebunden ist und Klartext nur in der kleinsten vertrauenswürdigen Komponente existiert.

Nutze kryptografische Kontrollen passend zum Zweck:

• Envelope- oder Feldverschlüsselung: begrenzt, welche Services und Identitäten sensible Felder wiederherstellen können.
• Tokenisierung oder Pseudonymisierung: erlaubt stabilen Ersatzwerten in Workflows, ohne den Originalwert offenzulegen. Die Google-Cloud-Dokumentation beschreibt reversible und irreversible Varianten.
• Redaction und Masking: entfernen unnötige Daten, bevor sie das Modell erreichen.
• Kurzlebige, audience-gebundene Credentials: reduzieren Reichweite und Dauer eines Credential-Diebstahls.

Die praktische Regel lautet: zuerst autorisieren, dann minimieren, zuletzt entschlüsseln. Gib nicht einen breiten Datensatz frei und bitte das Modell anschließend, die verbotenen Felder zu ignorieren.

"Ein schmales MCP-Tool ist nützlich. Zur Grenze wird es erst, wenn der Agent es nicht umgehen kann und die geschützte Ressource dieselbe Identität und Policy unabhängig durchsetzt."

MCP- vs. API-Sicherheit: Was solltest du nutzen?

Meistens beides. MCP und APIs lösen unterschiedliche Teile des Stacks. MCP gibt Agent Clients einen standardisierten Contract für Discovery und Aufrufe. APIs bleiben hinter vielen MCP-Servern die dauerhafte Service-Schnittstelle. Keine der beiden Entscheidungen ersetzt Objekt-Autorisierung.

Den genauen OAuth-Flow, Audience-Validierung, Token Exchange und das Tenant-Isolation-Design findest du im MCP-Authorization-Architektur-Guide. Für die breitere Wahl zwischen Wissen, Connectivity und Verfahren nutze unseren Vergleich MCP vs. RAG vs. Agent Skills vs. Custom GPTs.

Was solltest du einen MCP- oder Agent-Plattform-Anbieter fragen?

Das kommerzielle Risiko hängt nicht davon ab, ob der Anbieter eine Folie mit „Enterprise MCP Gateway“ zeigt. Verlange Belege dafür, dass die behauptete Grenze Umgehungsversuchen standhält.

• Identity Propagation: Unterscheiden Logs Nutzer, Agent, Service und Downstream Actor auf jedem Hop?
• Alternative Pfade: Was hindert Shell-Code, Browser-Automation oder einen direkten API Client daran, breitere Credentials zu verwenden?
• Autorisierungsgranularität: Kann die Policy Tool, Argumente, Tenant, Objekt, Beziehung, Felder, Zweck und Risiko berücksichtigen?
• Fail-closed-Verhalten: Was passiert, wenn Policy Engine, Identity Provider oder Key Service nicht erreichbar sind?
• Credential-Design: Sind Tokens kurzlebig, audience-gebunden und werden sie statt Passthrough für Downstream-Audiences getauscht?
• Datenminimierung: Lassen sich sensible Felder vor der Modellinferenz maskieren, tokenisieren oder vollständig zurückhalten?
• Audit-Nachweis: Kann eine Decision ID Nutzerabsicht, Policy-Auswertung, Tool Call, Downstream-API und zurückgegebene Felder verbinden?
• Widerruf: Wie schnell verliert ein Nutzer, Agent, Tenant, Server oder eine Policy-Version den Zugriff?
• Adversarial Test: Demonstriert der Anbieter einen abgelehnten Cross-Tenant-Read und einen abgelehnten Direct-API-Bypass?

Lautet die Antwort „Der Prompt sagt dem Agenten, dass er das nicht tun darf“, gibt es keine Sicherheitsgrenze. Lautet sie „Das MCP-Tool ist read-only“, frage, welche Komponente diese Behauptung verifiziert. Das offizielle MCP-Schema warnt ausdrücklich: Tool-Annotationen sind Hinweise, keine vertrauenswürdigen Fakten.

Ist MCP tot?

Nein. Die bessere Schlussfolgerung ist weniger dramatisch und dafür nützlicher: MCP ist Infrastruktur, nicht Autorität. Ein Standardprotokoll kann Integrationskosten senken, Tools auffindbar machen, bestimmte Credentials vom Modell trennen und einen einheitlichen Inspektionspunkt schaffen. Das sind wertvolle Eigenschaften.

MCP scheitert, wenn Teams ihm eine Aufgabe geben, die es nicht vollständig beansprucht. Es rettet kein Admin-Token, keine unbeschränkte Shell, keine flache Multi-Tenant-Datenbank und keinen Service, der nur beim Login autorisiert. Die Lösung ist nicht, MCP zu entsorgen. Du musst Identität, Ausführung und Datenzugriff so gestalten, dass das Protokoll innerhalb einer echten Trust Boundary liegt.

Implementierungs-Checkliste

1. Inventarisiere jeden Pfad von der Agent Runtime zu sensiblen Daten und Seiteneffekten.
2. Entferne dauerhafte Admin-Credentials und isoliere die Ausführungsumgebung.
3. Propagiere die delegierte menschliche Identität und den Agent Actor getrennt.
4. Erzwinge Tool- und Argument-Policies vor der Ausführung.
5. Prüfe die Autorisierung auf dem konkreten Objekt oder der Zeile im Downstream erneut.
6. Minimiere Felder vor dem Modell und kontrolliere anschließend Entschlüsselung oder Re-Identifikation.
7. Nutze audience-gebundene, kurzlebige Tokens und tausche sie für Downstream-Audiences.
8. Logge eine Correlation ID und Policy Decision ID über die vollständige Aufrufkette.
9. Teste Direct-API-Bypass, Cross-Tenant-Read, ein verbotenes Feld und eine widerrufene Identität.

Primärquellen

• Model Context Protocol Authorization Specification, 2025-11-25
• Model Context Protocol Security Best Practices
• MCP-Schema-Referenz zu Tool-Annotationen
• RFC 8707, Resource Indicators for OAuth 2.0
• RFC 9700, Best Current Practice for OAuth 2.0 Security
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-162, Attribute Based Access Control
• PostgreSQL Row Security Policies
• OpenFGA: Fine-Grained Authorization
• Google Cloud Sensitive Data Protection: Pseudonymisierung
• AWS Security Blog: sichere Zugriffsmuster für KI-Agenten mit MCP