Betrodd agentidentitet för agentföretaget

När företag omfamnar det agentiska paradigmet uppstår en ny säkerhetsutmaning: Hur flödar slutanvändarens identitet genom ett nätverk av autonoma AI-agenter? I traditionella API-arkitekturer autentiserar en användare en gång och programmet anropar backendtjänster åt användaren. Identitetskedjan är kort, lättförståelig och hanteras vanligtvis inom en enskild Trust domän. Agentarkitekturer har dock mycket längre kedjor där en enskild begäran skickas ut över olika agenter, tjänster och Model Context Protocol-servrar (MCP), var och en potentiellt över servicegränser, Trust domäner och till och med organisationsgränser. Utan en medveten strategi för identitetspropagering står företag inför ett val mellan säkerhet och funktionalitet – ett dilemma som ingen arkitekt ska behöva möta.

MuleSoft hanterar komplexiteten i identitetspropagering med sin funktion Betrodd agentidentitet. Denna lösning använder en policybaserad, gatewayhanterad strategi för att säkerställa att slutanvändarens identitet upprätthålls över olika interaktionstyper—inklusive agent-till-agent-protokoll (A2A), MCP-verktygsanrop och REST API-begäranden.Genom att centralisera identitetshantering på Flex Gateway-lagret genom utgående autentiseringspolicyer kan företag säkra hela sitt agentnätverk utan att ändra backendtjänster eller agenter.

Detta dokument går igenom utmaningen för identitetspropagering med hjälp av en progressiv serie scenarion, vart och ett med ytterligare komplexitet. Tillsammans illustrerar dessa scenarion varför Betrodd agentidentitet är ett grundläggande krav för agentdistribuering i företagsskala.

I ett konventionellt program är identitetsflödet (OAuth JWT-flödet) enkelt: Användaren loggar in, får en token och programmet använder token för att komma åt backendresurser. Token är inbäddad med användarens identitet – inklusive vem de är och vad de är auktoriserade att göra – och reser med varje begäran. Samtalskedjan är kort, vanligtvis ett eller två hopp, och identitetspropagering löses.

Agentarkitekturer har dock mycket längre anropskedjor där en enskild användarbegäran kan spridas över olika agenter, backendtjänster och Model Context Protocol-servrar (MCP).Varje begärandedestination utgör en separat hop. Även om dessa utmaningar – till exempel identitetspropagering med flera hopp, modeller med blandad auktorisering och gränser för cross-domain Trust – är vanliga i alla distribuerade API-konfigurationer, är det som skiljer sig åt hur det nuvarande ekosystemet svarar som standard. Idag är det dominerande mönstret för agent-till-agent och agent-till-API-kommunikation beroende av klientuppgifter, API-nycklar eller delade hemligheter. Detta innebär:

Användaridentitet förloras som standard. När en agent anropar en MCP-server eller API längre ner med klientuppgifter bär begäran agentens tjänsteidentitet och inte slutanvändarens. Tjänsten längre ner kan inte veta vilken användare som initierade åtgärden, vilket gör det omöjligt att godkänna och granska varje användare.
Blandade auktoriseringsbehov ignoreras. Inte alla tjänster längre ner kräver användarsammanhang.Även om vissa hanterar användarspecifik information som transaktioner eller portföljer tillhandahåller andra data på offentlig nivå eller systemnivå som referensmaterial eller marknadstrender.Eftersom den nuvarande standarden uteslutande förlitar sig på klientuppgifter finns det inget sätt att skilja mellan dessa behov eller att selektivt propagera användaridentitet endast vid behov.
Cross-Domain Trust-gränser har inte åtgärdats. Agenter i B2B och reglerade scenarion kan behöva interagera med system som styrs av helt separata identitetsleverantörer (IdP). Till exempel kan ett externt banksystem inte tolka en företagstoken för enkel inloggning (SSO), men det måste fortfarande få användarens samtycke och syfte. Flödet för klientuppgifter har ingen mekanism för detta.

