MCP by Default Hold

mcpsecuritygovernanceagent-identitytool-boundariesprompt-injectioncredential-exposureprotocol-governanceagentic-security

Überblick

MCP by default ist das Anti-Pattern, Tools und Daten einfach deshalb über das Model Context Protocol offenzulegen, weil ein Agent MCP konsumieren kann – selbst wenn ein engerer CLI-Befehl, eine interne API, ein Read-only-Export, ein Batch-Job, ein Webhook oder ein menschlicher Freigabe-Workflow sicherer und leichter zu steuern wäre. MCP selbst ist keine spekulative Infrastruktur mehr: Im Dezember 2025 wechselte es zu einer herstellerneutralen Foundation-Governance, wird von den großen Modellanbietern übernommen und unterliegt inzwischen der sicherheitstechnischen Prüfung, die mit der Rolle als Standardweg einhergeht, über den Agenten auf reale Systeme zugreifen (MCP security landscape). Die Spezifikation vom 28.07.2026 ging noch weiter und ersetzte den zustandsbehafteten Handshake und die Session auf Protokollebene durch einen zustandslosen Kern, header-basiertes Routing, cachebare List-Ergebnisse, gehärtete Autorisierung und Tasks (MCP 2026-07-28 specification).

Der Hold ist nicht mehr generische Protokoll-Vorsicht. Er bezieht sich konkret auf das Deployment von MCP ohne Identität, Governance und Kontrollen für Tool-Grenzen. Die Maintainer haben bewusst entschieden, dass das Protokoll Sicherheit nicht für einen erzwingt, und die Änderungen vom 28. Juli bedeuten, dass die Session nicht mehr die Kontrolleinheit ist, wodurch die Durchsetzung auf die Request-Ebene und den Endpunkt verschoben wird (VentureBeat on the new spec). OWASP kartiert Risiken über LLM-Anwendungen, agentische Systeme und MCP-Server, während die Spezifikation bewusst nichts davon erzwingt, sodass Unternehmen die Durchsetzungsschicht selbst bauen müssen: ein Inventar, das ständigen Wandel überlebt, eine Identitäts-Lineage vom Menschen bis zum Tool, bei jedem Call geprüfte Autorisierung und eine Audit-Trail, die rekonstruieren kann, was passiert ist (OWASP MCP risk mapping).

Das konkrete Schadensmuster ist inzwischen in CVE-Einträgen dokumentiert, nicht nur in Forschung. Bei CVE-2026-75130 ließ nicht bereinigter, über eine Custom-AI-Instructions-Funktion via MCP-Server ausgelieferter Inhalt Angreifer Anweisungen vergiften, Credentials aus Environment-Dateien an einen von Angreifern kontrollierten Dienst exfiltrieren und destruktive Dateilöschungen durchführen, während der Agent eine routinemäßige Anfrage nach Bibliotheksdokumentation bearbeitete (CVE-2026-75130). MCP bleibt eine legitime Integrationswahl dort, wo wiederverwendbarer Agenten-Tool-Zugriff die Last von Identität, Governance und Lifecycle-Management wert ist. Als architektonischer Standard steht es auf Hold.

