Klarert agentidentitet for Agentic Enterprise

Etter hvert som virksomheter tar imot det agentiske paradigmet, dukker det opp en ny sikkerhetsutfordring: Hvordan flyter sluttbrukeridentitet gjennom et nettverk av autonome AI-agenter? I tradisjonelle API-arkitekturer godkjennes en bruker én gang, og programmet kaller opp serverdeltjenester på vegne av brukeren. Identitetskjeden er kort, godt forstått og behandles vanligvis innenfor ett enkelt Trust domene. Agentiske arkitekturer har imidlertid mye lengre kjeder der en enkelt forespørsel støtter på tvers av ulike agenter, tjenester og MCP-servere (Model Context Protocol), som alle potensielt krysser tjenestegrenser, Trust domener og til og med organisasjonsgrenser. Uten en hensiktsmessig strategi for identitetsfordeling står virksomheter overfor et valg mellom sikkerhet og funksjonalitet – et dilemma ingen arkitekt bør måtte møte.

MuleSoft løser kompleksiteten i identitetsforplantning med sin Trusted Agent Identity-funksjon. Denne løsningen bruker en policybasert, gatewayadministrert strategi for å sikre at sluttbrukeridentitet opprettholdes på tvers av ulike interaksjonstyper – inkludert agent-til-agent-protokoll (A2A), MCP-verktøykall og REST API-forespørsler.Ved å sentralisere identitetsbehandling på Flex Gateway-laget gjennom utgående godkjenningspolicyer, kan virksomheter sikre hele agentnettverket uten å endre serverdeltjenester eller agenter.

Dette dokumentet går gjennom identitetsforplantningsutfordringen ved å bruke en progressiv serie scenarier, som hver introduserer ekstra kompleksitet. Sammen illustrerer disse scenariene hvorfor Trusted Agent Identity er et grunnleggende krav for eventuelle agentdistribusjoner i bedriftsskala.

I et konvensjonelt program er identitetsflyten (OAuth JWT-flyt) enkel: Brukeren logger seg på, mottar et token, og programmet bruker tokenet til å få tilgang til serverdelressurser. Tokenet er innebygd med brukerens identitet – inkludert hvem de er og hva de er autorisert til å gjøre – og reiser med hver forespørsel. Samtalekjeden er kort, vanligvis én eller to hopper, og identitetsforplantning løses.

Agentiske arkitekturer har imidlertid mye lengre oppkallkjeder der en enkelt brukerforespørsel kan vises på tvers av ulike agenter, serverdeltjenester og MCP-servere (Model Context Protocol).Hver forespørselsmål utgjør en egen hop. Selv om disse utfordringene – som multihop-identitetsforplantning, blandede godkjenningsmodeller, Trust-grenser på tvers av domener – er vanlige i ethvert distribuert API-oppsett, er det som er forskjellig hvordan det nåværende økosystemet reagerer som standard. I dag er det dominerende mønsteret for agent-til-agent- og agent-til-API-kommunikasjon avhengig av klientlegitimasjon, API-nøkler eller delte hemmeligheter. Det betyr følgende:

Brukeridentitet mistes som standard. Når en agent kaller opp en MCP-server eller nedstrøms API ved bruk av klientlegitimasjon, bærer forespørselen agentens tjenesteidentitet og ikke sluttbrukerens. Nedstrømsjenesten har ingen måte å vite hvilken bruker som startet handlingen, noe som gjør det umulig å godkjenne og kontrollere etter hver bruker.
Blandte godkjenningsbehov ignoreres. Ikke alle nedstrøms tjenester krever brukerkontekst.Mens noen behandler brukerspesifikk informasjon som transaksjoner eller porteføljer, gir andre offentlig tilgjengelige eller systemnivåbaserte data som referansemateriale eller markedstrender.Fordi den gjeldende standarden er utelukkende avhengig av klientlegitimasjon, er det ingen måte å skille mellom disse behovene eller selektivt propagere brukeridentitet bare når det er nødvendig.
Grenser for Trust på tvers av domener blir ikke løst. Agenter i B2B- og regulerte scenarier må kanskje samhandle med systemer som styres av helt separate identitetsleverandører (IdP-er). Et eksternt banksystem kan for eksempel ikke tolke et firmas enkeltpåloggingstoken (SSO), men må likevel motta brukerens samtykke og hensikt. Client Credentials-flyten har ingen mekanisme for dette.

