Identität des vertrauenswürdigen Agenten für das Agentenunternehmen

Da Unternehmen das Agentenparadigma akzeptieren, stellt sich eine neue Sicherheitsherausforderung: Wie durchläuft die Endbenutzeridentität ein Netzwerk autonomer AI-Agenten? In traditionellen API-Architekturen authentifiziert sich ein Benutzer einmal und die Anwendung ruft Backend-Services im Namen des Benutzers auf. Die Identitätskette ist kurz, gut verstanden und wird in der Regel in einer einzelnen Trust Domäne verwaltet. Agentenarchitekturen weisen jedoch wesentlich längere Ketten auf, in denen eine einzelne Anforderung über verschiedene Agenten-, Service- und MCP-Server verteilt ist, wobei jeder potenziell Servicegrenzen, Trust Domänen und sogar Organisationsgrenzen überschreitet. Ohne eine bewusste Strategie zur Identitätsübermittlung stehen Unternehmen vor der Wahl zwischen Sicherheit und Funktionalität – ein Dilemma, mit dem kein Architekt konfrontiert werden sollte.

MuleSoft behebt die Komplexität der Identitätsübertragung mit der Funktion “Identität vertrauenswürdiger Agenten”. Diese Lösung nutzt eine richtlinienbasierte, Gateway-verwaltete Strategie, um sicherzustellen, dass die Identität der Endbenutzer über verschiedene Interaktionstypen hinweg erhalten bleibt – einschließlich A2A-Protokollen (Agent-zu-Agent), MCP-Toolaufrufen und REST-API-Anforderungen.Durch die Zentralisierung der Identitätsverwaltung auf Flex Gateway-Ebene über ausgehende Authentifizierungsrichtlinien können Unternehmen ihr gesamtes Agentennetzwerk schützen, ohne Backend-Services oder -Agenten zu ändern.

In diesem Dokument wird die Identitätsübernahme anhand einer progressiven Reihe von Szenarien beschrieben, die jeweils zusätzliche Komplexität mit sich bringen. Zusammen veranschaulichen diese Szenarien, warum Identität vertrauenswürdiger Agenten eine grundlegende Voraussetzung für die Bereitstellung von Agenten im Unternehmensmaßstab ist.

In einer herkömmlichen Anwendung ist der Identitäts-Flow (OAuth JWT-Flow) einfach: Der Benutzer meldet sich an, erhält ein Token und die Anwendung verwendet das Token für den Zugriff auf Backend-Ressourcen. Das Token ist in die Identität des Benutzers eingebettet, einschließlich dessen, wer er ist und wozu er autorisiert ist, und wird bei jeder Anforderung weitergeleitet. Die Anrufkette ist kurz, in der Regel ein oder zwei Hops, und die Identitätsübertragung ist gelöst.

Agentenarchitekturen verfügen jedoch über wesentlich längere Anrufketten, in denen eine einzelne Benutzeranforderung über verschiedene Agenten, Backend-Services und MCP-Server (Model Context Protocol) verteilt werden kann.Jedes Anforderungsziel stellt einen separaten Hop dar. Während diese Herausforderungen wie die Multi-Hop-Identitätsübernahme, gemischte Autorisierungsmodelle oder Cross-Domain Trust Grenzen bei jedem verteilten API-Setup üblich sind, unterscheidet sich die Art und Weise, wie das aktuelle Ökosystem standardmäßig reagiert. Heute basiert das dominante Muster für die Kommunikation zwischen Agenten und Agenten auf Client-Anmeldeinformationen, API-Schlüsseln oder gemeinsamen Geheimnissen. Das bedeutet:

Die Benutzeridentität geht standardmäßig verloren. Wenn ein Agent einen MCP-Server oder eine nachgelagerte API mit Client-Anmeldeinformationen aufruft, enthält die Anforderung die Serviceidentität des Agenten und nicht die des Endbenutzers. Der nachgelagerte Service kann nicht herausfinden, welcher Benutzer die Aktion initiiert hat, was Autorisierungs- und Überwachungsprotokolle pro Benutzer unmöglich macht.
Gemischte Autorisierungsanforderungen werden ignoriert. Nicht jeder nachgelagerte Service erfordert Benutzerkontext.Während einige benutzerspezifische Informationen wie Transaktionen oder Portfolios verwalten, stellen andere Daten auf öffentlicher Ebene oder auf Systemebene wie Referenzmaterial oder Markttrends bereit.Da der aktuelle Standard ausschließlich auf Client-Anmeldeinformationen basiert, gibt es keine Möglichkeit, zwischen diesen Anforderungen zu unterscheiden oder die Benutzeridentität nur bei Bedarf selektiv zu verbreiten.
Domänenübergreifende Trust Grenzen sind nicht adressiert. Agenten in B2B- und regulierten Szenarien müssen möglicherweise mit Systemen interagieren, die von vollständig separaten Identitätsanbietern (IdPs) verwaltet werden. Beispielsweise kann ein externes Banksystem kein Single Sign-On-Token (SSO) eines Unternehmens interpretieren, muss jedoch weiterhin die Einwilligung und den Intent des Benutzers erhalten. Der Flow für Client-Anmeldeinformationen weist dafür keinen Mechanismus auf.

Das Ergebnis ist eine Lücke zwischen der Unternehmensanforderung für benutzerattributbaren Zugriff mit den geringsten Berechtigungen und der Abhängigkeit des aktuellen Ökosystems von der Service Level Authentifizierung ohne Benutzerkontext. Um diese Lücke zu schließen, ist ein bewusster, mehrschichtiger Ansatz zur Identitätsübermittlung erforderlich. Zur Veranschaulichung dieser Konzepte verwenden die folgenden Szenarien Finport, eine fiktive Fintech-Anwendung, um praktische Beispiele für diese Architekturmuster bereitzustellen.

Finport ist eine fiktive Webanwendung für die Verwaltung des Fintech-Portfolios, die von einer Agentenarchitektur unterstützt wird. Ein Agentenmakler (mit MuleSoft Agent Broker erstellt) koordiniert mehrere nachgelagerte Agenten und MCP-Server, um Benutzeranforderungen zu erfüllen.

Finport stellt drei Kernfunktionen mit jeweils unterschiedlichen Identitätsanforderungen zur Verfügung:

“Zeige mir mein Portfolio.”: Der Benutzer fragt nach seinem persönlichen Besitz und seinem Transaktionsverlauf. Da diese Daten benutzerspezifisch sind, müssen der nachgelagerte Portfolio Serviceagent und der Portfolio-MCP-Server wissen, welche Benutzerdaten zurückgegeben werden sollen, und überprüfen, ob der Benutzer für den Zugriff darauf autorisiert ist. Die Benutzeridentität muss durch jeden Hop übernommen werden.
“Was sind die aktuellen Markttrends?”: Der Benutzer fordert öffentliche Marktdaten und Vermögenswertpreise an. Da die Daten öffentlich sind und nicht nach Benutzer variieren, benötigen oder erwarten der nachgelagerte Market Data Agent und der Asset Market MCP Server kein benutzerdefiniertes Token. Die eigenen Serviceanmeldeinformationen des Maklers sind ausreichend.
“Überweisen Sie 5.000 EUR auf mein externes Sparkonto.”: Der Benutzer initiiert eine Geldüberweisung an eine Bank, die einen anderen Identitätsanbieter verwendet (z. B. Auth0 anstelle von Okta). Das Finport-Token des Benutzers ist für das System der Bank bedeutungslos. Der Benutzer muss sich direkt bei der Bank authentifizieren (inline in der Unterhaltung), bevor die Übertragung fortgesetzt werden kann.

Jede dieser Funktionen wird einem anderen Identitätsübertragungsmuster zugeordnet. Die folgenden Szenarien werden schrittweise anhand einer Standardbasis (ohne Agenten) durch jedes unterschiedliche Muster erstellt und veranschaulichen, wie ausgehende Richtlinien in Flex Gateway jede Anforderung erfüllen, ohne die Agenten oder Backend-Services zu ändern.

Bevor Sie Agenten einführen, müssen Sie unbedingt die Grundlage festlegen: ein Benutzer, der sich bei einer Client-Anwendung authentifiziert und auf einen Backend-Service zugreift.

Der Flow:

Der Benutzer öffnet “Finport” und wird zur Anmeldeseite des Identitätsanbieters (z. B. “Okta”) umgeleitet.
Der Benutzer authentifiziert sich (Benutzername, Kennwort, SSO, Multi-Faktor-Authentifizierung (MFA) und alle anderen Anforderungen).
Der IdP stellt der Finport-Anwendung ein signiertes JWT-Zugriffstoken aus.
Finport verfügt nun über ein Benutzertoken, das die Identität des Benutzers darstellt: wer sie sind, welche Umfänge ihnen gewährt wurden und wann das Token abläuft. Sie kann sie jedem nachgelagerten Service im Namen dieses Benutzers präsentieren.

