Identità agente affidabile per l'azienda agente

Man mano che le aziende abbracciano il paradigma degli agenti, emerge una nuova sfida per la sicurezza: Come scorre l'identità dell'utente finale attraverso una rete di agenti AI autonomi? Nelle architetture API tradizionali, un utente esegue l'autenticazione una volta e l'applicazione chiama i servizi di backend per conto dell'utente. La catena dell'identità è breve, ben compresa e in genere gestita all'interno di un unico dominio Trust. Le architetture agentiche, tuttavia, sono caratterizzate da catene molto più lunghe in cui una singola richiesta viene inviata attraverso vari agenti, servizi e server MCP (Model Context Protocol), ciascuno dei quali potenzialmente supera i confini di servizio, domini Trust e persino i confini dell'organizzazione. Senza una strategia deliberata per la propagazione dell'identità, le aziende devono scegliere tra sicurezza e funzionalità, un dilemma che nessun architetto dovrebbe affrontare.

MuleSoft risolve le complessità della propagazione dell'identità con la sua funzione Trusted Agent Identity. Questa soluzione utilizza una strategia gestita dal gateway basata su policy per garantire il mantenimento dell'identità dell'utente finale in vari tipi di interazioni, inclusi protocolli A2A (Agent-to-Agent), chiamate a strumenti MCP e richieste API REST. Centralizzando la gestione dell'identità a livello di Flex Gateway tramite politiche di autenticazione in uscita, le aziende possono proteggere l'intera rete di agenti senza modificare i servizi di backend o gli agenti.

Questo documento descrive la sfida della propagazione dell'identità utilizzando una serie progressiva di scenari, ciascuno dei quali introduce ulteriore complessità. Insieme, questi scenari illustrano perché Trusted Agent Identity è un requisito fondamentale per qualsiasi distribuzione di agenti su scala aziendale.

In un'applicazione convenzionale, il flusso di identità (flusso JWT OAuth) è semplice: L'utente accede, riceve un token e l'applicazione utilizza il token per accedere alle risorse di backend. Il token è incorporato nell'identità dell'utente, inclusa la sua identità e le operazioni che è autorizzato a eseguire, e viaggia con ogni richiesta. La catena di chiamata è breve, in genere uno o due salti e la propagazione dell'identità viene risolta.

Le architetture agentiche, tuttavia, sono caratterizzate da catene di chiamata molto più lunghe in cui una singola richiesta utente può essere inoltrata in vari agenti, servizi di backend e server MCP (Model Context Protocol).Ogni destinazione della richiesta costituisce un salto separato. Mentre queste sfide, come la propagazione dell'identità multi-hop, i modelli di autorizzazione misti, i confini Trust tra domini diversi, sono comuni in qualsiasi configurazione API distribuita, ciò che è distinto è il modo in cui l'ecosistema corrente risponde per impostazione predefinita. Oggi, lo schema dominante per la comunicazione da agente ad agente e da agente ad API si basa sulle credenziali client, sulle chiavi API o sui segreti condivisi. Ciò significa:

L'identità dell'utente viene persa per impostazione predefinita. Quando un agente chiama un server MCP o un'API a valle utilizzando le credenziali client, la richiesta porta l'identità di servizio dell'agente e non quella dell'utente finale. Il servizio a valle non ha modo di sapere quale utente ha avviato l'azione, rendendo impossibile l'autorizzazione e gli itinerari di controllo per utente.
Le esigenze di autorizzazione miste vengono ignorate. Non tutti i servizi a valle richiedono contesto utente. Mentre alcuni gestiscono informazioni specifiche dell'utente come transazioni o portafogli, altri forniscono dati rivolti al pubblico o a livello di sistema come materiale di riferimento o tendenze del mercato.Poiché lo standard corrente si basa esclusivamente sulle credenziali del cliente, non è possibile distinguere tra queste esigenze o propagare selettivamente l'identità dell'utente solo quando necessario.
I confini del Cross-Domain Trust non sono risolti. Gli agenti negli scenari B2B e regolamentati potrebbero dover interagire con sistemi gestiti da provider di identità (IdP) completamente separati. Ad esempio, un sistema bancario esterno non è in grado di interpretare un token Single Sign-On (SSO) aziendale, ma deve comunque ricevere il consenso e l'intento dell'utente. Il flusso credenziali client non ha alcun meccanismo per questo.

