MCP by Default Sospendi

Ü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).

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

• Anthropic MCP announcement
• MCP security best practices
• MCP authorization guidance
• Microsoft MCP indirect injection guidance
• Simon Willison MCP analysis