Adoptionssignale

  • Die Adoption ist breit und beschleunigt sich weiter: Tier-1-SDKs verzeichnen fast eine halbe Milliarde Downloads pro Monat, wobei TypeScript und Python jeweils die Marke von einer Milliarde Gesamt-Downloads überschritten haben (MCP 2026-07-28 specification).
  • Der Produktionseinsatz ist real, aber enger gefasst als die Schlagzeilen-Zahlen vermuten lassen. Die belastbarste Umfragequelle zeigt 41 Prozent der Software-Organisationen im begrenzten oder breiten Produktionseinsatz mit MCP-Servern und ersetzt eine frühere, unbelegte Angabe von 78 Prozent (MCP adoption statistics), andere Tracker setzen den Produktionseinsatz bei rund 45 Prozent an (MCP adoption statistics 2026).
  • Default-by-Policy wird explizit: 67 Prozent der befragten CTOs nannten MCP ihren Default-Integrationsstandard für die nächsten 12 Monate, obwohl weniger als die Hälfte der Produktions-Deployments geschäftskritische Kundendaten berührt (CTO survey data).
  • Governance, nicht Funktionsumfang, ist der Flaschenhals. Nur 11 bis 14 Prozent der Enterprise-Pilotprojekte erreichen die Produktion, wobei Identitätsmanagement, Auditierbarkeit und Vendor-Lock-in als Blocker genannt werden (Enterprise MCP Guide 2026).
  • Compliance-Frameworks benennen MCP inzwischen direkt. Das AIUC-1-Release Q2 2026, wirksam ab dem 15. April 2026, änderte 14 Anforderungen und fügte 23 Kontrollen hinzu, mit MCP- und A2A-Protokollsicherheit, Agenten-Identitäts- und Zugriffsmanagement sowie Drittparteirisiko-Monitoring als den drei Schwerpunkten, einschließlich verpflichtender Kontrollen für die Authentifizierung von MCP- und A2A-Protokollen (AIUC-1 Q2 refresh).
  • Standardisierungsgremien haben Implementierungs-Baselines veröffentlicht: OWASP GenAI veröffentlichte einen praktischen Leitfaden zur sicheren MCP-Serverentwicklung (OWASP GenAI MCP baseline), OWASP unterhält ein MCP-Governance- und Risiko-Framework (OWASP MCP Governance and Risk Project), und die NSA veröffentlichte Design-Überlegungen, die davor warnen, dass MCP mit einem flexiblen, unterspezifizierten Design ausgeliefert wurde (NSA MCP security design considerations).
  • Das Ökosystem hinkt seiner eigenen Spezifikation hinterher. Eine Black-Box-Prüfung jedes Remote-Servers in der offiziellen Registry fand nur 1 von 4.356 erreichbaren Servern bereit für die Änderungen vom 28.07.2026 (MCP spec readiness probe).

Risiken

  • Das Protokoll erzwingt Sicherheit nicht, per Design. MCP definiert, wie Hosts, Clients und Server kommunizieren und wie unterstützte HTTP-Deployments autorisieren, aber Protokollkonformität allein macht ein Deployment nicht sicher (MCP security), und die ursprüngliche Spezifikation wurde ohne verpflichtendes Authentifizierungs-Framework unter einem impliziten Vertrauensmodell ausgeliefert, das davon ausging, dass Server gutartig seien (MCP security risks and best practices).
  • Agenten-Identität ist die fehlende Kontrollebene. Die MCP-Spezifikation stellt nur ein minimales Autorisierungsmodell bereit und lässt Anleitung zur Integration von Enterprise-Identitäts- und Zugriffskontrollsystemen vermissen (enterprise identity integration for MCP), sodass Unternehmen selbst eine Identitäts-Lineage vom Menschen bis zum Tool aufbauen und die Autorisierung bei jedem Call selbst prüfen müssen (OWASP MCP risk mapping).
  • Eingeschleuste Prompts werden zu gestohlenen Credentials. Vergiftete Anweisungen, ausgeliefert über einen MCP-Server, exfiltrierten Environment-Datei-Credentials und löschten Dateien während einer gewöhnlichen Agenten-Anfrage bei CVE-2026-75130, klassifiziert als unsachgemäße Neutralisierung von Eingaben, die für LLM-Prompting verwendet werden (CVE-2026-75130); die Spezifikationsänderungen vom 28. Juli verschieben, wo sich diese Risiken potenzieren, da die Session nicht mehr die Kontrolleinheit ist (VentureBeat on the new spec).
  • Unauthentifizierte Exposition ist am Rand weiterhin die Norm. Rund vier von zehn internetzugänglichen MCP-Servern laufen ohne jede Authentifizierung (MCP adoption statistics 2026).
  • Tool-Oberflächen multiplizieren den Explosionsradius. Unit 42 maß eine Angriffserfolgsrate von 78,3 Prozent, wenn fünf MCP-Server mit einem einzigen KI-Agenten verbunden waren, und im Januar und Februar 2026 wurden mehr als 30 CVEs gegen MCP-Server, -Clients und -Infrastruktur gemeldet (OWASP MCP Top 10).
  • Das Interaktionsmuster kehrt vertraute Annahmen um. MCP erwartet oft, dass Server für verbundene Clients Abfragen durchführen und teilweise Aktionen ausführen – eine Umkehrung, die sicheren Einsatz in einem unterspezifizierten Design ambig macht (NSA MCP security design considerations).
  • Agenten-Builder-Plattformen sind ein aktives Ziel. CVE-2025-59528, eine Code-Injection-Schwachstelle mit CVSS 10.0 im Agenten-Builder Flowise, ermöglichte Command Execution und uneingeschränkten Dateisystemzugriff bei 12.000 bis 15.000 internetexponierten Instanzen und war die dritte ausgenutzte Flowise-Schwachstelle innerhalb von zwölf Monaten (Flowise CVSS 10.0 RCE).
  • Bestehende KI-Governance-Frameworks decken dies noch nicht ab. MCP ersetzt statische, entwicklergesteuerte API-Integrationen durch dynamische, nutzergesteuerte Agentensysteme und erzeugt damit Bedrohungen, die Frameworks wie NIST AI RMF und ISO/IEC 42001 nicht im Detail adressieren (securing MCP).
  • Upgrade-Drift erzeugt eine Sicherheitslandschaft mit gemischten Ständen. Da fast keine registrierten Remote-Server bereit für die Spezifikation vom 28.07.2026 sind, werden Organisationen für einige Zeit alte und neue Autorisierungs- und Routing-Modelle parallel betreiben (MCP spec readiness probe).

