Ein Agent, der Unternehmenssysteme erreichen kann, schafft ein Identitätsproblem, das klassische Anwendungsarchitekturen oft aufschieben können. Ein Nutzer bittet um einen Bericht. Der Agent wählt ein Tool. Ein Gateway leitet die Anfrage weiter. Ein Service in einem anderen Account liest Daten und führt eine Aktion aus. An jedem Hop muss eine täuschend einfache Frage beantwortet werden: Wer ruft hier an?

„Alex hat darum gebeten“ reicht nicht. Der nachgelagerte Service muss außerdem wissen, ob die Anfrage über das zugelassene Agent-Gateway kam, welche Runtime sie ausführt und ob diese Runtime in diesem Kontext für Alex handeln darf. Sieht der Service nur einen gemeinsamen API-Key, verschmilzt der ganze Pfad zu einem nicht unterscheidbaren Principal.

Genau dieses Problem löst Workload Identity Federation. Gemeint ist eine Architektur, die Identitäten von Software-Workloads über Accounts, Trust Domains oder Organisationsgrenzen hinweg etabliert, weitergibt und prüft. In einem Agent-System trennt sie üblicherweise drei Fakten: den auslösenden Nutzer, den ausführenden Workload und ein Gateway, das den Aufruf delegiert oder weiterleitet.

Einfach gesagt: Ein nachgelagertes Tool sollte einer Anfrage nicht allein vertrauen, weil sie ein User-Token enthält oder ein gemeinsames Geheimnis kennt. Es sollte prüfen können, welche Services sie verarbeitet haben und ob dieser Weg erlaubt ist.

Warum das jetzt wichtig ist

Agent-Plattformen zentralisieren meist den Teil, den Nutzer sehen: eine Chat-Oberfläche, einen Coding Agent oder ein Gateway zur Tool Discovery. Die Daten und Geschäftsoperationen, die sie benötigen, bleiben dagegen typischerweise verteilt. Finance, Support und Engineering besitzen jeweils eigene Accounts, Services, Richtlinien und Datensätze. Alles in einen zentralen Agent-Account zu kopieren, ist oft nicht vertretbar. Einem zentralen Agent dauerhaften, umfassenden Zugriff auf alle Accounts zu geben, ist kaum besser.

Die AWS-Referenzarchitektur vom 24. September macht eine Alternative konkret. Sie belässt Daten der Fachbereiche in getrennten AWS-Accounts, stellt ausgewählte Tools über MCP-Server bereit und präsentiert diese Fähigkeiten einem Agent über ein zentrales AgentCore Gateway. Die AWS-Architektur ist ein Implementierungsmuster, kein universeller Standard. Sie beschreibt aber die entscheidende Spannung: zentrale Discovery und Policy ohne zentrale Eigentümerschaft an sämtlichen Daten.

MCP, das Model Context Protocol, ermöglicht Agents, Tools zu entdecken und aufzurufen. Es legt jedoch nicht von selbst mehrstufige Identität, delegierte Berechtigung oder accountübergreifende Authorization fest. Diese Aspekte müssen aus der MCP-Implementierung, einem Identity-System und Policy Enforcement bewusst zusammengesetzt werden.

Die Entwicklung geht über ein einzelnes Cloud-Muster hinaus. Databricks kündigte am 24. September die Unity Gateway CLI als zentrale Stelle für zugelassene Coding Agents, Modelle, MCP-Server, Skills, Routing und Ausgabenrichtlinien an. Das Unternehmen beschreibt zudem zentrale Traces für lokale Tool-Aufrufe und Skill-Aufrufe. Die Databricks-Ankündigung zeigt, warum ein Gateway zum Kontrollpunkt wird. Vertrauenswürdig ist dieser Kontrollpunkt aber nur, wenn nachgelagerte Systeme Traffic über ihn von Traffic unterscheiden können, der ihn umgeht.

Die Identitätsfakten in einer Anfrage

Trenne zunächst Identitäten, die häufig in einem Token vermischt werden.