Was dadurch festgelegt wird: Dieser Prozess folgt dem OAuth 2.0-Standardarchitekturmuster. Das anfängliche Benutzertoken, das durch einen vertrauenswürdigen Identitätsanbieter validiert wird, dient als wesentliche Grundlage für alle nachfolgenden Vorgänge. Jedes nachfolgende Szenario basiert auf diesem Token.

Die Frage: Nach der Authentifizierung initiiert der Benutzer Aktionen wie Mittelübertragungen, Marktanalysen oder Portfolioüberprüfungen. Diese Anforderungen werden über einen Agentenbroker verarbeitet und können mehrere nachgelagerte Agenten oder MCP-Server umfassen. Dies wirft kritische Fragen auf: Wie wird die Identität des Benutzers in diesen verteilten Anforderungen beibehalten? Was geschieht, wenn ein nachgelagerter Service einen völlig anderen Identitätsanbieter verwendet?

Der Benutzer bittet den Finport-Agenten um “Zeige mir mein Portfolio”. Diese Interaktion löst eine Backend-Kette aus, die mit dem Finport-Agentenbroker beginnt und mit MuleSoft Agent Broker erstellt wurde. Der Makler übergibt die Aufgabe an einen Portfolio Serviceagenten, der wiederum einen Portfolio MCP Server abfragt. Das Token für die Erstauthentifizierung des Benutzers muss nun mehrere Hops durchlaufen, um auf die angeforderten Portfoliodatensätze zuzugreifen.

Die Weitergabe des ursprünglichen Tokens verstößt gegen das Prinzip der geringsten Berechtigung, während die Verwendung eines Serviceaccounts die Identität des Benutzers verliert.

Der Finportagent erhält das Token des Benutzers, kann dieses Token jedoch nicht einfach an den Portfolio Serviceagenten weiterleiten, da es gegen das Prinzip der geringsten Berechtigung verstoßen und die Anforderung für den nachgelagerten Service nicht ordnungsgemäß eingrenzen würde. Umgekehrt führt die Verwendung eines Serviceaccounts zu einem Totalverlust der Benutzeridentität. Der Portfolio Serviceagent und der Portfolio-MCP-Server hätten keine Möglichkeit, zu erfahren, welcher Benutzer das Portfolio zurückgeben soll, und der Überprüfungsprotokoll würde jede Aktion der Serviceidentität des Maklers und nicht dem Endbenutzer zuordnen.

Flex Gateway löst diese Komplexitäten der Identitätsübertragung durch seine Richtlinie “Ausgehender OAuth 2.0-Tokenaustausch” transparent auf. Diese Lösung fängt ausgehende Anforderungen bei jedem Hop in der Anrufkette ab und tauscht das eingehende Benutzertoken mit dem Identitätsanbieter gegen neue Anmeldeinformationen aus, die speziell für den nachgelagerten Service gelten. Die On-Behalf-Of-Richtlinie (OBO) unterstützt sowohl die Protokolle “OAuth 2.0 Token Exchange (RFC 8693)” als auch “Microsoft Entra ID On-Behalf-Of”.

Wichtiger architektonischer Vorteil: Dieser gesamte Prozess wird von der Flex Gateway-Ausgangsrichtlinie verarbeitet. Der Makler und die Agenten enthalten eine Authentifizierungslogik von null. Stattdessen konzentrieren sie sich ausschließlich auf Geschäftslogik, während die Gateway-Ebene die Identitätsübertragung erzwingt.

Der Flow:

Der Benutzer authentifiziert sich bei Okta und die Finport-Anwendung sendet eine Anforderung über Flex Gateway.
Der Makler erhält das validierte Benutzertoken und bestimmt, ob der Portfolio Serviceagent benötigt wird.
Die ausgehende OBO-Richtlinie von Flex Gateway tauscht das Benutzertoken mit dem Identitätsanbieter gegen ein Token aus, das für den Portfolio Serviceagenten gilt.
Der Portfolio Serviceagent erhält ein Token mit ordnungsgemäßem Umfang und ruft den Portfolio-MCP-Server auf.
Flex Gateway tauscht das Token erneut aus, diesmal mit dem Umfang für den MCP-Server.
Der Portfolio-MCP-Server gibt die spezifischen Portfoliodaten des Benutzers zurück.
Es ist ein vollständiger Prüfpfad vorhanden. Jeder Hop ist dem ursprünglichen Endbenutzer zuzuordnen.