Vorteile & Nachteile

Vorteile

  • MCP ist inzwischen tatsächlich gemeinsam genutzte Infrastruktur und nicht mehr das Integrationsformat eines einzelnen Anbieters: Im Dezember 2025 wechselte es zu einer herstellerneutralen Foundation-Governance und wird von jedem großen Modellanbieter unterstützt, sodass ein gut gebauter Server viele Agenten-Clients bedienen kann statt nur einen.
  • Die Spezifikation vom 28.07.2026 machte MCP deutlich besser für den Einsatz im Enterprise-Maßstab geeignet: Sie ersetzte den zustandsbehafteten Handshake und die Session auf Protokollebene durch einen zustandslosen Request/Response-Kern, header-basiertes Routing, cachebare List-Ergebnisse und eine gehärtete Autorisierung, wodurch die Session-Pinning-Probleme entfallen, die das Cloud-native Skalieren bislang erschwerten.
  • Das Governance-Material hat inzwischen aufgeholt, sodass ein disziplinierter MCP-Rollout nicht mehr von Grund auf neu erfunden werden muss: OWASPs MCP Top 10, dessen Leitfaden zur sicheren Entwicklung von MCP-Servern und Governance-Framework, die NSA-Design-Überlegungen sowie AIUC-1s dedizierte Kontrollen für MCP/A2A und Agenten-Identität stehen als Prüfungsgrundlage zur Verfügung.

Nachteile

  • Das Deployment von MCP ohne Identitäts- und Autorisierungsschicht ist inzwischen das dominierende Fehlermuster: Die Spezifikation erzwingt bewusst keine Sicherheit, ihr Autorisierungsmodell ist minimal und schweigt zur Integration von Enterprise-SSO, und rund vier von zehn internetzugänglichen MCP-Servern laufen weiterhin völlig ohne Authentifizierung.
  • Eingeschleuste Prompts werden direkt zum Credential-Verlust, sobald Tool-Grenzen zu locker sind, wie bei CVE-2026-75130, wo vergiftete benutzerdefinierte Anweisungen über den Context7-MCP-Server Credentials aus Environment-Dateien exfiltrierten und bei einer routinemäßigen Dokumentationsanfrage Dateien löschten.
  • Tool-Oberflächen summieren sich nicht additiv, sondern potenzieren sich: Unit 42 maß eine Angriffserfolgsrate von 78,3 Prozent, wenn fünf MCP-Server mit einem einzigen Agenten verbunden waren, und allein im Januar und Februar 2026 wurden mehr als 30 CVEs gegen MCP-Server, -Clients und -Infrastruktur gemeldet.

Empfehlung

MCP-First-Architekturentscheidungen zurückstellen, bis Identität, Autorisierung und Tool-Grenzen etabliert sind, bevor der erste Server ausgeliefert wird. Mit der kleinstmöglichen Schnittstelle starten, die funktioniert: Ein Read-only-Export, ein eingeschränkter API-Endpunkt, ein CLI-Befehl, ein geplanter Batch-Job oder ein durch Freigabe abgesicherter Workflow ist in der Regel leichter abzusichern und zu beobachten als ein universeller MCP-Server. Fällt die Entscheidung dennoch auf MCP, sollte es als sicherheitstechnischer Übergang behandelt werden statt als Integrationskomfort – die Durchsetzung auf die Request-Ebene verlagern und Kontrollen jetzt am Endpunkt ansetzen, da die Session nicht mehr die Kontrolleinheit ist (VentureBeat on the new spec).