Die User Identity beschreibt, welcher Mensch oder Application Principal die Arbeit ausgelöst hat. Sie ist die passende Grundlage für Fragen wie: „Darf dieser Mitarbeiter diesen Kundendatensatz sehen?“

Die Workload Identity beschreibt, welcher laufende Service einen Netzwerkaufruf ausführt: etwa agent-runtime, policy-gateway oder billing-mcp-server. Sie beantwortet Fragen wie: „Ist dies ein Production-Gateway aus der erwarteten Umgebung?“ SPIFFE, eine Spezifikationsfamilie für Service Identity, modelliert dies mit kurzlebigen kryptografischen Credentials namens SVIDs. Ein SVID kann ein X.509-Zertifikat oder ein JWT sein. Die SPIFFE-Konzepte erläutern dieses Modell.

Der Delegation Path beschreibt, wer Berechtigung für wen ausübt. Das ist etwas anderes als das bloße Weiterreichen eines User-Credentials. OAuth 2.0 Token Exchange definiert Semantik für Impersonation und Delegation, einschließlich eines actor-Claims zur Kennzeichnung einer Partei, die in einer Kette Berechtigung ausübt. RFC 8693 legt diese Semantik fest.

Diese Mechanismen gehören zusammen, sind aber keine Synonyme. Ein Workload-Credential identifiziert einen Service. Ein User-Token identifiziert den auslösenden Principal. Token Exchange kann eine delegierte Beziehung ausdrücken. Ein sicheres Design braucht häufig alle drei.

Einfach gesagt: „Der Nutzer darf das“ und „dieser Service darf anrufen“ sind getrennte Prüfungen. Ein Agent-System wird sicherer, wenn es beide ausführt, statt ein User-Token als Berechtigung für jede Maschine im Pfad zu behandeln.

So funktioniert das Muster Schritt für Schritt

Stell dir einen zentralen Agent vor, der ein Finance-Tool und ein Support-Tool abfragen kann, die jeweils einem anderen Account gehören.

Erstens erhält jede beteiligte Runtime eine überprüfbare Identität. Behandle ein gemeinsames Secret nicht als Identität des gesamten Anfragepfads. Das Gateway braucht eine eigene Identität, ebenso die Agent-Runtime und jeder nachgelagerte Service. Das Credential muss mit einem zur Umgebung passenden Mechanismus ausgestellt, rotiert und validiert werden. Das gehört zum Credential Lifecycle Management. Dieses allein erklärt aber nicht, was ein Credential identifiziert oder welcher Trust Domain sein Empfänger vertraut.

Zweitens authentifizierst du den Nutzer unabhängig davon. Im dokumentierten AWS-Beispiel leitet der Agent das JWT des Nutzers zur Prüfung der User-Policy an das Gateway weiter. Das Gateway beschafft anschließend eigene OAuth-2.0-Machine-to-Machine-Credentials für ausgehende Aufrufe an MCP-Server der Fachbereiche. Die AWS-Architektur ist gerade deshalb nützlich, weil sie User-Token und Machine Credential des Gateways nicht für denselben Zweck ausgibt.

Drittens triffst du am Gateway eine explizite Authorization-Entscheidung. Ein Policy Enforcement Point ist die Komponente, die Zugriffsregeln an einer Grenze auswertet und durchsetzt. Dort kann Policy User-Claims, gewünschtes Tool, Tenant, Umgebung und Operation kombinieren. Sie kann entscheiden, ob der Nutzer finance.invoice.lookup aufrufen darf, statt nur zu prüfen, ob der Agent einen Finance-Endpunkt erreicht.

Viertens authentifiziert sich der nächste Hop als Workload. Der Finance-MCP-Server sollte das vom Gateway präsentierte Credential validieren. Überschreitet die Federation Trust Domains, brauchen Empfänger eine konfigurierte Grundlage, um fremden Issuern zu vertrauen. Bei SPIFFE Federation tauschen Trust Domains fremde Trust Bundles aus, damit Workloads Identitäten anderer Domains validieren können. SPIFFE Federation ist ein Modell für dieses Trust-Problem über Domain-Grenzen.

