MCP-Sicherheit im Produktivbetrieb

Ein MCP-Server ist nicht einfach eine weitere API. Er ist ein Anweisungskanal, den das Modell liest und ausführt. Jeder Werkzeugname, jede Parameterbeschreibung und jede Zeichenkette, die ein Werkzeug zurückgibt, landet im selben Kontextfenster wie die Anfrage der Nutzerin – und das Modell kann Daten nicht zuverlässig von Befehlen unterscheiden. Genau diese Eigenschaft macht Model-Context-Protocol-Sicherheit zu einer anderen Disziplin als API-Sicherheit, und sie erklärt, warum sich die Vorfälle des Jahres 2026 so gleichförmig wiederholen.

Dies ist ein Betriebsleitfaden, kein Aufsatz über Bedrohungsmodellierung: was die Spezifikation bereits vorschreibt, was die Vorfälle 2026 tatsächlich gebrochen haben und welche Kontrollen im Produktivbetrieb tragen – samt Befehlen zur Prüfung.

Was MCP an Ihrem Bedrohungsmodell ändert

In einer klassischen Integration entscheidet die Entwicklerin, welcher Aufruf mit welchen Argumenten an welcher Codestelle erfolgt. Bei MCP übergibt der Client dem Modell die Werkzeugdefinitionen aller verbundenen Server, und das Modell wählt Aufruf und Parameter. OWASP formuliert die Folge unmissverständlich: MCP bündelt Prompt Injection, Lieferkettenrisiko und das Confused-Deputy-Problem an einer Stelle.^[owaspcs]

• Werkzeug-Metadaten wirken wie Code. Beschreibungen und JSON-Schemas liest das Modell als Handlungsanweisung. Ein vergiftetes description-Feld ist näher an injiziertem Code als an Dokumentation.
• Werkzeugausgaben sind nicht vertrauenswürdige Eingaben. Eine Webseite, ein Issue-Titel oder eine Datenbankzeile kehren mit demselben Rang in den Kontext zurück wie der System-Prompt.
• Das Modell sieht alle Server gleichzeitig. Die Beschreibung eines bösartigen Servers kann verändern, wie der Agent einen anderen, vertrauenswürdigen Server nutzt. Das ist Tool Shadowing – eine Prüfung Server für Server findet es nicht.^[owaspcs]

Die Spezifikation stellt ausdrücklich klar, dass sie das nicht für Sie löst: Autorisierung ist für MCP-Implementierungen OPTIONAL; bei HTTP-Transport SOLLTE die Spezifikation befolgt werden, stdio-Implementierungen sollen Zugangsdaten aus der Umgebung beziehen.^[spec-auth] Alles Weitere – Sandboxing, Werkzeugintegrität, Egress-Kontrolle – bleibt bei denen, die Host, Client oder Server ausliefern.

Die Vorfälle 2026, die den Maßstab setzen

Die beiden deutlichsten Datenpunkte des Jahres stammen nicht aus exotischen Laboraufbauten, sondern aus den Standardkonfigurationen der Hersteller selbst. Am 5. August 2026 prüfte Novee Security auf der Black Hat USA die Coding-Agents von Anthropic, Google und OpenAI in genau der Konfiguration, die diese Hersteller ausliefern. Aus der Arbeit gingen zwei CVEs hervor, beide behoben. Was die beiden jeweils erlaubten, unterscheidet sich stark – und genau darin liegt der Erkenntniswert.^{[ghsa-google][ghsa-anthropic]}

Das Muster lohnt eine präzise Formulierung, weil es weit über diese drei Produkte hinaus gilt: der Fehler saß im Harness, nicht im Modell. Eine Komponente markierte einen Wert als sicher, eine spätere handelte mit mehr Autorität darauf. Nach dem Berichtsstand vom 7. August 2026 stand keiner der beiden CVEs im KEV-Katalog der CISA, und die öffentliche Quellenlage zeigt keine dieser Ketten gegen ein reales Ziel eingesetzt – es geht um die Fehlerklasse, nicht um eine laufende Kampagne.