Die Durchsetzungsschicht selbst aufbauen, die das Protokoll bewusst nicht bereitstellt: ein Server-Inventar, das ständigen Wandel überlebt, eine Identitäts-Lineage vom menschlichen Principal über den Agenten bis zum Tool-Call, bei jedem Call geprüfte Autorisierung und eine Audit-Trail, die rekonstruieren kann, was passiert ist (OWASP MCP risk mapping). MCP-Server in bestehende Enterprise-Identitäts- und Zugriffskontrollen integrieren, statt sich auf das minimale Autorisierungsmodell der Spezifikation zu verlassen (enterprise identity integration for MCP), und Kontrollen gegen den OWASP-Leitfaden zur sicheren MCP-Serverentwicklung abgleichen (OWASP GenAI MCP baseline), das OWASP-MCP-Governance-Framework (OWASP MCP Governance and Risk Project), die OWASP MCP Top 10 (OWASP MCP Top 10), die NSA-Design-Überlegungen (NSA MCP security design considerations) und, wo für Kunden relevant, die AIUC-1-Kontrollen für MCP/A2A-Authentifizierung und Agenten-Identität (AIUC-1 Q2 refresh).

Praktisch bedeutet das: Read-only-Tools zuerst bevorzugen und Schreibaktionen hinter expliziter Freigabe absichern; die Anzahl der an einen Agenten angebundenen Server klein halten, angesichts der gemessenen Erfolgsrate, wenn fünf Server sich einen Agenten teilen (OWASP MCP Top 10); niemals einen Server ohne Authentifizierung ins Internet exponieren (MCP adoption statistics 2026); jedes Tool, das lokale Dateien, Environment-Variablen oder Agenten-Anweisungen liest, nach CVE-2026-75130 als Credential-Exposure-Pfad behandeln (CVE-2026-75130); Agenten-Builder-Plattformen bei Schwachstellen maximaler Schwere als P0 patchen (Flowise CVSS 10.0 RCE); und die Migration auf die Spezifikation vom 28.07.2026 angesichts der wenigen bereiten Server bewusst planen (MCP spec readiness probe). Den Hold erst aufheben, wenn MCP eine gesteuerte Plattform-Fähigkeit mit benannten Verantwortlichen ist, nicht ein Reflex, nur weil Agenten es unterstützen.

Quellen

Überblick

MCP by Default ist das Anti-Pattern, Tools und Daten über das Model Context Protocol bereitzustellen, nur weil ein Agent MCP konsumieren kann, obwohl ein engerer CLI-Befehl, interne API, read-only Data Export, Batch Job, Webhook oder Human-Approval-Workflow sicherer wäre. MCP existiert mit gutem Grund: Anthropic führte es als offenen Standard ein, um AI-Assistenten mit Systemen zu verbinden, in denen Daten leben, und fragmentierte Integrationen durch ein Protokoll für Datenquellen und AI-Tools zu ersetzen (Anthropic MCP announcement).

Die Gefahr liegt darin, Integrationsbequemlichkeit zur Default-Architektur zu machen. MCP-Server können sensible Resources, ausführbare Tools, lokale Commands, OAuth-Flows und Third-Party-APIs modellvermittelten Workflows exponieren. Offizielle MCP-Security-Guidance deckt Risiken wie Confused Deputy, Token Passthrough, SSRF, Session Hijacking, lokale Server-Command-Ausführung, Transport-Restriktionen und Least-Privilege-Scope-Design ab (MCP security best practices). Microsoft nennt MCP-spezifische Prompt-Injection- und Tool-Poisoning-Risiken, bei denen bösartiger externer Content oder Tool-Metadaten ein AI-System zu unbeabsichtigten Tool Calls oder Data Exfiltration manipulieren (Microsoft MCP indirect injection guidance).

