MCP-Authentifizierung erklärt: Inbound-Identität, Outbound-Anmeldedaten und Delegierung

Das Token, das einen Aufrufer gegenüber einem Gateway identifiziert, und die Anmeldedaten, die für den Zugriff auf einen nachgelagerten Dienst verwendet werden, lösen unterschiedliche Probleme. Sichere MCP-Systeme wahren diese Unterscheidung.

Authentifizierung umfasst mehr als einen Hop

Eine MCP-Anfrage kann mehrere Vertrauensgrenzen überschreiten, bevor ein geschäftliches Zielsystem sie empfängt. Eine Person oder ein Dienst authentifiziert sich gegenüber einer Anwendung. Ein Agent kann als eigenständiger Software-Principal agieren. Der Client authentifiziert sich beim MCP Gateway. Das Gateway entscheidet, ob dieser Aufrufer einen Server oder ein Tool nutzen darf. Anschließend authentifiziert sich das Gateway gegenüber dem nachgelagerten MCP-Server, der seinerseits einen weiteren autoritativen Dienst aufrufen kann.

Verwendet man den Begriff „Token“ für jegliche Anmeldedaten, verschwimmen diese Grenzen. Die Inbound-Anmeldedaten beantworten die Frage, wer das Gateway aufruft. Die Zugriffsrichtlinie (Access Policy) regelt, welche Gateway-Ressourcen diese Identität nutzen darf. Die Outbound-Authentifizierung bestimmt, dessen Anmeldedaten und Berechtigungen der nachgelagerte Server erhält. Diese Antworten können bewusst unterschiedlich ausfallen.

Die Dokumentation von TrueFoundry unterteilt die Architektur in Inbound-Authentifizierung, Zugriffskontrolle und Outbound-Authentifizierung. Diese Trennung bildet den richtigen Ausgangspunkt, um über Delegierung, Zuordnung (Attribution) und das Confused-Deputy-Problem nachzudenken.

Das Gateway unterteilt die Überprüfung bewusst in drei Schritte. Eine erfolgreiche Inbound-Authentifizierung identifiziert den Aufrufer, die Zugriffsrichtlinie wählt jedoch weiterhin die zulässigen Tools aus und die Outbound-Authentifizierung bestimmt nach wie vor den Principal, den der MCP-Server sieht.

Inbound-Authentifizierung ermittelt den Gateway-Aufrufer

TrueFoundry dokumentiert mehrere Inbound-Methoden: ein Personal Access Token für Benutzer mit TrueFoundry-Konten, ein Virtual-Account-Token für Aufrufe von Dienst zu Dienst, ein Identity-Provider-Token für Kunden oder Dienste, die den JWT-Issuer einer Organisation nutzen, sowie TrueFoundry OAuth für kompatible IDE-Clients.

Nach Validierung der Anmeldedaten löst das Gateway eine TrueFoundry-Identität auf und wendet die Zugriffskontrolle auf MCP-Server und einzelne Tools an. Die relevante Identität kann ein Benutzer, ein Team oder ein virtuelles Konto sein. Die als Beta dokumentierte Funktion Agent Identity fügt einen separat registrierten Agent-Akteur für von Agenten ausgehende Aufrufe hinzu. Dies unterscheidet sich von einem virtuellen Konto, das einen Dienst oder eine Anwendung ohne menschlichen Benutzer dahinter repräsentiert.

Die Identitätsauflösung sollte Issuer, Audience, Signatur, Zeitgrenzen und das Claim-Mapping zur Auswahl des Subjects überprüfen. Ein gültig signiertes Token für die falsche Audience stellt keine Autorisierung für das Gateway dar. Mappings sollten präzise genug sein, damit zwei Dienste nicht versehentlich auf dieselbe Agentenidentität aufgelöst werden.

Outbound-Authentifizierung wählt den nachgelagerten Principal

Das Gateway kann sich gegenüber einem MCP-Server authentifizieren mittels: benutzerbezogenem OAuth Authorization Code, OAuth Client Credentials auf Anwendungsebene, der dokumentierten Okta Token-Exchange/OBO-Konfiguration, geteilten oder individuellen API-Schlüsseln, ohne Authentifizierung für öffentliche Dienste, Token-Passthrough, Token-Forwarding oder AWS SigV4 für unterstützte AWS-Endpunkte.