Resultatet er en gap mellom virksomhetens krav til brukerattribusjonert tilgang med færrest rettigheter og det gjeldende økosystemets avhengighet av tjenestenivågodkjenning som mangler brukerkontekst. Å lukke dette gapet krever en hensiktsmessig, lagdelt tilnærming til identitetsforplantning. For å illustrere disse konseptene bruker følgende scenarier Finport, en fiktiv fintech-applikasjon, til å gi praktiske eksempler på disse arkitektoniske mønstrene.

Finport er et fiktivt forbrukerrettet Fintech-porteføljebehandling-nettprogram som støttes av en agentisk arkitektur. En Agent Broker (bygd med MuleSoft Agent Broker) koordinerer flere nedstrøms agenter og MCP-servere for å innfri brukerforespørsler.

Finport viser tre kjernefunksjonaliteter, hver med et distinkt identitetskrav:

"Vis meg min portefølje.": Brukeren ber om sin personlige portefølje og transaksjonshistorikk. Fordi disse dataene er brukerspesifikke, må nedstrøms Portfolio Service Agent og Portfolio MCP Server vite hvilken brukers data som skal returneres, og må bekrefte at brukeren er autorisert til å få tilgang til dem. Brukeridentitet må overføres gjennom alle hopper.
"Hva er dagens markedstrender?": Brukeren ber om felles markedsdata og aktivumpriser. I og med at dataene er felles og ikke varierer etter bruker, trenger ikke nedstrøms Market Data Agent og Asset Market MCP Server et brukeromfangstoken. Meglerens egen tjenesteloggingslegitimasjon er tilstrekkelig.
"Overfør $5,000 til min eksterne sparingskonto.": Brukeren initierer en overføring av midler til en bank som bruker en annen identitetsleverandør (for eksempel Auth0 i stedet for Okta). Brukerens Finport-token er meningsløst for bankens system. Brukeren må godkjenne direkte med banken (innebygd i samtalen) før overføringen kan fortsette.

Hver av disse funksjonene tilordnes til et annet identitetsforplantningsmønster. Følgende scenarier bygger gradvis fra en standard basislinje (uten agenter) gjennom hvert distinkt mønster, og illustrerer hvordan utgående policyer i Flex Gateway håndterer hvert krav uten å endre agentene eller serverdeltjenestene.

Før du introduserer agenter, er det viktig å etablere standarden: en bruker som godkjenner seg med et klientprogram og får tilgang til en serverdeltjeneste

Flyten:

Brukeren åpner Finport og omdirigeres til identitetsleverandørens påloggingsside (for eksempel Okta).
Brukeren godkjennes (brukernavn, passord, SSO, godkjenning med flere faktorer (MFA) og eventuelle andre krav).
IdP-en utsteder et signert JWT-tilgangstoken til Finport-programmet.
Finport har nå et brukertoken som representerer brukerens identitet: hvem de er, hvilke omfang de har blitt tildelt, og når tokenet utløper. Den kan presentere den til hvilken som helst nedstrøms tjeneste på vegne av denne brukeren.

Hva dette etablerer: Denne prosessen følger standard OAuth 2.0-arkitekturmønsteret. Det første brukertokenet, som valideres av en klarert identitetsleverandør, tjener som det grunnleggende grunnlaget for alle etterfølgende operasjoner. Hvert etterfølgende scenario bygger på dette tokenet.

Spørsmålet: Når brukeren er godkjent, initierer brukeren handlinger som overføringer av midler, markedsanalyse eller porteføljegjennomganger. Disse forespørslene behandles via en agentmegler og kan involvere flere nedstrøms agenter eller MCP-servere. Dette stiller viktige spørsmål: Hvordan beholdes brukerens identitet på tvers av disse fordelte forespørslene? Hva skjer når en nedstrøms tjeneste bruker en helt annen identitetsleverandør?