MCP by Default steht auf Hold, weil MCP eine explizite Integrationsentscheidung sein sollte, kein Reflex. MCP nutzen, wo wiederverwendbare Agent-Tool-Integration den zusätzlichen Security- und Lifecycle-Aufwand rechtfertigt. Nicht als erste Antwort auf jedes Daten-, Automations- oder Internal-Tool-Exposure-Problem.

Adoptionssignale

  • MCP hat starkes Ökosystem-Momentum, weil es ein häufiges Integrationsproblem adressiert: AI-Assistenten sind isoliert von Datenquellen, und jede neue Quelle erforderte sonst Custom Implementation (Anthropic MCP announcement).
  • Anthropic positionierte MCP als offenen Standard für sichere, bidirektionale Verbindungen zwischen Datenquellen und AI-powered Tools, mit SDKs, Claude Desktop Support und frühen Prebuilt Servern für Systeme wie Google Drive, Slack, GitHub, Git, Postgres und Puppeteer (Anthropic MCP announcement).
  • Offizielle MCP-Dokumentation behandelt Authorization als optional im Protokoll, aber stark empfohlen bei user-spezifischen Daten, administrativen Aktionen, auditierbaren Operationen, enterprise-kontrollierten Resources, Rate Limits oder consent-geschützten APIs (MCP authorization guidance).
  • Security Guidance ist zu detaillierten Anforderungen und Mitigations gereift, u. a. per-client Consent, exakte Redirect-URI-Validierung, OAuth-State-Validierung, Token-Audience-Validierung, HTTPS, sichere Token-Speicherung und progressive Least-Privilege-Scopes (MCP security best practices, MCP authorization guidance).
  • Security Researcher und Vendors dokumentieren MCP-spezifische Risikomuster wie Prompt Injection, Tool Poisoning, mutable Tool Descriptions, Rug-Pull-Angriffe, Cross-Server Tool Shadowing und gefährliche Kombinationen aus privaten Daten, untrusted Instructions und Exfiltration Tools (Microsoft MCP indirect injection guidance, Simon Willison MCP analysis).
  • Die offizielle Best-Practices-Seite nennt lokale MCP-Server explizit als Sonderfall, weil sie Commands auf dem Rechner des Users ausführen können und für andere lokale Prozesse erreichbar sein können; Consent, exakte Command-Anzeige, Sandboxing und eingeschränkte Transports wie stdio oder IPC sind nötig (MCP security best practices).

Risiken

  • Tool-Flächen vergrößern den Blast Radius. MCP-Server stellen Tools und Resources bereit, die Modelle aufrufen können; breite Tool-Kataloge standardmäßig schaffen mehr Pfade für bösartige Prompts, kompromittierte Tool-Metadaten, verwirrte Nutzer oder falsch begrenzte Agents.
  • Prompt Injection wird operatives Risiko. Microsoft beschreibt indirekte Prompt Injection als bösartige Anweisungen in externem Content wie Dokumenten, Webseiten und E-Mails, die zu unbeabsichtigten Aktionen inklusive Data Exfiltration, schädlicher Ausgabe und Manipulation späterer Interaktionen führen (Microsoft MCP indirect injection guidance).
  • Tool Poisoning und Rug Pulls sind schwer sichtbar. Tool-Metadaten helfen LLMs bei Tool-Auswahl; bösartige Anweisungen in Tool Descriptions können Modellverhalten manipulieren, während sie für Nutzer unsichtbar bleiben; Tool Descriptions können nach Approval in einem Rug-Pull-Muster wechseln (Microsoft MCP indirect injection guidance, Simon Willison MCP analysis).
  • Authorization ist nicht trivial. Offizielle MCP-Guidance empfiehlt Authorization bei User Data, administrativen Aktionen, Audit-Anforderungen, Enterprise Access Controls, consent-geschützten APIs, Rate Limits oder Usage Tracking; kurzlebige Tokens, Token-Validierung, HTTPS, Least-Privilege-Scopes, sichere Token-Speicherung und Session-ID-Härtung (MCP authorization guidance).
  • Confused Deputy und Token Passthrough sind real. MCP-Proxy-Server müssen per-client Consent implementieren und Tokens vermeiden, die nicht explizit für den MCP-Server ausgestellt wurden; Token Passthrough ist Anti-Pattern und in der Authorization Specification explizit verboten (MCP security best practices).
  • SSRF kann über OAuth-Metadata-Discovery eintreten. Auf Servern deployte MCP-Clients müssen SSRF beim Abruf OAuth-bezogener URLs bedenken, inklusive interner IPs, Cloud-Metadata-Endpoints, Localhost-Services, DNS Rebinding und Redirect Chains (MCP security best practices).
  • Lokale MCP-Server-Installation kann beliebige Commands ausführen. Unterstützt ein Client One-Click-Lokalkonfiguration, verlangt offizielle Guidance die exakte Command-Anzeige, klare Kennzeichnung des Code-Execution-Risikos, explizite Freigabe und Abbruchmöglichkeit vor Ausführung (MCP security best practices).
  • Human Approval muss bedeutsam sein. Simon Willison argumentiert, MCP-Clients sollten Human-in-the-Loop-Tool-Denial praktisch als Pflicht behandeln, Tool Descriptions und Tool Invocations klar zeigen und Nutzer warnen, wenn sich Tool Descriptions ändern (Simon Willison MCP analysis).
  • Supply-Chain-Controls gelten für AI-Integrationen. Microsoft empfiehlt, alle AI-Komponenten vor Integration zu verifizieren, inklusive Modelle und Context Provider, sichere Deployment-Pipelines zu pflegen und kontinuierliches Application- und Security-Monitoring (Microsoft MCP indirect injection guidance).

