Gemeinsam genutzte API-Schlüssel und Servicekonten verwischen den Unterschied zwischen einzelnen Agenten und den Personen, die hinter einer Anfrage stehen. In den Protokollen erscheint ein Zugangsschlüssel, nicht aber der Agent oder die Supportkraft, die im Auftrag eines Kunden handelt. Bei geringem Umfang ist das nur lästig, im Unternehmensmaßstab jedoch gefährlich. Nicht zuordenbare Änderungen an Abrechnungen, Krankenakten oder Infrastruktur schaffen Compliance-Lücken, erschweren die forensische Aufarbeitung von Vorfällen und erzwingen übermäßig großzügige Richtlinien, die das Risiko erhöhen.

In Arbeitsabläufen mit mehreren Agenten geht es häufig über Orchestratoren und Tool-Agenten zu MCP-Servern. Ohne die Weitergabe der Identität muss das Zielsystem entweder dem zwischengeschalteten Dienst vertrauen oder die Anfrage ablehnen. Agent Identity unterstützt die Token-Weitergabe, wenn nachgelagerte Systeme dem ursprünglichen Token vertrauen, OAuth2-Client-Anmeldedaten, wenn der Agent für sich selbst handeln muss, und OBO-Austausch, bei dem ein Token entsteht, das den „Agenten im Auftrag des Benutzers“ repräsentiert. So kann das führende System die korrekten benutzerspezifischen Berechtigungen anwenden, ohne die Agenten ändern zu müssen.

Eine Identität ist nur dann nützlich, wenn sich mit ihr auch Berechtigungen durchsetzen lassen. TrueFoundry hinterlegt für jeden Agenten Zulassungslisten (für Benutzer, Teams, Apps und andere Agenten) sowie Egress-Berechtigungen für Modelle, MCP-Server und Dienste. Wird eine Berechtigung entzogen, antwortet das Gateway sofort mit dem Statuscode 403. Durch die zentrale Verwaltung dieser Kontrollen vermeidet ihr fragile, mehrfach implementierte Zugriffslogik in Agenten und erhaltet eine zentrale Stelle, an der sich Berechtigungen prüfen, entziehen und bei verändertem Umfang oder Risiko verschärfen lassen.

TrueFoundry unterstützt verschiedene Identitätsmodelle: von TrueFoundry ausgestellte Tokens für einen schnellen Einstieg oder IdP-gestützte Identitäten, die Subject-Claims in Okta, Entra oder einem beliebigen OIDC-Anbieter zugeordnet werden. Auch die SigV4-Signierung für AWS-Abläufe wird unterstützt. Agenten können überall ausgeführt und trotzdem verwaltet werden: Bei proxied Agenten werden Richtlinien für eingehende Anfragen durchgesetzt, bei eingebetteten Agenten die Governance ausgehender Zugriffe. Teams können schrittweise vorgehen – zunächst besonders risikoreiche Agenten registrieren und die Abdeckung anschließend erweitern, ohne die Bereitstellungen grundlegend umzubauen.

Die Zentralisierung von Identitäten am Gateway bündelt auch Risiken: Token-Austausch, Caching und Berechtigungsentzug werden zu kritischen Infrastrukturkomponenten. Rechnet mit zusätzlichem Betriebsaufwand, etwa für die Überwachung des Token-Lebenszyklus, die Skalierung des Gateways und die Absicherung der Austauschpfade. Bewertet außerdem Latenz und Fehlerszenarien bei OBO-Abläufen und SigV4-Signierung unter Last. TrueFoundry begegnet vielen dieser Herausforderungen mit Token-Caching, Aktualisierungslogik und OpenTelemetry-Tracing. Plattformteams müssen das Gateway jedoch in ihre SLOs und Notfallpläne aufnehmen.