Brukeren ber Finport-agenten om å "Vis meg porteføljen min." Denne interaksjonen utløser en serverdelkjede som starter med Finport Agent Broker, bygget med MuleSoft Agent Broker. Megleren overgir oppgaven til en Portfolio tjenesteagent, som i sin tur spør en Portfolio MCP Server. Brukerens første godkjenningstoken må nå gå gjennom flere hopper for å få tilgang til de forespurte porteføljepostene.

Overføring av det opprinnelige tokenet bryter prinsippet om minst rettigheter, mens bruk av en tjenestekonto mister brukerens identitet.

Finport-agenten mottar brukerens token, men kan ikke bare videresende det samme tokenet til Portfolio Service Agent, da det ville bryte prinsippet om minste rettighet og ikke kunne omfatte forespørselen om nedstrømstjenesten riktig. Omvendt fører bruk av en tjenestekonto til totalt tap av brukeridentitet. Portfolio tjenesteagent og Portfolio MCP Server ville ikke ha noen måte å vite hvilken bruker portefølje som skal returneres, og revisjonsspor vil tilskrive hver handling til meglerens tjenesteidentitet i stedet for sluttbrukeren.

Flex Gateway løser disse identitetsforplantningskompleksitetene transparent gjennom sin utgående OAuth 2.0 tokenutvekslingspolicy. Denne løsningen fanger opp utgående forespørsler ved hvert hopp i samtalekjeden, og utveksler det innkommende brukertokenet med identitetsleverandøren for en ny legitimasjon med omfang spesifikt for nedstrømstjenesten. Policyen On-Behalf-Of (OBO) støtter både OAuth 2.0 Token Exchange (RFC 8693) og Microsoft Entra ID On-Behalf-Of-protokollene.

Viktig arkitektonisk fordel: Hele denne prosessen håndteres av Flex Gateway utgående policy. Megleren og agentene inneholder null godkjenningslogikk. I stedet fokuserer de bare på forretningslogikk, mens gatewaylaget håndhever identitetsfordeling.

Flyten:

Brukeren godkjennes med Okta, og Finport-programmet sender en forespørsel via Flex Gateway.
Megleren mottar det validerte brukertokenet og finner ut at Portfolio tjenesteagent er nødvendig.
Flex Gateways utgående OBO-policy utveksler brukertokenet med identitetsleverandøren for et token som omfang til porteføljetjenesteagenten.
Portfolio tjenesteagent mottar et riktig omfangstoken og kaller opp Portfolio MCP Server.
Flex Gateway utveksler tokenet på nytt, denne gangen med omfang for MCP-serveren.
Portfolio MCP-serveren returnerer brukerens spesifikke portföljdata.
Det finnes et fullstendig revisjonsspor. Hvert hopp kan tilskrives den opprinnelige sluttbrukeren.

Hvorfor det betyr noe: Uten OBO-tokenutveksling må virksomheter velge mellom å videresende det opprinnelige tokenet, som bryter minst rettigheter, eller å bruke tjenestekontoer, som risikerer å miste brukeridentiteten. OBO-mønsteret eliminerer denne avveiningen fordi brukerens identitet beholdes ved hvert hopp, hvert token er omfanget til sitt mål, og selve agentene forblir fullstendig uvitende om identitetsmekanikken.

Ikke alle nedstrøms tjenester krever brukerkontekst. Brukeren spør Finport-agenten, "Hva er dagens markedstrender?" Til forskjell fra porteføljeforespørselen i scenario 1 er markedstrenddata offentlige når de ikke varierer etter bruker. Nedstrøms Market Data Agent og Asset Market MCP Server trenger ikke, eller forventer, et brukeromfangstoken.

Propagering av brukertokener der de ikke er nødvendige, utvider angrepsflaten.

Hvis Finport Agent Broker skulle overføre brukerens token til Market Data Agent ved bruk av OBO-mønsteret fra scenario 1, ville det fungere, men ville være unødvendig. Utvidelse av brukertokener der de ikke er nødvendige, utvider angrepsflaten, skaper unødvendige avhengigheter på identitetsleverandøren for tokenutvekslinger og bryter prinsippet om minst rettigheter. Markedsdataagenten trenger bare å vite at forespørselen kommer fra en autorisert tjeneste, ikke hvilken bruker som spør.