Vorteile & Nachteile

Vorteile

  • Kann Agent-Integrationen beschleunigen, wenn mehrere Clients einen wiederverwendbaren, standardisierten Zugang zu denselben Tools, Datenquellen oder Developer-Systemen brauchen.
  • Reduziert Bespoke-Connector-Arbeit für legitime Agent-Tool-Use-Cases durch Resources und Tools über ein gemeinsames Protokoll mit wachsendem Ökosystem.
  • Funktioniert gut, wenn die Integration ein klares Threat Model, eng begrenzte Tools, explizite User Consent, auditierbare Authorization und einen Lifecycle-Owner für den MCP-Server hat.

Nachteile

  • Exponiert Tool- und Datenflächen für modellgesteuerte Systeme und erhöht Risiken durch Prompt Injection, Tool Poisoning, Confused Deputy, SSRF, Session Hijacking und Data Exfiltration.
  • Fügt Identity, Authorization, Consent, Scope Design, Token Handling, Transport, Observability und Supply-Chain-Verantwortung hinzu, die einfachere CLI-, API-, Batch- oder Human-Approval-Flows vermeiden können.
  • Ermutigt zu Over-Integration, wenn Teams breite Tool-Kataloge standardmäßig publizieren statt Least Privilege, progressive Elevation, User Approval und risikobasierte Tool-Exposition anzuwenden.

Empfehlung

Bei MCP-first-Architekturentscheidungen auf Hold bleiben, bis Integrationsbedarf, User Journey, Threat Model, Identity Model und Governance die Wahl des Protokolls rechtfertigen. Mit der kleinsten funktionierenden Schnittstelle starten: read-only Export, eingeschränkter API-Endpoint, CLI-Befehl, geplanter Batch, Webhook oder Approval-Workflow können leichter zu sichern und zu beobachten sein als ein General-Purpose-MCP-Server.

MCP nutzen, wenn Nutzen spezifisch und messbar ist: mehrere Agent-Clients brauchen dieselbe Integration, die Tool-Fläche ist stabil, Authorization und Scopes sind klar definiert, Human Approval ist machbar, und der Server hat einen Owner für Updates, Logging, Monitoring, Incident Response und Deprecation. Zuerst read-only Tools, Write Actions nur mit expliziter Freigabe und Idempotenz; keine rohen Admin-APIs oder breite Filesystem-, Netzwerk-, Datenbank- oder Messaging-Fähigkeiten.

Vor Produktion Security Review verlangen: Tool Inventory, Consent UI, Token-Audience-Validierung, OAuth Flow, Redirect-URI-Matching, SSRF Controls, lokales Execution Model, Transport-Restriktionen, Least-Privilege-Scopes, Prompt-Injection-Handling, Tool-Description-Change Detection, Logging, Rate Limiting, Package Provenance und Rollback. Von Hold nur wechseln, wenn MCP die richtige Integrationsabstraktion ist, nicht der Default, weil Agents es unterstützen.

Quellen