Warum dies wichtig ist: Ohne OBO-Token-Austausch müssen Unternehmen zwischen der Weiterleitung des ursprünglichen Tokens, das gegen die geringsten Berechtigungen verstößt, oder der Verwendung von Serviceaccounts, bei denen die Gefahr besteht, dass die Benutzeridentität verloren geht, wählen. Durch das OBO-Muster wird dieser Kompromiss beseitigt, da die Identität des Benutzers bei jedem Hop beibehalten wird, jedes Token auf sein Ziel begrenzt wird und die Agenten selbst die Identitätsmechanik nicht kennen.

Nicht jeder nachgelagerte Service erfordert Benutzerkontext. Der Benutzer fragt den Finport-Agenten: “Was sind die aktuellen Markttrends?” Im Gegensatz zur Portfolioanforderung in Szenario 1 sind Markttrenddaten öffentlich, wenn sie nicht je nach Benutzer variieren. Der nachgelagerte Marktdatenagent und der Vermögenswertmarkt-MCP-Server benötigen oder erwarten kein benutzerdefiniertes Token.

Durch die Übernahme von Benutzertoken, wo sie nicht benötigt werden, wird die Angriffsfläche erweitert.

Wenn der Finport-Agenten-Broker das Token des Benutzers mithilfe des OBO-Musters aus Szenario 1 an den Marktdatenagenten weiterleitet, funktioniert dies, wäre jedoch unnötig. Die Übernahme von Benutzertoken, wo sie nicht benötigt werden, erweitert die Angriffsfläche, schafft unnötige Abhängigkeiten vom Identitätsanbieter für Token-Austausche und verstößt gegen das Prinzip der geringsten Berechtigung. Der Marktdatenagent muss lediglich wissen, dass die Anforderung von einem autorisierten Service stammt und nicht, welcher Benutzer danach fragt.

Die Richtlinie “Ausgehende OAuth 2.0-Clientanmeldeinformationen” von Flex Gateway behandelt dies transparent. Anstatt das Token des Benutzers auszutauschen, fügt die Richtlinie die eigenen Serviceanmeldeinformationen des Maklers über eine Client-Anmeldeinformationsgewährung in die ausgehende Anforderung ein. Der nachgelagerte Marktdatenagent erhält ein ordnungsgemäß authentifiziertes Service Level Token, bei dem keine Benutzeridentität übernommen wird, da keine benötigt wird.

Wichtiger architektonischer Vorteil: Die Identitätsübertragungsstrategie ist nicht universell, sondern wird pro nachgelagerter Route basierend auf der Art der Daten und den Anforderungen des Zielservice bestimmt. Durch die ausgehenden Richtlinien von Flex Gateway kann dies pro Route konfiguriert werden. Derselbe Finportagent-Broker kann ohne Codeänderungen an OBO-Flows (in Szenario 1) und S2S-Flows teilnehmen. Die Richtlinienkonfiguration im Gateway für den Ausgang bestimmt, welches Muster für welchen nachgelagerten Aufruf gilt.

Der Flow:

Der Benutzer fragt den Finport-Agenten: “Was sind die aktuellen Markttrends?”
Der Makler bestimmt, dass der Marktdatenagent zum Erfüllen der Anforderung benötigt wird.
Die Richtlinie für ausgehende Client-Anmeldeinformationen von Flex Gateway ruft ein Servicelevel-Token mit den eigenen Anmeldeinformationen des Maklers ab (kein Benutzertoken wird ausgetauscht oder übernommen).
Der Marktdatenagent erhält eine ordnungsgemäß authentifizierte Serviceanforderung und ruft den Vermögenswertmarkt-MCP-Server auf.
Der Vermögenswertmarkt-MCP-Server gibt die öffentlichen Marktdaten zurück.
Es ist keine Benutzeridentität in der Kette vorhanden, da für diesen Datentyp keine benötigt wird.

Warum dies wichtig ist: Mit dem richtliniengesteuerten Framework von Flex Gateway können Architekten das optimale Identitätsmodell für jede Interaktion auswählen. Dadurch wird die schwierige Wahl zwischen universeller Benutzertoken-Übertragung – was die Overhead- und Sicherheitsrisiken erhöht – und globaler Serviceaccount-Nutzung, die den Benutzerkontext und die Compliance beeinträchtigt, gelöst.