Flex Gateways policy for utgående OAuth 2.0-klientlegitimasjon håndterer dette gjennomsiktig. I stedet for å utveksle brukerens token, setter policyen inn meglerens egen tjenestelogitimasjon via en klientlegitimasjonstildeling i den utgående forespørselen. Den nedstrøms Market Data Agent mottar et riktig godkjent tjenestenivåtoken der ingen brukeridentitet overføres fordi ingen er nødvendig.

Viktig arkitektonisk fordel: Identitetsforplantningsstrategien er ikke tilpasset alle, men bestemmes per nedstrøms rute basert på datatypen og kravene til måltjenesten. Flex Gateways utgående policyer gjør dette konfigurerbart per rute. Den samme Finport Agent Broker kan delta i både OBO-flyter (i scenario 1) og S2S-flyter uten noen kodeendringer. Policy-konfigurasjonen på utgangsgaten bestemmer hvilket mønster som gjelder for hvilket nedstrøms kall.

Flyten:

Brukeren spør Finport-agenten, "Hva er dagens markedstrender?"
Megleren finner ut at Markedsdataagent er nødvendig for å innfri forespørselen.
Flex Gateways policy for utgående klientlegitimasjon innhenter et tjenestenivåtoken ved bruk av meglerens egen legitimasjon (ingen brukertoken utveksles eller overføres).
Market Data Agent mottar en riktig godkjent tjenesteforespørsel og kaller opp MCP-serveren for aktivummarkedet.
MCP-serveren for aktivummarkedet returnerer felles markedsdata.
Ingen brukeridentitet finnes i kjeden etter utforming fordi ingen er nødvendig for denne typen data.

Hvorfor det betyr noe: Flex Gateways policydrevne rammeverk gir arkitekter mulighet til å velge den optimale identitetsmodellen for hver interaksjon, og løser det vanskelige valget mellom universell brukertokenforplantning – som øker risikoen for overhead og sikkerhet – og global bruk av tjenestekontoer, som ofre brukerkontekst og samsvar.

Det mest komplekse identitetsscenarioet oppstår når en agent må samhandle med et system som styres av en helt annen identitetsleverandør, en som ikke gjenkjenner det eksisterende brukertokenet.

scenariet: Finport-brukeren ber Finport-agenten om å "Overføre $5000 til min eksterne sparingskonto." Denne forespørselen involverer to distinkte nedstrøms baner:

Veien til Portfolio tjenesteagent (OBO) for å kontrollere brukerens portefølje
Transaksjonsagenten → Transaksjons-MCP-serveren → Brukerens bankbane for å utføre den faktiske overføringen

Transaksjonsagenten må samhandle med brukerens bank, som bruker sin egen identitetsleverandør. Brukerens Okta-token fra Finport er meningsløs for bankens system fordi banken ikke har noen Trust med Finports identitetsleverandør. Verken OBO-mønsteret (fra Scenario 1) eller S2S-mønsteret (fra Scenario 2) kan løse dette. OBO utveksler tokener i samme identitetsleverandør, og S2S bruker tjenestelegitimasjon som ikke bærer noen brukeridentitet i det hele tatt. Banken krever at brukeren godkjenner direkte med sin egen banklegitimasjon, potensielt inkludert MFA.

Policyen Utgående A2A-godkjenningskode i oppgave på Flex Gateway bruker en utfordringsresponsmekanisme i agentsamtalen. Hvis et sekundært token mangler ved kontakt med banken, returnerer policyen en godkjenningskravet utfordring. Denne utfordringen inkluderer alle nødvendige detaljer, som endepunkter, omfang og PKCE-parametere, for at klienten skal kunne starte en OAuth 2.0-flyt med bankens leverandør.

Finport-appen viser deretter bankens innebygde pålogging for direkte brukergodkjenning. Når den er fullført, returnerer klienten tokenet i A2A-forespørselen. Policyen trekker ut dette tokenet for bankens system og fjerner det fra meldingsteksten for å sikre sikkerhet.