Fünftens erzwingst du auch lokale Authorization. Der datenbesitzende Service behält die Kontrolle über eigene Tool-Logik, Datenzugriff und Business Rules. AWS beschreibt, dass das zentrale Gateway User-Claims und Tool-Aktionen auswertet, während MCP-Server der Fachbereiche eingehende Tokens authentifizieren und ihr lokales Verhalten kontrollieren. Die AWS-Referenzarchitektur setzt somit auf mehrschichtige Authorization, nicht auf eine einzige allmächtige Gateway-Entscheidung.

Zum Schluss lehnst du Umgehungspfade ab. Positive Kontrollen definieren, was erlaubt ist. Negative Kontrollen definieren, was nicht passieren darf. AWS dokumentiert allowedWorkloadConfiguration; damit kann eine Runtime auf Anfragen beschränkt werden, deren Identity Chain ein zugelassenes AgentCore Gateway enthält. Das verringert das Risiko, dass ein Caller die Runtime direkt aufruft und die Gateway-Policy umgeht. Die AWS-Hinweise zur Authentifizierung und Security beschreiben diese Kontrolle.

Einfach gesagt: Lass nicht nur das Gateway hinein. Konfiguriere den nachgelagerten Service so, dass er Aufrufe ohne Gateway ablehnt, wenn das Gateway Teil deines Sicherheitsdesigns ist.

Was es nicht ist

Workload Identity Federation ist keine Network Segmentation. Netzwerkkontrollen können Verbindungen begrenzen, beweisen aber nicht kryptografisch, welcher Workload eine Anfrage erzeugt hat oder dass sie einen zugelassenen Vermittler passiert hat.

Sie ist auch nicht Capability Mediation. Capability Mediation begrenzt, welche Tools oder Aktionen ein Agent verwenden darf. Federated Identity liefert die authentifizierten Principals und Informationen zum Aufrufpfad, auf die solche Entscheidungen sich stützen können. Du brauchst beides: Eine echte Identität macht nicht jeden Tool-Aufruf angemessen.

Ebenso wenig garantiert sie, dass ein Agent eine gute Entscheidung getroffen hat. Ein Modell kann einen Nutzer missverstehen, bösartige Inhalte in einem Dokument befolgen oder eine schädliche, aber technisch autorisierte Aktion wählen. Identity beweist Herkunft und begrenzt Zugriff; semantische Authorization, Business Rules, Freigaben und Guardrails entscheiden weiterhin, ob die verlangte Operation sinnvoll ist.

Praktisches Beispiel: ein accountübergreifender Incident Assistant

Stell dir einen Incident Assistant für Operations Engineers vor. Er kann Service Health aus dem Production-Account, Kundenauswirkungen aus einem Support-Account und den Billing-Status aus einem Finance-Account lesen. Der Assistant soll Evidenz zusammenfassen, darf aber nicht allein auf eine Chat-Anfrage hin Rückerstattungen auslösen oder Production-Ressourcen ändern.

Ein praktikables Design beginnt mit engen MCP-Tools. Der Support-Server bietet ein schreibgeschütztes Lookup von Fällen. Der Production-Server liefert Status und Informationen zu jüngsten Deployments. Der Finance-Server bietet ein Lookup des Rechnungsstatus, keine generische Datenbankabfrage.

Wenn ein Engineer eine Frage stellt, sendet der Agent den User Context an das Gateway. Das Gateway prüft die User-Claims und entscheidet, ob das relevante Tool erlaubt ist. Anschließend ruft es einen MCP-Server mit seinem eigenen Machine Credential auf. Der Zielservice validiert dieses Credential, erkennt das Gateway als zugelassenen Workload und erzwingt seine lokale Regel: Vielleicht dürfen nur On-Call Engineers kontospezifische Details lesen, und kein Tool in diesem Workflow darf Daten verändern.