Resultatet är en klyfta mellan företagskravet för användartillskrivbar åtkomst med minst privilegier och det nuvarande ekosystemets beroende av servicenivåautentisering som saknar användarsammanhang. Att överbrygga detta mellanrum kräver en medveten, skiktad strategi för identitetspropagering. För att illustrera dessa koncept använder följande scenarion Finport, ett fiktivt fintech-program, för att ge praktiska exempel på dessa arkitektoniska mönster.

Finport är ett fiktivt webbprogram för portföljhantering för konsumenter som backas upp av en agentarkitektur. En agentmäklare (byggd med MuleSoft Agent Broker) koordinerar flera agenter och MCP-servrar längre ner för att uppfylla användarförfrågningar.

Finport visar tre kärnfunktioner, var och en med ett tydligt identitetskrav:

“Visa mig min portfolio.” Användaren begär sina personliga innehav och transaktionshistorik. Eftersom dessa data är användarspecifika måste Portfolio Serviceagent och Portfolio MCP Server längre ner veta vilken användares data som ska returneras och verifiera att användaren har behörighet att få åtkomst till dem. Användaridentitet måste propageras genom varje hopp.
“Vilka är de aktuella marknadstrenderna?”: Användaren begär offentliga marknadsdata och tillgångspriser. Eftersom data är offentliga och inte varierar beroende på användare behöver eller förväntar sig inte Market Data Agent och Asset Market MCP Server en token med användaromfång längre ner. Mäklarens egna serviceuppgifter är tillräckliga.
“Överför 5 000 dollar till mitt externa sparkonto.”: Användaren inleder en fondöverföring till en bank som använder en annan IdP (till exempel Auth0 istället för Okta). Användarens Finport-token är meningslös för bankens system. Användaren måste autentisera sig direkt med banken (inbäddat i konversationen) innan överföringen kan fortsätta.

Var och en av dessa funktioner mappar till olika identitetspropageringsmönster. Följande scenarion bygger progressivt från en standardbaslinje (utan agenter) genom varje distinkt mönster, vilket illustrerar hur utgående policyer i Flex Gateway hanterar varje krav utan att ändra agenterna eller backendtjänsterna.

Innan du introducerar agenter är det viktigt att etablera baslinjen: en användare som autentiserar med ett klientprogram och öppnar en backendtjänst.

Flödet:

Användaren öppnar Finport och omdirigeras till IdP:ns inloggningssida (till exempel Okta).
Användaren autentiserar (användarnamn, lösenord, SSO, flerfaktorsautentisering (MFA) och andra krav).
IdP utfärdar en signerad JWT-åtkomsttoken till Finport-programmet.
Finport har nu en användartoken som representerar användarens identitet: vilka de är, vilka omfattningar de har beviljats och när token går ut. Den kan presentera den för alla tjänster längre ner på uppdrag av denna användare.

Vad detta etablerar: Denna process följer OAuth 2.0-standardarkitekturmönstret. Den inledande användartoken, validerad av en betrodd IdP, fungerar som den grundläggande grunden för alla efterföljande operationer. Varje efterföljande scenario bygger på denna token.

Fråga: När de har autentiserats inleder användaren åtgärder som fondöverföringar, marknadsanalyser eller portföljgranskningar. Dessa begäranden bearbetas genom en Agentmäklare och kan involvera flera agenter längre ner eller MCP-servrar. Detta väcker kritiska frågor: Hur upprätthålls användarens identitet i dessa distribuerade begäranden? Vad händer om en tjänst längre ner använder en helt annan IdP?

Användaren ber Finport-agenten att “Visa mig min portfolio”. Denna interaktion utlöser en backendkedja som börjar med Finport Agent Broker, byggd med MuleSoft Agent Broker. Förmedlaren lämnar över uppgiften till en Portfolio Serviceagent, som i sin tur frågar en Portfolio MCP-server. Användarens inledande autentiseringstoken måste nu resa genom flera hopp för att komma åt de begärda portföljposterna.