Viktig arkitektonisk fordel: Gatewaypolicylaget organiserer hele godkjenningsprosessen på tvers av domener, slik at verken megleren eller agentene noen gang samhandler med rå legitimasjon eller krever Knowledge av bankens identitetsleverandør. Ved å bruke dette utfordringsresponsrammeverket beholder brukerne full kontroll: de gir eksplisitt samtykke til å godkjennes med eksterne systemer, mens det resulterende tokenet overføres sikkert via policylaget.

Flyten:

Brukeren ber Finport om å starte en overføring. Forespørselen flyter gjennom megleren.
Megleren bruker porteføljen (OBO) til å bekrefte porteføljen, og transaksjonen (i oppgave) til å utføre overføringen.
Transaksjonsbanen utløser en godkjenningskravet utfordring fra policyen I oppgave i Flex Gateway.
Utfordringen overføres tilbake til Finport-programmet, som presenterer bankens påloggingsflyt for brukeren innebygd.
Brukeren godkjenner med sin bank, inkludert MFA hvis det er nødvendig.
Banktokenet inkluderes i den etterfølgende A2A-forespørselen. Policyen trekker den ut, angir den i Godkjenning-hodet og videresender forespørselen.
Transaksjons-MCP-serveren mottar forespørselen med bankens token og utfører overføringen.

Hvorfor dette betyr noe: Identitet på tvers av domener er en stor utfordring i agentiske arkitekturer. Uten godkjenning i oppgaver må virksomheter enten forhåndsopprette komplekse Trust mellom alle identitetsleverandører i nettverket, eller be brukere om å oppgi banklegitimasjon til en agent. In-Task-mønsteret løser dette ved å tillate direkte brukergodkjenning med eksterne leverandører. Policyen administrerer tokenmekanikk samtidig som agentene holdes frakoblet fra eksterne identitetsdomener.

På tvers av alle tre scenarier gjelder ett enkelt arkitektonisk prinsipp: Identitetsforplantning håndheves på gatewaylaget, ikke i agenter eller tjenester. Agentene og MCP-serverne inneholder null godkjenningslogikk. Deres rolle er begrenset til å behandle godkjente forespørsler og returnere resultater, mens det utgående policylaget Flex Gateway behandler alle identitetsrelaterte operasjoner.

Dette fungerer fordi Flex Gateways utgående godkjenningspolicyer fanger opp trafikk på riktig sted: etter at agenten har fattet rutingsbeslutningen sin, men før forespørselen når nedstrømsjenesten. Policyen transformerer tokenet – enten det er en OBO-utveksling, innsetting av kundelegitimasjon eller utfordringsrespons – og videresender en riktig godkjent forespørsel. Nedstrømsjenesten vet aldri forskjellen, så agenten trenger aldri å bry seg. Godkjenningslogikk er sentralisert ved gatewayen, ikke fordelt på tvers av tjenester. Serverdeltjenestene krever ingen kodeendringer, og den samme policykonfigurasjonen kan brukes på nytt på tvers av flere ruter.

Denne tilnærmingen er også protokollagnostisk. I og med at policyene opererer på HTTP-laget, brukes de konsekvent enten agenten kommuniserer via REST, MCP, A2A eller webhooks. Som dokumentert i Agent Fabric Deep Dive blir all A2A- og MCP-trafikk rutet gjennom Flex Gateway for å sikre at policyer brukes på hvert endepunkt, noe som betyr at identitetsforplantning håndheves jevnt uavhengig av kommunikasjonsprotokollen.

Tre komponerbare mønstre dekker hele spekteret av identitetskrav i en agentisk arkitektur:

Mønster	Policy (policy)	Brukeridentitet	Brukerinteraksjon	Brukstilfelle
På vegne av (OBO)	Oauth 2.0 OBO Credential Injection Policy	Beholdt	Ingen (gjennomsiktig)	Brukerspesifikke data i samme Trust
Server-til-server (S2S)	Utgående OAuth 2.0-klientlegitimasjon	Ikke overført	Ingen	Felles data, operasjoner på systemnivå
Taksgodkjenningskode	Utgående A2A-godkjenningskode i arbeid	Primær + Sekundær	Nødvendig (innebygd godkjenning)	Kryddomene, fleridentitetsleverandør, operasjoner med høy risiko