Lesen Sie das zusammen mit dem Betriebsmodell aus DevOps vs. MLOps vs. LLMOps: Wer das exakte Bündel hinter einer Aktion nicht benennen kann – Modell, Prompt, Werkzeugschema, Policy –, kann weder einen Vorfall erklären noch einem Rollback trauen.

Die Grundlinie, die die Spezifikation bereits vorschreibt

Ein überraschend großer Teil von „MCP-Sicherheit“ ist schlicht sauberes OAuth. Die Revision 2025-06-18 stufte den MCP-Server als reinen OAuth-2.1-Resource Server ein, die Revision 2025-11-25 verfeinerte Discovery und Consent.^[spec-log] Wer einen entfernten MCP-Server betreibt, findet im Folgenden keine Empfehlungen, sondern Pflichten.^{[oauth21][rfc9700][nsa]}

Discovery: RFC 9728 statt README

MCP-Server MÜSSEN OAuth 2.0 Protected Resource Metadata implementieren und mindestens einen Eintrag in authorization_servers veröffentlichen; Clients MÜSSEN das für die Discovery nutzen. Auf eine nicht authentifizierte Anfrage antwortet der Server mit 401 und einem WWW-Authenticate-Header, der auf das Metadatendokument zeigt.^{[spec-auth][rfc9728]}

curl -sSI https://mcp.example.com/mcp | grep -i '^www-authenticate'
# www-authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

curl -sS https://mcp.example.com/.well-known/oauth-protected-resource \
  | jq '{resource, authorization_servers, scopes_supported}'

curl -sS https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{issuer, token_endpoint, code_challenge_methods_supported}'

Audience-Bindung: die Kontrolle gegen Token-Wiederverwendung

Clients MÜSSEN den resource-Parameter aus RFC 8707 in Authorization- und Token-Request senden – mit der kanonischen URI des Zielservers und unabhängig davon, ob der Autorisierungsserver ihn unterstützt.^[rfc8707] Server MÜSSEN prüfen, dass ein vorgelegtes Token für sie ausgestellt wurde, und es andernfalls ablehnen.^[spec-auth]

Token-Passthrough – ein Token annehmen, das nicht für einen selbst ausgestellt wurde, und es weiterreichen – ist ausdrücklich verboten. Die Begründung der Spezifikation ist betrieblich: Es zerstört den Audit-Trail, umgeht Rate Limits und Prüfungen, die von der Audience abhängen, und macht den Server zum Proxy für jeden mit einem gestohlenen Token.^[spec-sec] Ruft Ihr MCP-Server eine vorgelagerte API auf, ist er dort Client und braucht ein eigenes Token.

CANONICAL = "https://mcp.example.com/mcp"   # RFC 8707 resource identifier

def authorize(token: dict) -> None:
    aud = token.get("aud")
    aud = aud if isinstance(aud, list) else [aud]
    if CANONICAL not in aud:
        raise Unauthorized("token audience does not include this server")   # 401
    if not required_scopes(token).issuperset(scopes_for_current_tool()):
        raise Forbidden("insufficient scope")                               # 403
    # Never forward `token` upstream. Mint a separate one for the upstream API.

Client-Registrierung: CIMD ist jetzt der empfohlene Standard

Die Revision 2025-11-25 ergänzte OAuth Client ID Metadata Documents als empfohlenen Registrierungsmechanismus (SEP-991), dazu Unterstützung für OpenID Connect Discovery und inkrementelle Scope-Zustimmung über WWW-Authenticate.^{[spec-log][cimd]} Bei CIMD ist die client_id eine HTTPS-URL, die auf ein kleines JSON-Dokument mit der Client-Beschreibung zeigt; der Autorisierungsserver holt es, prüft die registrierten Redirect-URIs und wendet seine Policy an – ohne Vorabsprache und ohne den Wildwuchs an Wegwerf-Registrierungen aus Dynamic Client Registration.