Das komplexeste Identitätsszenario tritt auf, wenn ein Agent mit einem System interagieren muss, das von einem völlig anderen IdP gesteuert wird, einem System, das das vorhandene Benutzertoken nicht erkennt.

Das Szenario: Der Finport-Benutzer bittet den Finport-Agenten, 5.000 EUR auf mein externes Sparkonto zu überweisen. Diese Anforderung umfasst zwei unterschiedliche nachgelagerte Pfade:

Pfad ‘Portfolio Serviceagent (OBO)’ zum Überprüfen der Bestände des Benutzers
Der Pfad Transaktionsagent → Transaktions-MCP-Server → Bank des Benutzers zum Ausführen der tatsächlichen Übertragung

Der Transaktionsagent muss mit der Bank des Benutzers interagieren, die seinen eigenen Identitätsanbieter verwendet. Das Okta-Token des Benutzers aus Finport ist für das System der Bank bedeutungslos, da die Bank keine Trust Beziehung zum Identitätsanbieter von Finport hat. Weder das OBO-Muster (aus Szenario 1) noch das S2S-Muster (aus Szenario 2) können dies lösen. OBO tauscht Token innerhalb desselben Identitätsanbieters aus und S2S verwendet Serviceanmeldeinformationen, die keinerlei Benutzeridentität enthalten. Die Bank fordert den Benutzer auf, sich direkt mit seinen eigenen Bankanmeldeinformationen zu authentifizieren, möglicherweise einschließlich MFA.

Die Richtlinie “Ausgehender A2A-Autorisierungscode für Aufgaben” für Flex Gateway verwendet einen Mechanismus für die Abfrageantwort in der Agentenunterhaltung. Wenn beim Kontaktieren der Bank ein sekundäres Token fehlt, gibt die Richtlinie eine für die Authentifizierung erforderliche Abfrage zurück. Diese Herausforderung enthält alle erforderlichen Details wie Endpunkte, Umfänge und PKCE-Parameter, damit der Client einen OAuth 2.0-Flow beim Anbieter der Bank initiieren kann.

Die Finport-Anwendung zeigt dann die Anmeldung der Bank inline für die direkte Benutzerauthentifizierung an. Nach Abschluss gibt der Client das Token in der A2A-Anforderung zurück. Die Richtlinie extrahiert dieses Token für das System der Bank und entfernt es aus dem Nachrichtentext, um die Sicherheit zu gewährleisten.

Wichtiger architektonischer Vorteil: Die Gateway-Richtlinienebene orchestriert den gesamten domänenübergreifenden Authentifizierungsprozess und stellt sicher, dass weder der Makler noch die Agenten jemals mit Rohanmeldeinformationen interagieren oder Knowledge über den Identitätsanbieter der Bank benötigen. Mithilfe dieses Frameworks für Herausforderungsantworten behalten Benutzer die vollständige Kontrolle über: Sie erteilen ausdrückliche Zustimmung zur Authentifizierung bei externen Systemen, während das resultierende Token sicher über die Richtlinienebene übertragen wird.

Der Flow:

Der Benutzer bittet Finport, eine Übertragung zu initiieren. Die Anforderung fließt über den Makler.
Der Makler wird aufgefächert und verwendet das Portfolio (OBO) zum Überprüfen von Beteiligungen und die Transaktion (in Aufgabe) zum Ausführen der Übertragung.
Der Transaktionspfad löst eine für die Authentifizierung erforderliche Abfrage über die Richtlinie “In Aufgabe” im Flex Gateway aus.
Die Herausforderung wird zurück in die Finport-Anwendung übertragen, die dem Benutzer den Anmelde-Flow der Bank inline anzeigt.
Der Benutzer authentifiziert sich bei seiner Bank, einschließlich der MFA, falls erforderlich.
Das Banktoken ist in der nachfolgenden A2A-Anforderung enthalten. Die Richtlinie extrahiert sie, legt sie in der Autorisierungskopfzeile fest und leitet die Anforderung weiter.
Der Transaktions-MCP-Server empfängt die Anforderung mit dem Token der Bank und führt die Übertragung aus.