Att skicka den ursprungliga token bryter mot principen om minsta privilegium, medan användning av ett servicekonto förlorar användarens identitet.

Finport-agenten får användarens token, men den kan inte bara vidarebefordra samma token till Portfolio Serviceagent, eftersom det skulle bryta mot principen om minsta privilegium och inte korrekt skulle omfatta begäran för tjänsten längre ner. Omvänt resulterar användning av ett servicekonto i en total förlust av användaridentitet. Serviceagenten för portföljen och MCP-servern för portföljen skulle inte ha något sätt att veta vilken användares portfölj som skulle returneras, och verifieringskedjan skulle tillskriva varje åtgärd till mäklarens tjänsteidentitet snarare än slutanvändaren.

Flex Gateway löser dessa komplexiteter för identitetspropagering transparent genom sin policy för utgående OAuth 2.0-tokenutbyte. Denna lösning fångar upp utgående begäranden vid varje hopp i anropskedjan och byter ut den inkommande användartoken med IdP mot en ny inloggningsuppgift som är specifikt begränsad för tjänsten längre ner. Policyn On-Behalf-Of (OBO) har stöd för både protokollen OAuth 2.0 Token Exchange (RFC 8693) och Microsoft Entra ID On-Behalf-Of.

Viktiga arkitektoniska fördelar: Hela processen hanteras av Flex Gateways utgående policy. Förmedlaren och agenterna innehåller noll autentiseringslogik. Istället fokuserar de enbart på verksamhetslogik medan gateway-lagret tillämpar identitetspropagering.

Flödet:

Användaren autentiserar med Okta och Finport-applikationen skickar en begäran via Flex Gateway.
Brokern får den validerade användartoken och avgör om Portfolio serviceagent behövs.
Flex Gateways utgående OBO-policy byter ut användartoken med IdP mot en token som är begränsad till Portfolio serviceagent.
Portfolio Serviceagent får en token med rätt omfattning och anropar Portfolio MCP Server.
Flex Gateway byter återigen ut token, denna gång begränsad till MCP-servern.
Portfolio MCP-servern returnerar användarens specifika portföljdata.
En fullständig verifieringskedja finns. Varje hopp kan tillskrivas den ursprungliga slutanvändaren.

Varför detta spelar roll: Utan OBO-tokenutbyte måste företag välja mellan att vidarebefordra den ursprungliga token, vilket bryter mot minst behörighet, eller använda servicekonton, vilket riskerar att förlora användaridentitet. OBO-mönstret eliminerar denna kompromiss eftersom användarens identitet bevaras vid varje hopp, varje token är begränsad till sitt mål och agenterna själva förblir helt omedvetna om identitetsmekaniken.

Inte alla tjänster längre ner kräver användarsammanhang. Användaren frågar Finport-agenten “Vilka är de aktuella marknadstrenderna?” Till skillnad från portföljbegäran i scenario 1 är marknadstrenddata offentliga när de inte varierar beroende på användare. Marknadsdataagenten och tillgångsmarknadens MCP-server längre ner behöver inte, eller förväntar sig, en token med användaromfång.

Att propagera användartokens där de inte behövs expanderar attackytan.

Om Finport Agent Broker skulle propagera användarens token till Marknadsdataagenten med OBO-mönstret från scenario 1 skulle det fungera men vara onödigt. Att propagera användartokens där de inte behövs expanderar attackytan, skapar onödiga beroenden av IdP för tokenutbyten och bryter mot principen om minsta privilegium. Marknadsdataagenten behöver bara veta att begäran kommer från en auktoriserad tjänst, inte vilken användare som frågar.