Diese Modi repräsentieren unterschiedliche Autoritätsebenen. Benutzerbezogenes OAuth ermöglicht es jeder Person, ihr eigenes Drittanbieter-Konto zu autorisieren. Client Credentials repräsentieren die Anwendung und gewähren in der Regel gemeinsame Dienstberechtigungen. Token Exchange oder OBO fordert ein Identitätssystem auf, ein nachgelagertes Token auszustellen, das von der Identität des Aufrufers abgeleitet und auf eine andere Audience ausgerichtet ist. Ein gemeinsam genutzter API-Schlüssel fasst alle Aufrufer unter einem einzigen vorgelagerten Principal zusammen, selbst wenn das Gateway die interne Zuordnung beibehält.

Die Wahl der einfachsten Integration kann das Autorisierungsmodell stillschweigend verändern. Verwendet ein Gmail-MCP-Server ein einziges gemeinsam genutztes Dienstkonto, sieht das vorgelagerte System nicht die persönliche Postfachberechtigung des einzelnen Mitarbeiters. Validiert ein interner MCP-Server das IdP-Token der Organisation direkt, kann ein Passthrough das Subject bewahren – jedoch nur, wenn Issuer, Audience und Scopes bewusst akzeptiert werden.

Das Diagramm gruppiert Modi nach ihrer Autoritätssemantik statt nach Protokollbezeichnungen. Benutzerbezogene und OBO-Flows können den Subject-Kontext bewahren, während Client Credentials und gemeinsam genutzte Schlüssel die Autorität der Anwendung repräsentieren, sofern der nachgelagerte Dienst keine zusätzlichen subject-bezogenen Kontrollen anwendet.

Passthrough und Forwarding sind keine Synonyme

In der dokumentierten Terminologie von TrueFoundry leitet Token-Passthrough dasselbe Token, das für die Inbound-Authentifizierung verwendet wurde, an den MCP-Server weiter. Der Server muss in der Lage sein, dieses TrueFoundry- oder Identity-Provider-Token zu validieren. Token-Forwarding hingegen überträgt separate, serverspezifische Anmeldedaten, die vom Client in dedizierten Headern bereitgestellt werden. Die Outbound-Anmeldedaten sind hierbei nicht der Inbound-Bearer.

Diese Unterscheidung ist wichtig für Protokollierung, Schwärzung, Widerruf und Bedrohungsmodellierung. Passthrough bewahrt ein einzelnes Credential über die Gateway-Grenze hinweg und erfordert daher ein korrektes nachgelagertes Audience-Vertrauen. Forwarding führt ein weiteres Geheimnis ein, das der Client beschaffen und schützen muss. Beide Verfahren belegen nicht automatisch, dass eine finale geschäftliche API die beabsichtigte Beziehung zwischen Mensch und Agent erkannt hat.

OAuth Token Exchange und OBO bieten ein anderes Muster: Das Gateway oder die Identitätsebene bezieht ein neues, audience-spezifisches Token, das die delegierte Autorität repräsentiert. Dies kann die Wiederverwendung von Bearer-Tokens reduzieren und es nachgelagerten Systemen ermöglichen, speziell für ihre Ressource definierte Scopes durchzusetzen. Die genauen Garantien hängen vom Identity Provider, den Claims, der Validierung und der nachgelagerten Anwendung ab.

Modellieren Sie die Principals, nicht nur die Header

Verhindern Sie das Confused-Deputy-Problem

Ein Gateway wird zum „Confused Deputy“ (verwirrten Stellvertreter), wenn es über weitreichende nachgelagerte Autorität verfügt und diese für einen Aufrufer nutzt, dem die entsprechende Berechtigung fehlt. Die Inbound-Authentifizierung kann vollkommen gültig sein, während die zusammengesetzte Aktion dennoch überautorisiert ist. Das Gateway muss Aufruferidentität, Agentenidentität, angeforderten Server und Tool, Outbound-Anmeldedatenmodus und nachgelagerten Scope zusammenführen.

Bei gemeinsam genutzten Anmeldedaten sollte der MCP-Server oder die zugrundeliegende Anwendung ausreichend vertrauenswürdigen Kontext erhalten, um eine subject-bezogene Autorisierung erneut anzuwenden, oder das Tool darf nur Ressourcen bereitstellen, die für jeden zugelassenen Aufrufer sicher sind. Verlassen Sie sich nicht darauf, dass das Modell Ergebnisse nach einer breit angelegten Abfrage filtert. Überprüfen Sie bei benutzerbezogenen Anmeldedaten, dass die Autorisierung an das vorgesehene Subject gebunden ist und nicht durch Übersteuerungen (Overrides) durch einen anderen Benutzer ersetzt werden kann.

