Confused Deputy
Wenn der MCP-Server mehr Rechte hat als der Nutzer, der ihn aufruft, ist die Tür offen für Identitäts-Verwechslungen. Klassisches Pattern aus der OS-Welt — und in MCP-Setups erschreckend häufig falsch umgesetzt.
Definition: Ein Confused Deputy ist ein Programm, das im Namen verschiedener User handelt, dabei aber MIT EIGENEN HÖHEREN RECHTEN — und nicht ausreichend prüft, in wessen Namen es gerade gerufen wird.
Berechtigungs-Karte
Nutzer
- liest eigene E-Mails
- löscht eigene Files
LLM
- bekommt Tool-Liste
- wählt Tool-Calls aus
MCP-Server
- liest ALLE E-Mails der Firma
- löscht ALLE Files
- schreibt in Audit-Log
Backend-API
- führt aus, was Server fordert
🚨 Asymmetrie: Der Server hat mehr Rechte als der Nutzer in dessen Namen er handelt. Das ist die Schwachstelle.
Szenario-Player
Setup
Eine Firma stellt einen MCP-Server bereit, der mit einer Inbox-API redet. Der Server-Account hat Read/Write auf JEDE Mailbox der Firma — weil sonst Admins keine Cross-User-Reports machen könnten. Jeder Mitarbeiter kann den Server in seinem Claude Desktop einhängen.
Risiko: Anna installiert den Server. Sie selbst darf nur ihre eigenen Mails lesen. Aber der Server, mit dem ihre Claude-Instanz nun redet, hat Zugriff auf alle. Das ist die Asymmetrie.
Schutz-Patterns
- User-Identity bei jedem Call mitgeben: Der Server muss wissen, in wessen Namen er handelt — über OS-User (stdio), OAuth- Token (HTTP) oder explizites Argument.
- Server-Rechte minimieren: Der Server-Account hat im Backend-System nur die Schnittmenge dessen, was die User gemeinsam dürfen. Niemals einen Super-Admin-Account verwenden.
- Per-User-OAuth-Flow: Bei hosted Servern: der Client delegiert dem Server ein User-Token, das nur Annas Rechte hat. Das Backend prüft dieses Token — der Server kann nicht mehr als Anna.
- Audit-Log mit beiden Identitäten: Jeder Aufruf loggt sowohl Server-Identity als auch User-Identity. So lässt sich ein Confused-Deputy-Vorfall im Nachhinein erkennen.
- Confirm-on-write — aber mit Kontext: Die User- Bestätigung muss zeigen, WELCHE Identität betroffen wird. Nicht „forward_email(...) ausführen?", sondern „forward_email FROM ceo@firma.com (NICHT du!) ausführen?".
Warum eigentlich? — Warum macht man den Fehler überhaupt?
Weil es bequem ist. Ein Server mit Admin-Rechten kann jede Anfrage bedienen, ohne pro-User-Token-Management. Lokal-stdio-Server haben keinen User-Context — sie laufen halt im OS-User. Hosted Server mit OAuth sind aufwendig: jeder User muss separat einloggen, Token-Refresh, Scope-Verhandlung. Viele Anbieter wählen den Bequemlichkeits-Pfad und packen Admin-Rechte in einen Service-Account.
Häufiger Denkfehler — Confused Deputy ≠ Prompt Injection
Verwechselt man oft. Prompt Injection ist DER VEKTOR — die Anweisung, die das LLM in die Irre führt. Confused Deputy ist DIE SCHWACHSTELLE — die Architektur, in der das LLM mehr Schaden anrichten kann, als der Nutzer dürfte. Eine korrekt rechte-isolierte Architektur überlebt Prompt Injection: der Server lehnt den schädlichen Call ab, weil die User-Identity ihn nicht autorisiert. Umgekehrt: ein Confused Deputy bleibt anfällig, auch wenn das LLM nicht injiziert wird — z.B. wenn der Nutzer selbst aus Versehen einen falschen Tool-Call bestätigt.
Tiefer rein — OAuth + MCP — die richtige Mechanik
Die MCP Authorization Spec definiert einen OAuth-2-Flow: der MCP-Server kennt einen Authorization-Server (z.B. Auth0, der eigene IDP). Der Client führt den User durch den OAuth-Flow, bekommt ein Access-Token, und gibt es bei jedem tools/call mit. Der Server leitet das Token an seine Backend-API weiter, und die Backend-API prüft, was DIESER USER darf. Ergebnis: kein Confused Deputy mehr, weil der Server keine eigenen Rechte braucht — nur ein durchgereichtes User-Token.