Das ist relevant, weil DCR eine Zutat des Confused-Deputy-Angriffs ist. Nutzt ein proxyender MCP-Server eine statische Client-ID gegenüber einem Drittanbieter-Autorisierungsserver, erlaubt zugleich dynamische Registrierung und setzt der Dritte zusätzlich ein Consent-Cookie, kann ein Angreifer einen Client mit eigener redirect_uri registrieren, das Cookie des Opfers wiederverwenden, den Zustimmungsdialog überspringen und den Authorization Code abgreifen. Gegenmaßnahme: serverseitig gespeicherte Zustimmung pro Client, geprüft vor dem Drittanbieter-Flow, exakte Redirect-URI-Prüfung und ein einmalig verwendbarer state.^[spec-sec]

Nichts davon ist neue Identitätstechnik – es ist dieselbe Disziplin wie IAM, das skaliert, mit denselben Abwägungen wie bei der Wahl zwischen Keycloak und Entra ID. Nutzen Sie den Autorisierungsserver, den Sie ohnehin betreiben und auditieren; lassen Sie nicht jeden MCP-Server seinen eigenen aufbauen.

Zehn Fehlermodi und die Kontrolle, die jeden schließt

Die OWASP MCP Top 10 sind ein lebendes Dokument in der Beta (v0.1) mit nächster Ausgabe für Oktober 2026 – also eher Checkliste als Zertifizierungsziel.^[owasp10]

Härtung, Schicht für Schicht

Werkzeugdefinitionen pinnen – oder Rug Pulls akzeptieren

Rug Pulls funktionieren, weil ein Werkzeug einmal genehmigt und danach nie wieder angesehen wird. Die Abhilfe ist mechanisch: Definition bei der Freigabe hashen, vor jedem Aufruf verifizieren.

import hashlib, json

