Amazon Bedrock: Token-Austausch für Multi-Tenant-Agenten eingeführt

Neue Funktion für Multi-Tenant-Agenten

Amazon Bedrock hat seinen AgentCore Gateway um eine Funktion erweitert, die den Identitätstransport in Multi-Tenant-Umgebungen neu regelt. Der „on-behalf-of“-Token-Exchange ermöglicht es einem generativen KI-Agenten, API-Aufrufe im Auftrag eines Benutzers durchzuführen, ohne dessen Authentifizierungstoken unverändert an nachgelagerte Systeme weiterzugeben. Der Gateway tauscht das Benutzertoken gegen ein Stellvertreter-Token, das die Benutzeridentität transportiert, aber nicht das ursprüngliche Token preisgibt. Die Funktion ist für Szenarien gedacht, in denen ein einzelner Agent mehrere Mandanten bedient und dabei auf externe Dienste zugreifen muss. Der Gateway übernimmt den Austausch und die Validierung der Token, sodass der Agent das ursprüngliche Token nicht direkt weiterleiten muss. Damit adressiert die Erweiterung das in der Amazon-Dokumentation beschriebene Architekturproblem, das bei der Skalierung von KI-Agenten in Multi-Tenant-Umgebungen auftritt.

Gelöstes Identitäts- und Auditproblem

Bisher mussten Entwickler bei Multi-Tenant-Agenten eine unbefriedigende Wahl treffen. Nutzten sie die Service-Identität des Agenten für API-Aufrufe, verschmolzen alle Nutzeraktionen in einem einzigen Audit-Log – die individuelle Nachverfolgbarkeit ging verloren, weil jeder nachgelagerte Dienst dem Agenten blind vertrauen musste. Leiteten sie hingegen das originale Benutzertoken unverändert weiter, entstand ein Confused-Deputy-Problem: Jeder nachgelagerte Dienst erhielt die vollen Zugriffsrechte des Endanwenders und musste darauf vertrauen, dass der Agent diese nicht zweckentfremdet. Beide Varianten sind in Umgebungen mit vielen Mandanten weder sicher noch revisionssicher skalierbar. Der neue „on-behalf-of“-Token-Exchange löst diesen Konflikt, indem der AgentCore Gateway als vertrauenswürdige Instanz das Benutzertoken entgegennimmt und gegen ein Stellvertreter-Token austauscht. Dieses Token kodiert die Identität des Nutzers, ohne das ursprüngliche Token preiszugeben. Dadurch bleibt in den Protokollen der nachgelagerten Systeme sichtbar, wer die Aktion ausgelöst hat – der Audit-Trail wird pro Nutzer erhalten. Gleichzeitig wird das Confused-Deputy-Risiko vermieden, weil die nachgelagerten Dienste nie das volle Benutzertoken sehen und der Agent es nicht weiterleiten muss.