Warum dies wichtig ist: Die domänenübergreifende Identität ist eine große Herausforderung in Agentenarchitekturen. Ohne die Authentifizierung innerhalb der Aufgabe müssen Unternehmen entweder komplexe Trust Relationships zwischen jedem IdPin im Netzwerk vorab einrichten oder Benutzer bitten, einem Agenten Bankanmeldeinformationen bereitzustellen. Das Muster “In Aufgabe” löst dies, indem die direkte Benutzerauthentifizierung bei externen Anbietern zugelassen wird. Die Richtlinie verwaltet die Token-Mechanik und sorgt gleichzeitig dafür, dass Agenten von externen Identitätsdomänen getrennt bleiben.

In allen drei Szenarien gilt ein einziges Architekturprinzip: Die Identitätsübertragung wird auf Gateway-Ebene erzwungen, nicht innerhalb von Agenten oder Services. Die Agenten und MCP-Server enthalten Nullauthentifizierungslogik. Ihre Rolle beschränkt sich auf die Verarbeitung authentifizierter Anforderungen und die Rückgabe von Ergebnissen, während die ausgehende Flex Gateway-Richtlinienebene alle identitätsbezogenen Vorgänge verwaltet.

Dies funktioniert, da die ausgehenden Authentifizierungsrichtlinien von Flex Gateway den Datenverkehr an der richtigen Stelle abfangen: nachdem der Agent seine Weiterleitungsentscheidung getroffen hat, aber bevor die Anforderung den nachgelagerten Service erreicht. Die Richtlinie wandelt das Token um – unabhängig davon, ob es sich um einen OBO-Austausch, eine Injektion von Clientanmeldeinformationen oder eine Antwort auf eine Herausforderung handelt – und leitet eine ordnungsgemäß authentifizierte Anforderung weiter. Der nachgelagerte Service kennt den Unterschied nie, daher muss sich der Agent nie darum kümmern. Die Authentifizierungslogik ist zentral im Gateway und nicht über Services verstreut. Die Backend-Services erfordern keine Codeänderungen und dieselbe Richtlinienkonfiguration kann über mehrere Routen hinweg wiederverwendet werden.

Dieser Ansatz ist ebenfalls protokollagnostisch. Da die Richtlinien auf HTTP-Ebene funktionieren, werden sie konsistent angewendet, unabhängig davon, ob der Agent über REST, MCP, A2A oder Webhooks kommuniziert. Wie im Agent Fabric Deep Dive dokumentiert, wird der gesamte A2A- und MCP-Datenverkehr über das Flex Gateway geleitet, um sicherzustellen, dass Richtlinien auf jeden Endpunkt angewendet werden, was bedeutet, dass die Identitätsübertragung unabhängig vom Kommunikationsprotokoll einheitlich erzwungen wird.

Drei zusammengesetzte Muster decken das gesamte Spektrum der Identitätsanforderungen in einer Agentenarchitektur ab:

Muster	Police	Benutzeridentität	Benutzerinteraktion	Anwendungsfall
Im Namen von (OBO)	OAuth 2.0-Richtlinie für die Eingabe von OBO-Anmeldeinformationen	Beibehalten	Keine (transparent)	Benutzerspezifische Daten innerhalb derselben Trust Domäne
Server-zu-Server (S2S)	Ausgehende OAuth 2.0-Client-Anmeldeinformationen	Nicht propagiert	Keine	Öffentliche Daten, Vorgänge auf Systemebene
Autorisierungscode für Aufgaben	Ausgehender A2A-Autorisierungscode für Aufgaben	Primär + Sekundär	Erforderlich (Inline-Authentifizierung)	Domänenübergreifende Vorgänge mit mehreren Identitäten und hohem Risiko

Diese Muster schließen sich nicht gegenseitig aus. Wie die Finport-Szenarien zeigen, kann ein einzelner Agentenmakler OBO für einen nachgelagerten Anruf, S2S für einen anderen und In-Task für einen dritten verwenden. Die Richtlinienkonfiguration für jede ausgehende Route bestimmt, welches Muster zutrifft. Es gibt keine Änderungen am Agentencode und keine Serviceänderungen, sondern nur Richtlinien.

Die oben beschriebenen Gateway-erzwungenen Muster schützen einzelne Interaktionen, die Identitätsübertragung ist jedoch kein isoliertes Problem. Es ist eine grundlegende Ebene des umfassenderen MuleSoft Agent Fabric-Governance-Modells. Wie im Agent Fabric Deep Dive beschrieben, basiert Agent Fabric auf vier Säulen: Ermitteln, Orchestrieren, Verwalten und Beobachten – und jede davon ist von einer zuverlässigen Identitätskette abhängig, damit sie effektiv funktioniert.

