Cross App Access auf dem TrueFoundry MCP Gateway: Identitätsgesteuerter Agenten-Zugriff, unterstützt durch Ihren IdP

KI-Agenten entwickeln sich schnell zur universellen Fernbedienung für die Unternehmensarbeit. Sie lesen aus Jira, schreiben in Slack, fragen das Data Warehouse ab, öffnen Pull-Requests und verketten ein Dutzend Tools miteinander, um eine einzelne Aufgabe zu erledigen. Das Model Context Protocol (MCP) ist das, was dies möglich macht — es gibt Agenten eine standardisierte Möglichkeit, diese Tools zu entdecken und aufzurufen.

Aber MCP beantwortet nur, wie ein Agent mit einem Tool spricht. Es beantwortet nicht die Frage, die sich derzeit jedes Sicherheitsteam stellt: Welche Agenten dürfen auf welche Systeme zugreifen, im Namen von wem, mit welchem Umfang — und wer kann das einsehen und widerrufen?

Genau diese Lücke schließt Cross App Access (XAA). Und es passt fast perfekt zu dem, wofür ein MCP-Gateway gebaut ist. Dieser Beitrag erklärt, was XAA ist, warum es wichtig ist und wie das TrueFoundry MCP Gateway es implementiert — wodurch Ihr Identity Provider zur Control Plane für jede Agenten-zu-Tool-Verbindung in Ihrer Organisation wird.

Das Problem: Agenten-Verbindungen finden außerhalb des Identitätsperimeters statt

Wenn ein Benutzer heute einen MCP-Client (eine KI-App wie Claude, Cursor oder VS Code) mit einem MCP-Server (Slack, Atlassian, ein interner Dienst) verbindet, findet der Autorisierungs-Handshake in der Regel direkt zwischen diesen beiden Apps statt. Das Muster sieht nach einer von zwei Möglichkeiten aus, und beide sind auf Unternehmensebene problematisch:

• Statische Anmeldeinformationen und API-Schlüssel. Langlebig, häufig mit zu weit gefassten Berechtigungen versehen, verstreut über Laptops und Konfigurationsdateien. Sie werden selten rotiert und fast nie sauber widerrufen. Jeder Schlüssel stellt ein dauerhaftes Privileg und einen potenziellen Schadensradius dar.
• Benutzerspezifische OAuth-Einwilligung. Besser als reine Schlüssel, aber dem Benutzer wird bei jedem Tool, jedem Client und jedes Mal ein Einwilligungsbildschirm angezeigt. Der Unternehmens-IdP hat den Benutzer an der App authentifiziert — aber er hat die Beziehung zwischen dem KI-Client und dem Tool nie autorisiert. Aus Sicht des IdP ist diese Gewährung unsichtbar.

Das Ergebnis ist Schatten-KI: ein unübersichtliches, unverwaltetes Netz von Agenten-zu-App-Verbindungen, das IT- und Sicherheitsteams weder inventarisieren noch kontrollieren können. Admins können die Frage „Welche KI-Clients können in Atlassian als dieser Benutzer agieren und mit welchen Berechtigungsumfängen (Scopes)?“ nicht beantworten — und sie können es nicht an zentraler Stelle abschalten, wenn ein Mitarbeiter oder ein Agent Offboarding durchläuft.

TrueFoundry löst bereits einen großen Teil dieses Problems, indem es den MCP-Zugriff über ein einzelnes, gesteuertes Gateway zentralisiert — ein einziger Zugangspunkt, RBAC bis auf Tool-Ebene, ein sicherer Credential Vault und ein vollständiger Audit-Trail. XAA schließt die letzte Lücke: Es stellt den Identity Provider selbst wieder in den Mittelpunkt der Autorisierungsentscheidung, sodass dieselben Richtlinien, die den Rest Ihres Stacks steuern, nun auch Ihre Agenten steuern.

Was Cross App Access eigentlich ist

Cross App Access (XAA) ist eine Erweiterung von OAuth 2.0, die es einem Enterprise Identity Provider ermöglicht, die Verbindung zwischen zwei Anwendungen zu vermitteln und zu genehmigen — anstatt dass diese beiden Apps direkt eine Vertrauensstellung aufbauen. Es wurde von Okta im Juni 2025 eingeführt, im September 2025 von der IETF OAuth Working Group übernommen und im November 2025 als Autorisierungserweiterung namens Enterprise-Managed Authorization (EMA) in MCP integriert. Diese Erweiterung erreichte im Juni 2026 den Status „Stable“.

Ein kurzer Hinweis zur Terminologie, da Sie in der Praxis beiden Namen begegnen werden:

• ID-JAG — der Identity Assertion JWT Authorization Grant — ist die anbieterneutrale OAuth-Erweiterung, die bei der IETF standardisiert wird. Es ist der technische Bauplan: Wie ein IdP eine signierte Identity Assertion ausstellt, welche Claims sie enthält und wie eine App diese einlöst.
• XAA ist Oktas Produktname für seine Implementierung von ID-JAG und der Begriff, dem die meisten Menschen zuerst begegnen. In MCP wird derselbe Mechanismus als Erweiterung für Enterprise-Managed Authorization bereitgestellt.

Wir werden durchgehend „XAA“ verwenden, aber der wichtige Punkt ist, dass es sich um einen offenen Standard handelt. Jeder IdP kann ID-JAG implementieren, und jeder MCP-Server, Client oder Gateway kann es unterstützen.

Die drei Rollen

XAA definiert eine klare Aufteilung der Verantwortlichkeiten:

Der Ablauf

Die Magie von XAA besteht darin, dass es den manuellen Einwilligungsschritt pro App durch einen richtliniengesteuerten Token-Exchange ersetzt, den der IdP vermittelt:

Da die Resource App den Signierungsschlüsseln des IdP aus dem SSO bereits vertraut, ist keine neue Vertrauensinfrastruktur erforderlich. Der IdP setzt die Richtlinie einmalig durch, stellt kurzlebige, zweckgebundene Tokens aus und zeichnet jede Gewährung auf — und der Benutzer sieht niemals eine Einwilligungssaufforderung. Autorisierungsentscheidungen verlagern sich von der Anwendungsebene auf die Identitätsebene, wo sie überprüfbar und widerrufbar sind.

Wie TrueFoundry XAA implementiert

Ein MCP-Gateway ist der ideale Ort für den Einsatz von XAA, da das Gateway genau an der Stelle sitzt, an der die Requesting App auf die Resource App trifft. Die Authentifizierungsarchitektur von TrueFoundry wurde um eine bewusste Trennung von inbound Authentifizierung (wie Clients ihre Identität gegenüber dem Gateway nachweisen) und outbound Authentifizierung (wie das Gateway nachgelagerte MCP-Server erreicht) herum aufgebaut. Diese Trennung ist genau die Form, die XAA benötigt.

TrueFoundry unterstützt XAA, indem das Gateway die Rolle der Requesting App übernimmt. Hier ist der Kernablauf.

Der Agent sendet sein Okta-Token; das Gateway führt den Exchange durch

Die Agenten-Anwendung authentifiziert den Benutzer einmalig bei Okta und erhält ein Okta-Token. Von da an übergibt sie dieses Token bei jeder Anfrage einfach an das Gateway — sie muss XAA nicht selbst implementieren oder eigene zweckgebundene Assertions einholen. Das Gateway kümmert sich um den Rest:

1. Validiert das Okta-Token und löst es mithilfe der bestehenden Identity Provider-Konfiguration und der Zuordnung von Okta-Gruppe → Team zu einer TrueFoundry-Identität (Benutzer, Team oder virtuelles Konto) auf und setzt dann RBAC/ABAC auf Tool-Ebene durch.
2. Führt den Token-Exchange mit Okta durch und fordert eine ID-JAG-Assertion an, die speziell für den MCP-Server gilt, den der Agent zu erreichen versucht. Okta wertet die XAA-Richtlinie aus und gibt die zweckgebundene Assertion zurück — ohne zusätzliche Einwilligungs- oder Autorisierungsaufforderung an den Benutzer.
3. Löst die Assertion ein gegen ein kurzlebiges, zielgruppenbeschränktes (audience-restricted) Access-Token für diesen MCP-Server.
4. Ruft den MCP-Server mit dem zweckgebundenen Token auf und streamt das Ergebnis zurück an den Agenten.

Der Benutzer meldet sich ein einziges Mal bei der Agenten-Anwendung an. Er sieht niemals einen OAuth-Einwilligungsbildschirm pro Server, und der Agent hält niemals dauerhafte Anmeldeinformationen für ein nachgelagertes Tool.

Dies baut direkt auf dem bestehenden Inbound-Authentifizierungsmodell von TrueFoundry auf (Identity Provider Tokens und Token Passthrough), wobei das Gateway als XAA Requesting App fungiert — den Token-Exchange durchführt und jede Assertion auf den jeweils genutzten Server beschränkt.

Anbindung von MCP-Servern, die kein XAA unterstützen (der Differenzierungsfaktor)

Die meisten MCP-Server in der Praxis — interne Dienste, OpenAPI-gecaptes Tools, Server von Drittanbietern — implementieren XAA nicht nativ, und viele werden es auch nie tun. Hier zahlt sich ein Gateway aus.