Entscheidend ist, dass ein Angreifer nicht denselben Pfad erhält, nur weil er den Endpunkt des Support-Servers entdeckt. Fordert der Server eine zugelassene Identity Chain mit dem Gateway, wird ein direkter Aufruf abgelehnt. User Authorization, Gateway Identity und die Policy des Services müssen zusammenpassen.

Das hilft auch im Betrieb. Ein Audit Record kann unterscheiden zwischen „der Nutzer forderte dieses Lookup an“, „das Gateway autorisierte dieses Tool“ und „der Finance-Service lieferte dieses Ergebnis“. Für Debugging und Incident Response sind das deutlich bessere Fakten als „das gemeinsame Agent-Credential rief Finance auf“.

Wo es scheitert

Der häufigste Fehler besteht darin, ein gültiges Credential mit einer vollständigen Authorization-Entscheidung zu verwechseln. Ein korrekt authentifiziertes Gateway kann trotzdem zum Confused Deputy werden: Es besitzt weitreichende Berechtigung und wird dazu gebracht, sie für den falschen Nutzer, das falsche Ziel oder die falsche Aktion einzusetzen. Policies müssen Nutzer, Workload, Zielservice, vorgesehene Operation, Tenant und Delegation Context zusammenbinden.

Das Weiterleiten von User-Tokens vergrößert außerdem den Schaden bei einem Leak. Prüfe Audience, Scope, Ablaufzeit und Replay-Verhalten. Logge keine rohen Credentials. Ein Token, das mehrere Services durchläuft, ist ein sicherheitsrelevantes Asset, keine harmlose Request-Metadaten.

Federation schafft Betriebsaufwand. Fremde Issuer oder Trust Bundles müssen onboarded werden; Schlüssel rotieren; Uhren driften; Issuer können ausfallen; und das Verhalten bei Revocation muss vor einem Incident klar sein. Ein System, das nur funktioniert, solange jeder Issuer erreichbar ist, kann gerade in dem Ausfall versagen, bei dem der Agent helfen soll.

Auch Portabilität hat Grenzen. Cloud-Plattformen und Identity Provider bieten unterschiedliche Semantik für Chains und Delegation. Das AWS-Feature für zugelassene Workloads ist ein nützlicher Beleg für das Muster, aber kein portabler Vertrag, den jeder MCP-Host implementiert. Definiere zuerst die benötigten Sicherheitseigenschaften und ordne sie dann den Mechanismen jeder Plattform zu.

Was du diese Woche tun kannst

Beginne mit einem Call-Path-Inventar für einen Agent-Workflow. Notiere für jeden Hop: auslösender Nutzer, aufrufender Workload, empfangender Workload, präsentiertes Credential, Issuer, Audience, delegierte Berechtigung und Policy-Entscheidung. Besteht dein Diagramm nur aus Pfeilen und API-Keys, ist es noch kein Identity-Design.

Wähle ein sensibles nachgelagertes Tool und mache die Verhinderung von Bypass-Aufrufen testbar. Probiere den zugelassenen Weg über das Gateway und einen ansonsten identischen direkten Aufruf. Letzterer sollte mit einem konkreten, beobachtbaren Identity- oder Authorization-Grund scheitern.

Trenne dann die Ownership von Policies. Platziere breite Tool Discovery und Routing über Domains an der Plattformgrenze, behalte aber lokale Business Authorization beim Service, dem die Daten gehören. Das senkt das Risiko, dass ein zentrales Plattformteam dauerhaft jede Regel einer Fachdomäne schreiben muss.

Füge schließlich zu normalen Agent-Evaluations auch Fälle für Identity-Fehler hinzu: abgelaufene Credentials, falsche Audience, unbekannter Issuer, fehlendes Gateway in der Chain, ein Nutzer mit Berechtigung für ein Tool, aber nicht für ein anderes, sowie direkte Service-Aufrufe. Agent-Reliability hängt nicht nur davon ab, ob das Modell ein plausibles Tool ausgewählt hat. Ebenso wichtig ist, ob jeder Service beweisen kann, dass die Anfrage über einen autorisierten Weg angekommen ist.