Disse mønstrene er ikke gjensidig eksklusive. Som Finport-scenariene viser, kan en enkelt agentmegler bruke OBO til ett nedstrøms anrop, S2S til et annet og In-Task til et tredje. Policy-konfigurasjonen på hver utgående rute bestemmer hvilket mønster som gjelder. Det er ingen endringer i agentkode og ingen tjenesteendringer, bare policy.

De gatewayforsterkede mønstrene som er beskrevet ovenfor, sikrer individuelle interaksjoner, men identitetsfordeling er ikke et isolert problem. Det er et grunnlag i den mer omfattende MuleSoft Agent Fabric-styringsmodellen. Som beskrevet i Agent Fabric Deep Dive, er Agent Fabric bygget på fire søyler: Oppdag, orkestrere, styre og observere, og hver av dem er avhengig av en pålitelig identitetskjede for å fungere effektivt.

Oppdag: Agentregisteret katalogiserer agenter og deres funksjoner. Agentmetadata, inkludert godkjenningskrav, gir meglere mulighet til å forstå hvilke identitetsmønstre hver agent forventer.
Orkestret: Agentbroker koordinerer arbeidsflyter for flere agenter. Flex Gateway håndterer identitetstransformasjon gjennomsiktig ved hvert hopp, slik at megleren kan fokusere på oppgavedekomponering og ruting.
Styr: All A2A- og MCP-trafikk rutes via Flex Gateway, selv om målsystemet ikke er sikret, for å sikre at policyer brukes på hvert endepunkt. Utgående godkjenningspolicyer er en del av styringslaget.
Observer: Agent Visualizer gir observasjon i sanntid via et dynamisk, interaktivt kart over agentinteraksjoner. Med brukeridentitet beholdt ved hvert hopp, gir sporinger og logger brukertilskrevne revisjonsspor på tvers av agentnettverket.

Uten klarert identitetsforplantning er styring ufullstendig. Du kan katalogere og orkestrere agenter, men du kan ikke sikre at de handler innenfor grensene til brukerens godkjenning. Klarert agentidentitet lukker dette gapet og sikrer at sikkerhet og brukerkontekst forblir sentral for agentiske arbeidsflyter.

For å implementere disse mønstrene:

Forstå den utgående policykatalogen. Se gjennom det fullstendige settet med utgående godkjenningspolicyer som er tilgjengelig for Flex Gateway.
Begynn med OBO. OAuth 2.0-policyen for tokenutveksling dekker de vanligste identitetsforplantingsbehovene: beholde brukerkontekst på tvers av agenthopper.
Legg til på-oppgave for scenarier på tvers av domener: Når agentnettverket ditt krysser Trust-grenser, gir A2A-policyen for godkjenningskode i oppgave mekanismen for å hente sekundær legitimasjon fra brukeren.
Hevelsesmidlet stoff. Definer agentnettverket i agent-nettverket YAML med policykonfigurasjoner som angir identitetsmodellen per rute. Plattformen håndterer resten.

Hvis du vil ha detaljert veiledning om gjennomføring, kan du se kompaniveiledningen.

Nikhil Aggarwal er Distinguished Engineer på Salesforce, der han leder arkitektur for MuleSoft og Salesforce Automation Clouds. Nikhil har over 18 års erfaring med å levere produkter i stor skala, og er opptatt av skalerbar arkitektur, intuitive utvikleropplevelser og å bygge team med høy ytelse. Før Salesforce ledet han flere initiativer i Microsoft Power Platform, Dataverse og Office 365 fra konsept til oppstart. Arbeidet hans fortsetter å forme hvordan moderne virksomheter kobler sammen systemer, automatiserer arbeidsflyter og låser opp forretningsverdi i AI-første æra.

Akash Trivedi er ingeniøransvarlig hos Salesforce med over 18 års erfaring med å bygge skalerbare, sikre, høyytelsesforetakssystemer. Han arbeider på overlappingen mellom AI, bedriftsarkitektur og prosessintelligens, med fokus på skybaserte plattformer og pålitelige løsninger som opererer i stor skala. Før Salesforce hadde han tekniske roller hos Microsoft, der han bidro til produkter som Copilot, Dataverse og Power Platform.