Da das Gateway den Identitätsfluss zentral terminiert, kann es die XAA-Governance vor jeden MCP-Server schalten, unabhängig davon, ob der Server den Standard unterstützt oder nicht. Sobald die Richtlinie erfüllt ist und ein zweckgebundenes Token vorliegt, vermittelt das Gateway die nachgelagerte Verbindung unter Verwendung dessen, was dieser Server tatsächlich versteht — benutzerspezifisches OAuth 2.0, Client Credentials, ein gemeinsam genutzter API-Schlüssel aus dem sicheren Vault, Token-Passthrough oder benutzerdefinierte Header. Der MCP-Server erhält eine enterprise-gesteuerte Autorisierung mit eingebundenem IdP, ohne eine einzige Zeile Token-Exchange-Code schreiben zu müssen, und Sie erhalten einen konsistenten XAA-Kontrollpunkt über Ihre gesamte Tool-Landschaft hinweg, anstelle eines Flickenteppichs aus „XAA-fähigen“ und „Legacy“-Servern.

Zuordnung von XAA zu bereits vorhandenen TrueFoundry-Funktionen

Wie es in der Praxis aussieht

Stellen Sie sich einen Entwickler vor, der Cursor bittet, einen Vorfall zu analysieren: die zugehörigen Atlassian-Tickets abrufen, den relevanten Slack-Thread prüfen und die Deployment-Historie zusammenfassen.

1. Der Entwickler meldet sich einmalig über Okta SSO bei der Agenten-Anwendung an, und der Agent erhält ein Okta-Token.
2. Der Agent sendet dieses Okta-Token bei jeder Anfrage an das TrueFoundry Gateway. Wenn er Atlassian benötigt, validiert das Gateway das Token, bestätigt, dass das Team des Entwicklers auf den Atlassian MCP-Server und nur auf die Lese-Tools zugreifen darf, für die es berechtigt ist, und führt den Token-Exchange mit Okta durch — wobei eine für diesen Server giltende Assertion angefordert wird. Okta prüft die Richtlinie — Darf die Gruppe dieses Entwicklers einem KI-Client den Zugriff auf Atlassian erlauben? — und gibt die zweckgebundene Assertion zurück. Kein Einwilligungs-Popup.
3. Das Gateway löst die Assertion gegen ein kurzlebiges, zweckgebundenes Access-Token ein und vermittelt den Aufruf an Atlassian.
4. Jede Aktion landet im Audit-Log von TrueFoundry, zugeordnet der individuellen Identität und dem spezifischen Agenten.
5. Wenn dieser Entwickler das Team verlässt, deaktiviert die IT ihn in Okta. Sein Zugriff — und der seines Agenten — auf jeden MCP-Server hinter dem Gateway wird über denselben Offboarding-Ablauf widerrufen, der auch den Rest seiner Apps steuert.

Es wurden keine neuen Schlüssel erstellt. Es wurden keine dauerhaften Privilegien hinterlassen. Die Sicherheitseinstufung der Richtlinie wurde einmalig in Okta überprüft.

Warum TrueFoundry + Okta

Okta gliedert das XAA-Ökosystem in drei Schichten: Requesting Apps (die Clients und Agenten), Resource Apps (die Tools, die Daten halten) und die Identitätsinfrastruktur- und Gateway-Schicht, die den Datenverkehr dazwischen leitet und sichert. TrueFoundry befindet sich genau in dieser dritten Schicht.

Die Kombination ist natürlich und komplementär:

• Okta ist die Control Plane. Es authentifiziert Benutzer, wertet aus, welche Apps sich verbinden dürfen, und stellt die signierten Assertions sowie kurzlebigen Tokens aus, die Richtlinien über Domänen hinweg übertragen.
• TrueFoundry ist die Durchsetzungs- und Konnektivitätsebene für MCP. Hier werden die Assertions eingelöst, hier wird RBAC auf Tool-Ebene angewendet, hier werden Nicht-XAA-Server in den Standard eingebunden, hier laufen Guardrails und hier wird jeder Aufruf protokolliert.

Zusammen ermöglichen sie es einem Unternehmen, die entscheidende Frage bei jeder modernen KI-Sicherheitsüberprüfung — „Können wir das in unserem IdP steuern?“ — mit einem eindeutigen Ja zu beantworten: Ihr Identity Provider entscheidet, welche KI-Clients sich mit welchen MCP-Servern und mit welchen Scopes verbinden, und Sie können alles zentral widerrufen.

Erste Schritte

Wenn Sie bereits das MCP Gateway von TrueFoundry nutzen, erweitert die XAA-Unterstützung das Authentifizierungsmodell, das Sie heute verwenden — registrieren Sie Okta als Identity Provider, ordnen Sie Okta-Gruppen TrueFoundry-Teams zu und bringen Sie Ihre MCP-Server (ob XAA-nativ oder nicht) unter einen einzigen identitätsgesteuerten Zugangspunkt.

Wenn Sie evaluieren, wie Sie KI-Agenten skaliert einsetzen können, ohne Wildwuchs bei den Anmeldeinformationen und Schatten-KI-Risiken einzugehen, ist dies das Fundament: standardbasiert, IdP-vermittelt und aufgebaut auf dem OAuth und OpenID Connect, dem Sie bereits vertrauen.