Il risultato è un divario tra il requisito aziendale per l'accesso attribuibile agli utenti con privilegi minimi e la dipendenza dell'ecosistema attuale dall'autenticazione del livello di servizio priva di contesto utente. Colmare questa lacuna richiede un approccio deliberato e stratificato alla propagazione dell'identità. Per illustrare questi concetti, i seguenti scenari utilizzano Finport, un'applicazione fintech fittizia, per fornire esempi pratici di questi modelli architettonici.

Finport è un'applicazione Web di gestione del portafoglio Fintech rivolta ai consumatori basata su un'architettura ad agenti. Un broker agente (creato utilizzando MuleSoft Agent Broker) coordina più agenti a valle e server MCP per soddisfare le richieste degli utenti.

Finport espone tre funzionalità principali, ciascuna con un requisito distinto di identità:

"Mostrami il mio portfolio.": L'utente richiede le proprie partecipazioni personali e la cronologia delle transazioni. Poiché questi dati sono specifici dell'utente, l'agente dell'assistenza di portafoglio e il server MCP di portafoglio a valle devono sapere quali dati dell'utente restituire e devono verificare che l'utente sia autorizzato ad accedervi. L'identità dell'utente deve essere propagata attraverso ogni salto.
"Quali sono le attuali tendenze del mercato?": L'utente richiede i dati del mercato pubblico e i prezzi degli asset. Poiché i dati sono pubblici e non variano a seconda dell'utente, l'agente dati di mercato a valle e il server MCP Mercato asset non necessitano o prevedono un token con ambito utente. Le credenziali di servizio del broker sono sufficienti.
"Trasferire 5.000 dollari al mio conto di risparmio esterno.": L'utente avvia un trasferimento di fondi a una banca che utilizza un IdP diverso (ad esempio, Auth0 anziché Okta). Il token Finport dell'utente non ha alcun significato per il sistema della banca. L'utente deve eseguire l'autenticazione direttamente presso la banca (in linea all'interno della conversazione) prima che il trasferimento possa procedere.

Ciascuna di queste funzionalità viene mappata a uno schema di propagazione dell'identità diverso. Gli scenari seguenti si basano progressivamente su una base di riferimento standard (senza agenti) attraverso ogni schema distinto, illustrando in che modo le policy in uscita in Flex Gateway soddisfano ogni requisito senza modificare gli agenti o i servizi di backend.

Prima di introdurre gli agenti, è essenziale stabilire la base di riferimento: un utente che esegue l'autenticazione con un'applicazione client e accede a un servizio di backend.

Il flusso:

L'utente apre Finport e viene reindirizzato alla pagina di accesso dell'IdP (ad esempio, Okta).
L'utente esegue l'autenticazione (nome utente, password, SSO, autenticazione a più fattori (MFA) e qualsiasi altro requisito).
L'IdP emette un token di accesso JWT firmato all'applicazione Finport.
Finport ora dispone di un token utente che rappresenta l'identità dell'utente: chi è, quali ambiti sono stati concessi e quando scade il token. Può presentarlo a qualsiasi servizio a valle per conto di questo utente.

Cosa stabilisce questo: Questo processo segue lo schema dell'architettura OAuth 2.0 standard. Il token utente iniziale, convalidato da un IdP affidabile, funge da base essenziale per tutte le operazioni successive. Ogni scenario successivo si basa su questo token.

La domanda: Una volta autenticato, l'utente avvia azioni come trasferimenti di fondi, analisi di mercato o revisioni del portafoglio. Queste richieste vengono elaborate tramite un broker agente e possono coinvolgere più agenti a valle o server MCP. Ciò solleva interrogativi critici: Come viene mantenuta l'identità dell'utente in queste richieste distribuite? Che cosa accade quando un servizio a valle utilizza un IdP completamente diverso?

L'utente chiede all'agente Finport di "Mostrarmi il mio portfolio". Questa interazione attiva una catena di backend che inizia con il broker agente Finport, creato utilizzando MuleSoft Agent Broker. Il broker passa l'operazione a un agente dell'assistenza, che a sua volta esegue una query su un server MCP portafoglio. Il token di autenticazione iniziale dell'utente deve ora attraversare più salti per accedere ai record del portafoglio richiesti.

Il passaggio del token originale viola il principio dei privilegi minimi, mentre l'utilizzo di un account di servizio perde l'identità dell'utente.

L'agente Finport riceve il token dell'utente, ma non può semplicemente inoltrare lo stesso token all'agente dell'assistenza di portafoglio, poiché violerebbe il principio dei privilegi minimi e non circoscriverebbe correttamente la richiesta per il servizio a valle. Al contrario, l'utilizzo di un account di servizio comporta una totale perdita di identità utente. L'agente dell'assistenza di portafoglio e il server MCP di portafoglio non avrebbero modo di sapere quale portafoglio di utenti restituire e l'itinerario di controllo attribuirebbe ogni azione all'identità di servizio del broker anziché all'utente finale.

Flex Gateway risolve queste complessità di propagazione dell'identità in modo trasparente tramite la sua politica Outbound OAuth 2.0 Token Exchange. Questa soluzione intercetta le richieste in uscita a ogni passaggio della catena di chiamata, scambiando il token utente in entrata con l'IdP con una nuova credenziale specifica per il servizio a valle. La policy OBO (On-Behalf-Of) supporta sia il protocollo OAuth 2.0 Token Exchange (RFC 8693) che il protocollo Microsoft Entra ID On-Behalf-Of.

Principali vantaggi architettonici: L'intero processo è gestito dalla politica in uscita Flex Gateway. Il broker e gli agenti contengono logica di autenticazione zero. Si concentrano invece esclusivamente sulla logica aziendale, mentre il livello gateway impone la propagazione dell'identità.

Il flusso:

L'utente esegue l'autenticazione con Okta e l'applicazione Finport invia una richiesta tramite Flex Gateway.
Il broker riceve il token utente convalidato e determina che l'agente dell'assistenza di portafoglio è necessario.
La policy OBO in uscita di Flex Gateway scambia il token utente con l'IdP con un token limitato all'agente dell'assistenza di portafoglio.
L'agente dell'assistenza di portafoglio riceve un token con ambito appropriato e chiama il server MCP del portafoglio.
Flex Gateway scambia nuovamente il token, questa volta con ambito per il server MCP.
Il server MCP del portafoglio restituisce i dati specifici del portafoglio dell'utente.
Esiste un itinerario di controllo completo. Ogni luppolo è attribuibile all'utente finale originale.

Perché è importante: Senza lo scambio di token OBO, le aziende devono scegliere tra l'inoltro del token originale, che viola i privilegi minimi, e l'utilizzo degli account di servizio, che rischia di perdere l'identità dell'utente. Lo schema OBO elimina questo compromesso poiché l'identità dell'utente viene mantenuta a ogni salto, ogni token viene circoscritto alla sua destinazione e gli agenti stessi rimangono completamente all'oscuro della meccanica dell'identità.

Non tutti i servizi a valle richiedono il contesto dell'utente. L'utente chiede all'agente Finport: "Quali sono le attuali tendenze del mercato?" A differenza della richiesta di portafoglio nello scenario 1, i dati sulle tendenze di mercato sono pubblici quando non variano in base all'utente. Il Market Data Agent e il Server MCP Asset Market a valle non hanno bisogno o si aspettano un token con ambito utente.

La propagazione dei token utente dove non sono necessari espande la superficie di attacco.

Se Finport Agent Broker propagasse il token dell'utente al Market Data Agent utilizzando lo schema OBO dello scenario 1, funzionerebbe ma non sarebbe necessario. La propagazione dei token utente dove non sono necessari espande la superficie di attacco, crea dipendenze inutili dall'IdP per gli scambi di token e viola il principio dei privilegi minimi. L'agente dati di mercato deve semplicemente sapere che la richiesta proviene da un servizio autorizzato, non da quale utente lo chiede.

La politica Credenziali client OAuth 2.0 in uscita di Flex Gateway gestisce questo aspetto in modo trasparente. Anziché scambiare il token dell'utente, la policy inserisce le credenziali di servizio del broker tramite una grant credenziali client nella richiesta in uscita. L'agente dati di mercato a valle riceve un token del livello di servizio correttamente autenticato in cui non viene propagata l'identità dell'utente perché non è necessario.

Principali vantaggi architettonici: La strategia di propagazione dell'identità non è valida per tutti, ma viene determinata in base al percorso a valle in base alla natura dei dati e ai requisiti del servizio di destinazione. Le policy in uscita di Flex Gateway lo rendono configurabile per ogni percorso. Lo stesso broker agente Finport può partecipare sia ai flussi OBO (nello scenario 1) che ai flussi S2S senza alcuna modifica del codice. La configurazione della policy nel gateway di uscita determina quale schema si applica a quale chiamata a valle.

Il flusso:

L'utente chiede all'agente Finport: "Quali sono le attuali tendenze del mercato?"
Il broker determina che l'agente dati di mercato è necessario per soddisfare la richiesta.
La policy Credenziali client in uscita di Flex Gateway ottiene un token del livello di servizio utilizzando le credenziali del broker (nessun token utente viene scambiato o propagato).
Market Data Agent riceve una richiesta di servizio correttamente autenticata e chiama il server MCP Asset Market.
Il server MCP Asset Market restituisce i dati del mercato pubblico.
L'identità dell'utente non è presente nella catena per progettazione, poiché non è necessaria per questo tipo di dati.

Perché è importante: Il framework basato sulle policy di Flex Gateway consente agli architetti di selezionare il modello di identità ottimale per ogni interazione, risolvendo la difficile scelta tra la propagazione dei token utente universali, che aumenta i rischi generali e di sicurezza, e l'utilizzo degli account di servizio globali, che sacrifica il contesto e la conformità degli utenti.

Lo scenario di identità più complesso si verifica quando un agente deve interagire con un sistema governato da un IdP completamente diverso, che non riconosce il token utente esistente.

Lo scenario: L'utente Finport chiede all'agente Finport di "Trasferire 5.000 $ al mio conto di risparmio esterno". Questa richiesta prevede due percorsi a valle distinti:

Percorso OBO (Portfolio Service Agent) per verificare le partecipazioni dell'utente
Percorso dell'agente della transazione per eseguire il trasferimento effettivo

L'agente della transazione deve interagire con la banca dell'utente, che utilizza il proprio IdP. Il token Okta dell'utente da Finport non ha alcun significato per il sistema della banca, poiché la banca non ha alcuna relazione Trust con l'IdP di Finport. Né lo schema OBO (dallo scenario 1) né lo schema S2S (dallo scenario 2) possono risolvere questo problema. OBO scambia token all'interno dello stesso IdP e S2S utilizza credenziali di servizio che non contengono alcuna identità utente. La banca richiede all'utente di eseguire l'autenticazione direttamente con le proprie credenziali bancarie, inclusa potenzialmente la MFA.

La politica Codice di autorizzazione in attività A2A in uscita su Flex Gateway utilizza un meccanismo di risposta alle sfide all'interno della conversazione dell'agente. Se manca un token secondario quando si contatta la banca, la policy restituisce una richiesta di autenticazione. Questa sfida include tutti i dettagli necessari, ad esempio endpoint, ambiti e parametri PKCE, per consentire al cliente di avviare un flusso OAuth 2.0 con l'operatore bancario.

L'app Finport visualizza quindi l'accesso in linea della banca per l'autenticazione diretta dell'utente. Al termine, il client restituisce il token nella richiesta A2A. La policy estrae questo token per il sistema della banca e lo cancella dal corpo del messaggio per garantire la sicurezza.

Principali vantaggi architettonici: Il livello di policy gateway orchestra l'intero processo di autenticazione tra domini, assicurando che né il broker né gli agenti interagiscano con le credenziali non elaborate o richiedano Knowledge del provider di identità della banca. Utilizzando questo framework di risposta alle sfide, gli utenti mantengono il pieno controllo: forniscono il consenso esplicito per l'autenticazione con sistemi esterni, mentre il token risultante viene trasmesso in modo sicuro tramite il livello di policy.

Il flusso:

L'utente chiede a Finport di avviare un trasferimento. La richiesta passa attraverso il broker.
Il broker si espande, utilizzando il portafoglio (OBO) per verificare le partecipazioni e la transazione (in-task) per eseguire il trasferimento.
Il percorso della transazione attiva una richiesta di autenticazione dalla policy In-Task sul gateway Flex.
La sfida si propaga nuovamente all'applicazione Finport, che presenta il flusso di accesso della banca all'utente in linea.
L'utente esegue l'autenticazione presso la propria banca, inclusa la MFA se richiesta.
Il token bancario viene incluso nella successiva richiesta A2A. La policy la estrae, la imposta nell'intestazione Authorization e inoltra la richiesta.
Il server MCP transazione riceve la richiesta con il token della banca ed esegue il trasferimento.

Perché è importante: L'identità tra domini è una sfida importante nelle architetture agenti. Senza l'autenticazione in-task, le aziende devono pre-stabilire complesse relazioni Trust tra ogni IdPin della rete o chiedere agli utenti di fornire credenziali bancarie a un agente. Lo schema In-Task risolve questo problema consentendo l'autenticazione diretta degli utenti con provider esterni; la policy gestisce la meccanica dei token mantenendo gli agenti disaccoppiati dai domini di identità esterni.

In tutti e tre gli scenari, vale un unico principio architettonico: La propagazione dell'identità viene applicata a livello di gateway, non all'interno di agenti o servizi. Gli agenti e i server MCP contengono zero logica di autenticazione. Il loro ruolo è limitato all'elaborazione delle richieste autenticate e alla restituzione dei risultati, mentre il livello di policy in uscita Flex Gateway gestisce tutte le operazioni correlate all'identità.

Questo funziona perché le politiche di autenticazione Flex Gateway intercettano il traffico nel punto giusto: dopo che l'agente ha preso la decisione di instradamento, ma prima che la richiesta raggiunga il servizio a valle. La policy trasforma il token, sia che si tratti di un exchange OBO, di un'iniezione credenziali client o di una risposta di sfida, e inoltra una richiesta correttamente autenticata. Il servizio a valle non conosce mai la differenza, quindi l'agente non deve mai preoccuparsi. La logica di autenticazione è centralizzata al gateway, non sparsa tra i servizi. I servizi di backend non richiedono modifiche del codice e la stessa configurazione della policy può essere riutilizzata in più percorsi.

Questo approccio è anche agnostico del protocollo. Poiché le policy operano a livello HTTP, vengono applicate in modo coerente sia quando l'agente comunica tramite REST, MCP, A2A o webhook. Come documentato in Agent Fabric Deep Dive, tutto il traffico A2A e MCP viene instradato attraverso Flex Gateway per garantire che le policy vengano applicate su ogni endpoint, il che significa che la propagazione dell'identità viene applicata in modo uniforme indipendentemente dal protocollo di comunicazione.

Tre schemi componibili coprono l'intero spettro dei requisiti di identità in un'architettura agente:

Schema	Politica	Identità utente	Interazione dell'utente	Caso d'uso
Per conto (OBO)	Policy di iniezione credenziali OBO OAuth 2.0	Conservato	Nessuno (trasparente)	Dati specifici dell'utente all'interno dello stesso dominio Trust
Server a server (S2S)	Credibili client OAuth 2.0 in uscita	Non propagato	Nessuno	Dati pubblici, operazioni a livello di sistema
Codice di autorizzazione in attività	Codice di autorizzazione in uscita A2A	Principale + secondario	Obbligatorio (autenticazione in linea	Operazioni cross-domain, multi-identity-provider, ad alto rischio

Questi schemi non si escludono a vicenda. Come mostrano gli scenari Finport, un singolo broker agente può utilizzare OBO per una chiamata a valle, S2S per un'altra e In-Task per una terza. La configurazione della policy su ogni instradamento in uscita determina quale schema si applica. Non sono previste modifiche del codice agente e del servizio, solo policy.

Gli schemi imposti dal gateway descritti sopra proteggono le interazioni individuali, ma la propagazione dell'identità non è un problema isolato. È un livello fondamentale del modello di governance MuleSoft Agent Fabric più ampio. Come descritto in Agent Fabric Deep Dive, Agent Fabric si basa su quattro pilastri: Scoprire, orchestrare, governare e osservare, e ciascuno di essi dipende da una catena di identità affidabile per funzionare in modo efficace.

Scopri: Il Registro agenti cataloga gli agenti e le loro capacità. I metadati degli agenti, inclusi i requisiti di autenticazione, consentono ai broker di capire quali schemi di identità si aspettano ogni agente.
Orchestra: Agent Broker coordina i flussi di lavoro multi-agente. Flex Gateway gestisce in modo trasparente la trasformazione dell'identità a ogni salto, in modo che il broker possa concentrarsi sulla scomposizione e l'instradamento delle operazioni.
Governato: Tutto il traffico A2A e MCP viene instradato attraverso Flex Gateway, anche se il sistema di destinazione non è protetto, per garantire che le policy vengano applicate su ogni endpoint. Le policy di autenticazione in uscita fanno parte del livello di governance.
Osserva: Agent Visualizer offre un'osservabilità in tempo reale attraverso una mappa dinamica e interattiva delle interazioni degli agenti. Mantenendo l'identità dell'utente a ogni passaggio, le tracce e i registri offrono percorsi di controllo attribuibili agli utenti in tutta la rete degli agenti.

Senza una propagazione affidabile dell'identità, la governance è incompleta. È possibile catalogare e orchestrare gli agenti, ma non è possibile assicurarsi che agiscano entro i limiti dell'autorizzazione utente. Trusted Agent Identity colma questa lacuna, garantendo che la sicurezza e il contesto degli utenti rimangano centrali nei flussi di lavoro degli agenti.

Per implementare questi schemi:

Informazioni sull'elenco delle policy in uscita. Esaminare la serie completa di policy di autenticazione disponibili per Flex Gateway.
Inizia con OBO. La policy OAuth 2.0 Token Exchange risponde alle esigenze più comuni di propagazione dell'identità: preservare il contesto degli utenti tra i salti degli agenti.
Aggiunta di operazioni per scenari tra domini diversi: Quando la rete di agenti supera i limiti Trust, la politica A2A In-Task Authorization Code fornisce il meccanismo di risposta alle sfide per ottenere credenziali secondarie dall'utente.
Sfrutta tessuto agente. Definire la rete di agenti nello YAML rete agente con configurazioni di policy che specificano il modello di identità per percorso. La piattaforma gestisce il resto.

Per istruzioni dettagliate sull'implementazione, vedere la guida all'implementazione.

Nikhil Aggarwal è un ingegnere distinto di Salesforce, dove dirige l'architettura per MuleSoft e Salesforce Automation Clouds. Nikhil vanta oltre 18 anni di esperienza nella fornitura di prodotti su larga scala ed è appassionato di architettura scalabile, esperienze di sviluppo intuitive e creazione di team ad alte prestazioni. Prima di Salesforce, ha diretto diverse iniziative in Microsoft Power Platform, Dataverse e Office 365, dall'ideazione al lancio. Il suo lavoro continua a plasmare il modo in cui le aziende moderne connettono i sistemi, automatizzano i flussi di lavoro e sbloccano il valore aziendale nell'era dell'intelligenza artificiale.

Akash Trivedi è Direttore Ingegneria di Salesforce con oltre 18 anni di esperienza nella creazione di sistemi aziendali scalabili, sicuri e ad alte prestazioni. Lavora all'intersezione tra AI, architettura aziendale e intelligenza dei processi, con particolare attenzione alle piattaforme native cloud e alle soluzioni affidabili che operano su larga scala. Prima di Salesforce, ha ricoperto ruoli di ingegnere in Microsoft, dove ha contribuito a prodotti come Copilot, Dataverse e Power Platform.