Jeder Hop sollte zudem eine Audit-Korrelations-ID aufrechterhalten, ohne Bearer-Tokens in Protokolle zu kopieren. Erfassen Sie Anmeldedatenmodus, aufgelöste Identität, Issuer, Audience, Scope-Klasse, Richtlinienversion und nachgelagerte Antwort-Metadaten. Geheimwerte gehören in geschützte Datenspeicher, nicht in Transkripte oder Traces.

Die Kette führt sowohl ein menschliches Subject als auch einen Software-Akteur durch die Gateway-Entscheidung. Der Outbound-Modus kann diesen Identitätskontext bewahren, austauschen oder zusammenfassen; das nachgelagerte System führt weiterhin die finale Autorisierung von Ressource und Aktion durch.

Ein praktisches Beispiel: CRM-Zugriff im Kundensupport

Ein Support-Mitarbeiter erhält eine Anfrage von einem authentifizierten Mitarbeiter. Die Anwendung sendet das Identity-Provider-Token des Mitarbeiters an das MCP Gateway und übergibt separat die registrierte Agentenidentität. Die Gateway-Richtlinie erlaubt diesem Benutzer-Agenten-Paar den Aufruf des CRM-Such-Tools.

Angenommen, die Bereitstellung nutzt die dokumentierte Okta OBO-Konfiguration von TrueFoundry. Das Gateway tauscht das eingehende Benutzertoken gegen ein Token für die CRM-Audience mit schreibgeschütztem Case-Scope aus. Das CRM validiert das neue Token und wendet seine eigene Autorisierung auf Zeilenebene an. Der Agent kann die berechtigten Fälle des Mitarbeiters abrufen, diese jedoch nicht ändern. Ein separates Update-Tool erfordert einen engeren nachgelagerten Scope und eine Genehmigung.

Verwendet die Bereitstellung stattdessen einen gemeinsam genutzten API-Schlüssel, muss die Architektur dies kompensieren. Der dem CRM vorgelagerte Dienst empfängt ein vertrauenswürdiges Attribut des aufgelösten Subjects vom Gateway, validiert es und filtert Datensätze serverseitig. Kann der Dienst den Subject-Kontext nicht durchsetzen, ist der gemeinsam genutzte Schlüssel für Daten mit benutzerspezifischer Autorisierung ungeeignet.

Outbound-Authentifizierung nach Autoritätssemantik wählen

• Verwenden Sie benutzerbezogene Autorisierung, wenn die vorgelagerte Ressource Eigentum der jeweiligen Person ist oder von dieser berechtigt wird.
• Verwenden Sie Client Credentials für Ressourcen, die tatsächlich im Eigentum der Anwendung stehen, und nicht als Abkürzung zur Umgehung der Benutzerautorisierung.
• Verwenden Sie Token Exchange oder OBO, wenn das nachgelagerte System ein delegiertes, audience-spezifisches Benutzertoken benötigt.
• Verwenden Sie Passthrough nur dann, wenn das nachgelagerte System das Inbound-Token bewusst vertraut und validiert.
• Verwenden Sie Forwarding, wenn der MCP-Server über ein separates Anmeldedatenschema verfügt, und akzeptieren Sie den daraus resultierenden Aufwand für die Verwaltung von Client-Geheimnissen.
• Behandeln Sie Server ohne Authentifizierung als öffentliche Funktionen; platzieren Sie keine sensiblen Daten oder mutierenden Aktionen dahinter.

Fehlertests für die Authentifizierungskette

• Spielen Sie ein gültiges Token mit der falschen Audience, dem falschen Issuer, Mandanten oder zugeordneten Subject erneut ein (Replay-Test).
• Halten Sie den Benutzer konstant und ändern Sie die Agentenidentität; überprüfen Sie, ob sich die effektive Tool-Reichweite wie vorgesehen ändert.
• Halten Sie den Agenten konstant und ändern Sie den Benutzer; überprüfen Sie, ob nachgelagerte Daten bei Bedarf dem menschlichen Subject folgen.
• Ersetzen Sie individuelle Anmeldedaten über die Autorisierungsübersteuerung eines anderen Benutzers.
• Widerrufen Sie eine Gateway-Freigabe und eine vorgelagerte OAuth-Freigabe unabhängig voneinander; überprüfen Sie deren unterschiedliche Auswirkungen.
• Rufen Sie den MCP-Server außerhalb des Gateways auf; überprüfen Sie, ob Netzwerk- und Serverrichtlinien ein Umgehen bei Bedarf verhindern.
• Inspeziieren Sie Protokolle, Traces, Fehler und Modellkontexte auf durchgesickerte Bearer-Tokens oder weitergeleitete Geheimnisse.