Entdecken: Die Agentenregistrierung katalogisiert Agenten und ihre Funktionen. Mithilfe von Agentenmetadaten, einschließlich Authentifizierungsanforderungen, können Makler nachvollziehen, welche Identitätsmuster die einzelnen Agenten erwarten.
Orchestrieren: Der Agentenmakler koordiniert Workflows mit mehreren Agenten. Flex Gateway verarbeitet die Identitätstransformation bei jedem Hop transparent, sodass sich der Makler auf die Aufgabenaufschlüsselung und -weiterleitung konzentrieren kann.
Regieren: Der gesamte A2A- und MCP-Datenverkehr wird über Flex Gateway weitergeleitet, selbst wenn das Zielsystem nicht sicher ist, um sicherzustellen, dass Richtlinien auf jeden Endpunkt angewendet werden. Richtlinien für die ausgehende Authentifizierung sind Teil der Governance-Ebene.
Beobachten: Agent Visualizer bietet Echtzeit-Beobachtbarkeit durch eine dynamische, interaktive Karte von Agenteninteraktionen. Da die Benutzeridentität bei jedem Hop erhalten bleibt, bieten Verfolgungen und Protokolle benutzerattributierbare Überwachungsprotokolle im gesamten Agentennetzwerk.

Ohne die Übernahme vertrauenswürdiger Identitäten ist die Verwaltung unvollständig. Sie können Agenten katalogisieren und orchestrieren, jedoch nicht sicherstellen, dass sie innerhalb der Grenzen der Benutzerautorisierung handeln. Trusted Agent Identity schließt diese Lücke und stellt sicher, dass Sicherheit und Benutzerkontext für Agenten-Workflows zentral bleiben.

Implementieren dieser Muster:

Kennen Sie das Verzeichnis der ausgehenden Policen. Überprüfen Sie den vollständigen Satz der für Flex Gateway verfügbaren ausgehenden Authentifizierungsrichtlinien.
Beginnen Sie mit OBO. Die OAuth 2.0-Tokenaustauschrichtlinie erfüllt die häufigsten Anforderungen an die Identitätsübertragung: Beibehalten des Benutzerkontexts in allen Agenten-Hops.
Hinzufügen von Aufgaben für domänenübergreifende Szenarien: Wenn Ihr Agentennetzwerk Trust Grenzen überschreitet, bietet die A2A In-Task Authorization Code-Richtlinie den Mechanismus für die Abfrageantwort, um sekundäre Anmeldeinformationen vom Benutzer abzurufen.
Agentengewebe nutzen. Definieren Sie Ihr Agentennetzwerk in der Agenten-Netzwerk-YAML mit Richtlinienkonfigurationen, die das Identitätsmodell pro Route angeben. Den Rest erledigt die Plattform.

Ausführliche Implementierungshinweise finden Sie im Companion Implementation Guide.

Nikhil Aggarwal ist Distinguished Engineer bei Salesforce, wo er die Architektur für MuleSoft und Salesforce Automation Clouds leitet. Nikhil verfügt über mehr als 18 Jahre Erfahrung in der Bereitstellung von Produkten im großen Stil und ist begeistert von skalierbarer Architektur, intuitiven Entwicklererfahrungen und dem Aufbau leistungsstarker Teams. Vor Salesforce leitete er mehrere Initiativen in Microsoft Power Platform, Dataverse und Office 365 vom Konzept bis zur Einführung. Seine Arbeit prägt weiterhin, wie moderne Unternehmen Systeme verbinden, Workflows automatisieren und Geschäftswerte im Zeitalter der AI-Ersten nutzen.

Akash Trivedi ist Director of Engineering bei Salesforce und verfügt über mehr als 18 Jahre Erfahrung in der Entwicklung skalierbarer, sicherer und leistungsstarker Unternehmenssysteme. Er arbeitet an der Schnittstelle von AI, Unternehmensarchitektur und Prozessintelligenz und konzentriert sich auf Cloud-native Plattformen und zuverlässige Lösungen, die skaliert funktionieren. Vor Salesforce war er als Ingenieur bei Microsoft tätig, wo er an Produkten wie Copilot, Dataverse und Power Platform mitwirkte.