def tool_fingerprint(tool: dict) -> str:
    canonical = json.dumps(
        {"name": tool["name"],
         "description": tool.get("description", ""),
         "inputSchema": tool.get("inputSchema", {})},
        sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    return hashlib.sha256(canonical.encode()).hexdigest()

if tool_fingerprint(live_tool) != PINNED[server_id][live_tool["name"]]:
    raise ToolDefinitionDrift(server_id, live_tool["name"])   # fail closed

Geschlossen scheitern. Ein Werkzeug, dessen Beschreibung sich seit der Freigabe geändert hat, ist ein neues Werkzeug und braucht eine neue Entscheidung durch einen Menschen – keinen stillen Retry.

Lokale Server ernsthaft sandboxen

Ein lokaler MCP-Server ist eine Binärdatei mit den Rechten des Clients. Die Vorgabe der Spezifikation für Ein-Klick-Konfiguration ist eindeutig: den exakten Befehl ungekürzt anzeigen, darauf hinweisen, dass er mit Client-Rechten läuft, und ihn mit minimalem Datei- und Netzwerkzugriff sandboxen.^[spec-sec] Lokal ist stdio vorzuziehen, weil es die Erreichbarkeit auf den Client-Prozess begrenzt. Muss es HTTP sein, binden Sie an 127.0.0.1 – nie an 0.0.0.0 –, verlangen Sie ein Token und validieren Sie den Host-Header bei jeder Anfrage.^[owaspcs]

docker run --rm -i \
  --network none \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  --user 10001:10001 \
  -v "$PWD/workspace:/workspace:ro" \
  ghcr.io/example/mcp-server@sha256:<digest>

Der @sha256:-Digest ist die Lieferkettenkontrolle, keine Stilfrage: Ein Tag lässt sich umhängen, ein Digest nicht. Wer ohnehin auf Kubernetes betreibt, wendet dieselbe Blast-Radius-Logik an wie in wann Kubernetes nicht die Antwort ist: ein Container pro MCP-Server lohnt sich, eine Control Plane pro MCP-Server nicht.

Egress kontrollieren – SSRF steckt im Discovery-Pfad

Dieser Punkt wird leicht übersehen, weil er den Client trifft, nicht den Server. Während der OAuth-Discovery ruft der Client URLs ab, die der Server liefert: die resource_metadata-URL aus WWW-Authenticate, die Einträge unter authorization_servers und danach die Endpunkte aus den AS-Metadaten. Ein bösartiger Server kann jede davon auf http://169.254.169.254/ richten und über Ihren Client Cloud-Instanzanmeldedaten auslesen.^[spec-sec]

Clients SOLLTEN außerhalb von Loopback HTTPS verlangen, private und Link-Local-Bereiche blockieren (10/8, 172.16/12, 192.168/16, 127/8, 169.254/16, fc00::/7, fe80::/10), dieselben Regeln auf jeden Redirect-Hop anwenden und serverseitige Deployments über einen Egress-Proxy führen. Die Spezifikation warnt ausdrücklich vor selbstgebauter IP-Validierung – Oktal-, Hex- und IPv4-mapped-IPv6-Kodierungen hebeln die meisten eigenen Parser aus – und vor DNS-Rebinding.^{[spec-sec][owaspssrf]}

Coding-Agents in der CI: Ihr wertvollstes Ziel

Ein Agent in der CI hat Schreibrechte am Repository und Zugriff auf Workflow-Secrets, und seine Eingabe ist das, was eine fremde Person in ein Issue geschrieben hat. Genau diese Konfiguration wurde auf der Black Hat angegriffen.

on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: read
  id-token: none

jobs:
  triage:
    runs-on: ubuntu-latest
    environment: agent-sandbox
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@<commit-sha>
        with: { persist-credentials: false }

      - run: printf '%s' "$ISSUE_BODY" > /tmp/untrusted.md
        env:
          ISSUE_BODY: ${{ github.event.issue.body }}

      - run: agent-cli review --input /tmp/untrusted.md --sandbox read-only --no-network

• Niemals ${{ github.event.* }} in einen run:-String interpolieren. Über Umgebungsvariable oder Datei übergeben.
• Repository-Anweisungsdateien sind nicht vertrauenswürdig. Das sagt inzwischen OpenAIs eigene Leitlinie, nachdem zwei Codex-Durchläufe mit gemeinsamem Checkout dem ersten erlaubten, die Anweisungen des zweiten zu schreiben.^[codex]
• Den Agenten zuletzt ausführen. Dieselbe Leitlinie warnt, er könne sonst Dateien für nachfolgende privilegierte Schritte hinterlassen.^[codex]
• Durchläufe in getrennte Jobs mit getrennten Checkouts legen, damit einer nicht die Eingabe des nächsten schreiben kann.
• Das Harness patchen. Gemini CLI 0.39.1, run-gemini-cli 0.1.22, Claude Code 2.1.163 – danach jeden von außen auslösbaren Workflow auditieren.

Audit: jeder Werkzeugaufruf muss rekonstruierbar sein

OWASP führt fehlende Telemetrie als eigenes Risiko, und sie macht aus einem eingegrenzten Vorfall einen unbegrenzten.^[owasp10] Mindestprotokoll pro Aufruf: authentifizierte Aufruferidentität, Server und Werkzeug, verifizierter Werkzeug-Fingerabdruck, vollständige Parameter mit geschwärzten Secrets, Entscheidungspfad (automatisch, per Policy, durch Menschen freigegeben), Ergebnis, Latenz und eine Korrelations-ID über den gesamten Agentenlauf. Alarm bei erstmals gesehenen Werkzeugen, Scope-Erhöhungen und anweisungsartigen Mustern in Werkzeugausgaben.

Zwei strukturelle Entscheidungen machen das jenseits einer Handvoll Server beherrschbar. Erstens: ein Gateway davor – eine Stelle, die Allowlists, Server-Isolation, Egress-Policy und Logging durchsetzt, schlägt dieselbe Policy in jedem Host neu implementiert. Zweitens: die langweilige Lösung wählen, wo es geht – das Argument aus langweiligen Cloud-Architekturen passt hier wörtlich: weniger bewegliche Teile, weniger Vertrauensgrenzen, weniger Verstecke für einen Confused Deputy. Dieselbe Zurückhaltung zahlt sich schon beim Zusammenstellen des Agenten-Stacks aus.

Ein Prüflauf für heute

Neun Prüfungen: 1) nicht authentifizierte Anfrage wird mit brauchbarem Verweis abgelehnt; 2) Protected Resource Metadata vorhanden; 3) Token für eine andere Audience wird abgelehnt; 4) einfaches HTTP wird nicht akzeptiert; 5) lokale Server lauschen nicht auf allen Interfaces; 6) Werkzeugdefinitionen stimmen mit den freigegebenen überein; 7) Images per Digest gepinnt; 8) keine Event-Daten in Shell-Schritten interpoliert; 9) Harness-Versionen auf Patch-Stand.