Flex Gateways policy Utgående OAuth 2.0-klientuppgifter hanterar detta transparent. Istället för att utbyta användarens token injicerar policyn mäklarens egna serviceuppgifter via ett beviljande av klientuppgifter i den utgående begäran. Marknadsdataagenten längre ner får en korrekt autentiserad servicenivåtoken där ingen användaridentitet propageras eftersom ingen behövs.

Viktiga arkitektoniska fördelar: Strategin för identitetspropagering är inte en-size-fits-all, utan avgörs per rutt längre ner baserat på typen av data och kraven för måltjänsten. Flex Gateways utgående policyer gör detta konfigurerbart per rutt. Samma Finport Agent Broker kan delta i både OBO-flöden (i scenario 1) och S2S-flöden utan några kodändringar. Policykonfigurationen för egress gateway avgör vilket mönster som gäller för vilket anrop längre ner.

Flödet:

Användaren frågar Finport-agenten “Vilka är de aktuella marknadstrenderna?”
Förmedlaren avgör att Marknadsdataagenten behövs för att uppfylla begäran.
Flex Gateways policy för utgående klientuppgifter hämtar en servicenivåtoken med mäklarens egna inloggningsuppgifter (ingen användartoken utbyts eller propageras).
Marknadsdataagenten får en korrekt autentiserad servicebegäran och anropar MCP-servern för tillgångsmarknaden.
MCP-servern för tillgångsmarknad returnerar offentliga marknadsdata.
Ingen användaridentitet finns i kedjan som design eftersom ingen behövs för denna typ av data.

Varför detta spelar roll: Flex Gateways policydrivna ramverk låter arkitekter välja den optimala identitetsmodellen för varje interaktion, vilket löser det svåra valet mellan universell användartokenspridning — vilket ökar overhead- och säkerhetsrisker — och global servicekontoanvändning, vilket offrar användarsammanhang och efterlevnad.

Det mest komplexa identitetsscenariot uppstår när en agent behöver interagera med ett system som styrs av en helt annan IdP, en som inte känner igen den befintliga användartoken.

Scenariot: Finport-användaren ber Finport-agenten att “Överföra 5 000 kr till mitt externa sparkonto”. Denna begäran involverar två separata vägar längre ner:

Sökvägen för Portfolio Service Agent (OBO) för att verifiera användarens innehav
Transaktionsagent → Transaktions-MCP-server → Användarens banksökväg för att utföra själva överföringen

Transaktionsagenten behöver interagera med användarens bank, som använder sin egen IdP. Användarens Okta-token från Finport är meningslös för bankens system, eftersom banken inte har någon Trust relation med Finports IdP. Varken OBO-mönstret (från scenario 1) eller S2S-mönstret (från scenario 2) kan lösa detta. OBO byter tokens inom samma IdP och S2S använder serviceinloggningsuppgifter som inte har någon användaridentitet alls. Banken kräver att användaren autentiserar direkt med sina egna bankuppgifter, eventuellt inklusive MFA.

Policyn Utgående A2A-auktoriseringskod i Flex Gateway använder en mekanism för utmaningssvar i agentkonversationen. Om en sekundär token saknas när du kontaktar banken returnerar policyn en utmaning som krävs för autentisering. Denna utmaning innehåller alla nödvändiga detaljer—som slutpunkter, omfattningar och PKCE-parametrar—för att klienten ska kunna inleda ett OAuth 2.0-flöde med bankens leverantör.

Finport-appen visar sedan bankens inloggning direkt för direkt användarautentisering. När det är klart returnerar klienten token i A2A-begäran. Policyn extraherar denna token för bankens system och skrubbar den från meddelandets brödtext för att säkerställa säkerhet.

Viktiga arkitektoniska fördelar: Policylagret för gateway orkestrerar hela processen för korsdomänautentisering, vilket säkerställer att varken mäklaren eller agenterna någonsin interagerar med råa inloggningsuppgifter eller kräver Knowledge om bankens IdP. Genom att använda detta ramverk för utmaningssvar behåller användare fullständig kontroll: de ger uttryckligt samtycke till autentisering med externa system, medan den resulterande token överförs säkert via policylagret.