Der Lebenszyklus von Anmeldedaten ist Teil des Datenpfads

Das Authentifizierungsdesign endet nicht mit der Akzeptanz eines Tokens. Anmeldedaten laufen ab, werden aktualisiert, rotiert und auf unterschiedlichen Systemen widerrufen. Die Dokumentation von TrueFoundry weist beispielsweise darauf hin, dass die Aktion „Revoke all tokens“ gespeicherte Anmeldedaten aus dem AI Gateway löscht, jedoch keine Freigaben beim vorgelagerten OAuth-Provider widerruft. Betreiber benötigen separate Verfahren für Gateway-Anmeldedaten, Identity-Provider-Sitzungen, vorgelagerte Autorisierungen und etwaige zwischengespeicherte nachgelagerte Tokens.

Legen Sie fest, welche Komponente die jeweiligen Anmeldedaten aktualisiert, welches Subject das aktualisierte Token repräsentiert und was passiert, wenn die Aktualisierung während einer Agentenaufgabe fehlschlägt. Ein pausierter Autorisierungs-Flow sollte nicht stillschweigend auf Anwendungs-Anmeldedaten mit umfassenderem Zugriff zurückfallen. Verbindet ein Benutzer sein Konto erneut, sollte die neue Freigabe mit dem vorgesehenen Subject und Server korreliert werden, bevor der Agent fortfährt.

Die Rotation schafft eine weitere Testgrenze. Gemeinsam genutzte API-Schlüssel benötigen möglicherweise einen Übergangszeitraum mit zwei Schlüsseln; benutzerbezogene OAuth-Tokens können unabhängig voneinander ungültig werden; OBO-Tokens können bis zum Ablauf zwischengespeichert werden, während das Inbound-Token für den erneuten Austausch aktuell bleiben muss. Speichern Sie Bezeichner für Anmeldedatenmodus und Token-Familie in geschützten Betriebs-Metadaten, damit Zuständige betroffene Aufrufe finden können, ohne Geheimnisse offenzulegen.

Der Widerruf sollte von außen nach innen überprüft werden. Entfernen Sie den Gateway-Mitarbeiter, widerrufen Sie die vorgelagerte Freigabe, deaktivieren Sie das nachgelagerte Konto und testen Sie jede Auswirkung separat. Ein vollständiges Incident-Verfahren weiß, welche Aktion neue Gateway-Aufrufe stoppt, welche den direkten Zugriff ungültig macht und welche nur eine lokale Kopie löscht.

Die Token-Verarbeitung sollte zudem im für das Modell sichtbaren Kontext fehlen. Agenten können über stabile Identitätsbezeichnungen, Autorisierungsergebnisse und Anweisungen zur erneuten Verbindung nachdenken, ohne Bearer-Material zu empfangen. Von Providern zurückgegebene Fehler sollten normalisiert werden, damit Debug-Ausgaben keine Header, Refresh-Tokens, Client-Geheimnisse oder signierten Anforderungsbestandteile in das Transkript leaken.

Die betriebliche Regel

Sichere MCP-Authentifizierung beginnt mit der Benennung jedes Principals und Hops. Inbound-Identität, Gateway-Zugriff, Outbound-Anmeldedaten und geschäftliche Autorisierung sind verwandte, aber nicht austauschbare Kontrollmechanismen. Das sicherste Design macht jeden Wechsel von Principal oder Audience explizit.

Das TrueFoundry MCP Gateway bietet dokumentierte Mechanismen für jede dem Gateway zugewandte Schicht, und Agent Identity – in der Governance-Verfügbarkeitsmatrix als Beta dokumentiert – kann den Software-Akteur vom menschlichen Subject unterscheiden. Die nachgelagerte Anwendung bleibt weiterhin Eigentümerin ihrer Domänen-Autorisierung und die Organisation bleibt Eigentümerin der Anmeldedaten-Minimierung. Diese Grenze ist keine Einschränkung in der Erklärung; sie ist das, was das Sicherheitsmodell überprüfbar macht.

Referenzen

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Redaktioneller Hinweis. Dieser Artikel spiegelt die technische Interpretation der zitierten öffentlichen Materialien durch TrueFoundry mit Stand vom 17. September 2026 wider. Produktfunktionen beschränken sich auf die verlinkte Dokumentation. Beispiele und Standard-Betriebseinstellungen dienen der Veranschaulichung; sie stellen keine Rechtsberatung, kein Audit-Gutachten, keinen unabhängigen Benchmark und keine Garantie für Sicherheit, Zuverlässigkeit oder Compliance dar.

‍