# 1
curl -sS -o /dev/null -w '%{http_code}\n' https://mcp.example.com/mcp

# 2
curl -sSf https://mcp.example.com/.well-known/oauth-protected-resource | jq -e '.authorization_servers[0]'

# 3
curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_FOR_OTHER_AUDIENCE" \
  https://mcp.example.com/mcp

# 4
curl -sS -o /dev/null -w '%{http_code}\n' http://mcp.example.com/mcp

# 5
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'

# 6
mcp-inspect list-tools --server internal | sha256sum

# 7
grep -rEn 'image:\s*\S+:(latest|main|v?[0-9]+)\s*$' deploy/

# 8
grep -rn 'github\.event\.\(issue\|comment\|pull_request\)' .github/workflows/ | grep 'run:'

# 9
gemini --version; claude --version

Prüfung 3 scheitert im ersten Durchgang am häufigsten – und ist zugleich die, bei der die Spezifikation am wenigsten Spielraum lässt.

Was diese Woche zu tun ist

MCP lohnt die Einführung. Das Protokoll beseitigt eine echte Klasse von Integrationsaufwand, und die Revision 2025-11-25 hat wichtige Sicherheitsentscheidungen aus dem Erfahrungswissen in die Spezifikation geholt. Ausgeliefert wird es aber als Fähigkeit, nicht als Control Plane. Die entscheidenden Kontrollen kennen Sie aus Identitäts- und Lieferkettenarbeit – angewandt auf eine Grenze, die viele Teams noch nicht gezogen haben.

In dieser Reihenfolge: Harness patchen; Audience-Prüfung verbindlich machen; Werkzeugdefinitionen und Image-Digests pinnen; lokale Server sandboxen und Egress schließen; und vor alles Destruktive ein menschliches Gate setzen. Wer sich in den nächsten zwölf Monaten die Finger verbrennt, wird nicht derjenige sein, der MCP eingeführt hat, sondern derjenige, der es eingeführt und das Harness auf Standard gelassen hat.

Häufige Fragen

Ist MCP standardmäßig sicher?

Nein, und die Spezifikation behauptet das auch nicht. Autorisierung ist für MCP-Implementierungen optional, und Sandboxing, Werkzeugintegrität und Netzwerk-Policy bleiben bei denen, die Host, Client oder Server bauen. Ein lokal installierter MCP-Server läuft mit denselben Rechten wie der Client, der ihn gestartet hat.

Was ist Tool Poisoning bei MCP?

Tool Poisoning bedeutet, die Werkzeuge eines Agenten so zu manipulieren, dass sich das Modell anders verhält. OWASP fasst darunter drei Untertechniken: Rug Pulls, bei denen die Beschreibung eines freigegebenen Werkzeugs nachträglich geändert wird; Schema Poisoning, bei dem die Schnittstellendefinition selbst in die Irre führt; und Tool Shadowing, bei dem die Beschreibung eines bösartigen Servers die Nutzung von Werkzeugen eines anderen, vertrauenswürdigen Servers verändert. Ein gepinnter Hash über Name, Beschreibung und Input-Schema, vor jedem Aufruf verifiziert, schließt die ersten beiden und erkennt die dritte.

Muss ich für meinen MCP-Server OAuth verwenden?