Flödet:

Användaren ber Finport inleda en överföring. Begäran flödar genom mäklaren.
Förmedlaren fläktar ut, med hjälp av Portfölj (OBO) för att verifiera innehav, och Transaktion (In-Task) för att utföra överföringen.
Transaktionsvägen utlöser en autentiseringsobligatorisk utmaning från policyn Uppgift i Flex Gateway.
Utmaningen propageras tillbaka till Finport-programmet, som presenterar bankens inloggningsflöde för användaren direkt.
Användaren autentiserar med sin bank, inklusive MFA om det behövs.
Banktoken inkluderas i den efterföljande A2A-begäran. Policyn extraherar den, ställer in den i sidhuvudet Godkännande och vidarebefordrar begäran.
Transaktions-MCP-servern tar emot begäran med bankens token och utför överföringen.

Varför detta spelar roll: Korsdomänidentitet är en stor utmaning i agentarkitekturer. Utan inloggningsuppgifter måste företag antingen upprätta komplexa Trust mellan varje IdPin-nätverk i förväg eller be användare att ange bankuppgifter till en agent. Mönstret Uppgift löser detta genom att tillåta direkt användarautentisering med externa leverantörer; policyn hanterar tokenmekanik medan agenter hålls frånkopplade från externa identitetsdomäner.

Över alla tre scenarion finns en enda arkitektonisk princip: Identitetspropagering tillämpas i gatewaylagret, inte inom agenter eller tjänster. Agenterna och MCP-servrarna innehåller noll autentiseringslogik. Deras roll är begränsad till att bearbeta autentiserade begäranden och returnera resultat, medan det utgående policylagret Flex Gateway hanterar alla identitetsrelaterade operationer.

Detta fungerar eftersom Flex Gateways utgående autentiseringspolicyer fångar upp trafik vid rätt tidpunkt: efter att agenten har fattat sitt dirigeringsbeslut, men innan begäran når tjänsten längre ner. Policyn transformerar token—oavsett om det är ett OBO-utbyte, injektion av klientuppgifter eller uppgiftsutmaning-svar—och vidarebefordrar en korrekt autentiserad begäran. Tjänsten längre ner vet aldrig skillnaden, därför behöver agenten aldrig bry sig. Autentiseringslogik är centraliserad vid gateway, inte utspridd över tjänster. Backendtjänsterna kräver inga kodändringar och samma policykonfiguration kan återanvändas över flera rutter.

Detta tillvägagångssätt är också protokollagnostiskt. Eftersom policyerna arbetar på HTTP-lagret gäller de konsekvent oavsett om agenten kommunicerar via REST, MCP, A2A eller webhooks. Som dokumenterats i Agent Fabric Deep Dive dirigeras all A2A- och MCP-trafik genom Flex Gateway för att säkerställa att policyer tillämpas för varje slutpunkt, vilket innebär att identitetspropagering tillämpas enhetligt oavsett kommunikationsprotokoll.

Tre komponerbara mönster täcker hela spektrumet av identitetskrav i en agentarkitektur:

Mönster	Policy :	Användaridentitet	Användarinteraktion	Användningsfall
På-uppdrag (OBO)	OAuth 2.0 Injektionspolicy för OBO-inloggningsuppgifter	Bevarad	Ingen (genomskinlig)	Användarspecifika data inom samma Trust domän
Server-till-server (S2S)	Utgående OAuth 2.0-klientuppgifter	Ej propagerat	Ingen	Offentliga data, systemnivåoperationer
Auktoriseringskod för uppgift	Utgående A2A-auktoriseringskod för uppgift	Primär + Sekundär	Obligatoriskt (direktautentisering	Operationer mellan domäner, flera identitetsleverantörer, högrisk

Dessa mönster utesluter inte varandra. Som Finport-scenariona visar kan en enskild agentmäklare använda OBO för ett samtal längre ner, S2S för ett annat och In-Task för ett tredje. Policykonfigurationen för varje utgående rutt avgör vilket mönster som gäller. Det finns inga ändringar av agentkod och ingen serviceändring, endast policy.

De gateway-baserade mönster som beskrivs ovan säkrar individuella interaktioner, men identitetspropagering är inte ett isolerat problem. Det är ett grundläggande lager av den bredare styrmodellen för MuleSoft Agent Fabric. Enligt beskrivningen i Agent Fabric Deep Dive bygger Agent Fabric på fyra pelare: Upptäck, orkestrera, styr och observera, och var och en är beroende av en pålitlig identitetskedja för att fungera effektivt.

Upptäck: Agentregistret katalogiserar agenter och deras kapacitet. Agentmetadata, inklusive autentiseringskrav, låter agenter förstå vilka identitetsmönster varje agent förväntar sig.
Orkestrera: Agentmäklaren koordinerar arbetsflöden för flera agenter. Flex Gateway hanterar identitetstransformation på ett transparent sätt i varje hopp, så att mäklaren kan fokusera på uppdelning och dirigering av uppgifter.
Styrning: All A2A- och MCP-trafik dirigeras genom Flex Gateway, även om målsystemet inte är säkert, för att säkerställa att policyer tillämpas för varje slutpunkt. Utgående autentiseringspolicyer är en del av styrlagret.
Observera: Agentvisualiseraren ger observerbarhet i realtid genom en dynamisk, interaktiv karta över agentinteraktioner. Med användaridentitet bevarad i varje hopp ger spårningar och loggar användarattributerbara granskningsloggar över agentnätverket.

Utan betrodd identitetspropagering är styrningen ofullständig. Du kan katalogisera och orkestrera agenter, men du kan inte säkerställa att de agerar inom gränserna för användarens auktorisering. Betrodd agentidentitet åtgärdar detta gap och säkerställer att säkerhet och användarsammanhang förblir centrala i agentflöden.

För att implementera dessa mönster:

Förstå katalogen Utgående policy. Gå igenom den fullständiga uppsättningen utgående autentiseringspolicyer för Flex Gateway.
Börja med OBO. OAuth 2.0-tokenutbytespolicyn hanterar det vanligaste behovet av identitetspropagering: bevara användarsammanhang över agenthumle.
Lägg till uppgift för korsdomänscenarier: Om ditt agentnätverk överskrider Trusts gränser tillhandahåller policyn A2A-uppgiftsauktoriseringskod utmaningssvarsmekanismen för att få sekundära inloggningsuppgifter från användaren.
Använd agenttyg. Definiera ditt agentnätverk i agentnätverks-YAML med policykonfigurationer som specificerar identitetsmodellen per rutt. Plattformen hanterar resten.

Detaljerad vägledning för implementering finns i guiden för implementering.

Nikhil Aggarwal är en framstående tekniker på Salesforce, där han leder arkitektur för MuleSoft och Salesforce Automation Clouds. Nikhil har över 18 års erfarenhet av att leverera storskaliga produkter och brinner för skalbar arkitektur, intuitiva utvecklarupplevelser och att bygga högpresterande team. Innan Salesforce ledde han flera initiativ i Microsoft Power Platform, Dataverse och Office 365 från koncept till lansering. Hans arbete fortsätter att forma hur moderna företag ansluter system, automatiserar arbetsflöden och frigör affärsvärde i den AI-första eran.

Akash Trivedi är teknikdirektör på Salesforce med över 18 års erfarenhet av att bygga skalbara, säkra och högpresterande företagssystem. Han arbetar i skärningspunkten mellan AI, företagsarkitektur och processintelligens, med fokus på molnbaserade plattformar och pålitliga lösningar som fungerar i stor skala. Innan Salesforce hade han ingenjörsroller på Microsoft, där han bidrog till produkter som Copilot, Dataverse och Power Platform.