Bei entfernten HTTP-Transporten praktisch ja. Die Spezifikation sieht vor, dass HTTP-basierte Implementierungen ihrem OAuth-2.1-Modell folgen sollten: Der Server ist Resource Server, muss RFC 9728 implementieren und prüfen, dass vorgelegte Tokens für ihn ausgestellt wurden. Lokale stdio-Server beziehen Zugangsdaten aus der Umgebung, brauchen aber weiterhin Sandboxing und Zustimmungskontrollen.

Was ist Token-Passthrough und warum ist es verboten?

Token-Passthrough bedeutet, ein Token anzunehmen, das nicht für den eigenen Dienst ausgestellt wurde, und es unverändert weiterzureichen. Die MCP-Spezifikation verbietet das ausdrücklich: Es zerstört Audit-Trails, umgeht Kontrollen, die von der Token-Audience abhängen, und macht den Server zum Exfiltrations-Proxy für jeden mit einem gestohlenen Token. Ruft der MCP-Server eine vorgelagerte API auf, braucht er dafür ein eigenes Token.

Wird eine MCP-Schwachstelle aktiv ausgenutzt?

Zum Redaktionsschluss steht weder CVE-2026-12537 noch CVE-2026-54316 im KEV-Katalog der CISA, und die öffentliche Berichterstattung zeigt keine der Ketten gegen ein Ziel eingesetzt. Ein öffentliches Reproduktions-Repository für den Claude-Code-Fehler existiert seit Juni 2026 – der begrenzende Faktor ist also Ihre Patch-Latenz, nicht die Verfügbarkeit eines Exploits.

Wie verhindere ich, dass ein bösartiger MCP-Server mein internes Netz erreicht?

Die Angriffsfläche liegt im OAuth-Discovery-Pfad: Der Client ruft URLs ab, die der Server liefert, sodass ein bösartiger Server auf Cloud-Metadatenendpunkte oder interne Dienste zeigen kann. Verlangen Sie HTTPS außerhalb von Loopback, blockieren Sie private und Link-Local-Bereiche, wenden Sie dieselbe Prüfung auf jeden Redirect-Hop an und führen Sie serverseitige Clients über einen Egress-Proxy. Bauen Sie die IP-Prüfung nicht selbst.

Was sind Client ID Metadata Documents (CIMD)?

CIMD ist ein Registrierungsmechanismus, der in der MCP-Revision 2025-11-25 unter SEP-991 als empfohlener Standard ergänzt wurde. Die client_id ist eine HTTPS-URL, die auf ein JSON-Dokument mit Client-Beschreibung und Redirect-URIs verweist; der Autorisierungsserver holt und validiert es bei Bedarf. Das vermeidet fest kodierte Client-IDs ebenso wie den Wildwuchs an Wegwerf-Registrierungen aus Dynamic Client Registration.

Quellen und weiterführende Literatur

Spezifikationstext, IETF-RFCs, OWASP-Projektmaterial, das Cybersecurity Information Sheet der NSA und Hersteller-Advisories aus erster Hand.

1. Model Context Protocol — Authorization (specification 2025-11-25)
2. Model Context Protocol — Security Best Practices
3. Model Context Protocol — Key Changes, revision 2025-11-25
4. SEP-991 — OAuth Client ID Metadata Documents for MCP
5. RFC 9728 — OAuth 2.0 Protected Resource Metadata
6. RFC 8707 — Resource Indicators for OAuth 2.0
7. RFC 9700 — Best Current Practice for OAuth 2.0 Security
8. OAuth 2.1 — draft-ietf-oauth-v2-1-13
9. OWASP MCP Top 10 (beta, v0.1)
10. OWASP Cheat Sheet Series — MCP Security
11. OWASP Cheat Sheet Series — SSRF Prevention
12. NSA Artificial Intelligence Security Center — CSI: MCP Security Design Considerations for AI-Driven Automation
13. GHSA-fg94-h982-f3mm — Out-of-Band Data Exfiltration via Pre-Approved HuggingFace Domain in WebFetch
14. NVD — CVE-2026-54316
15. GHSA-wpqr-6v78-jr5g — Google run-gemini-cli security advisory
16. NVD — CVE-2026-12537
17. OpenAI — codex-action security guidance