Sikret agentidentitet for agentvirksomheden

Efterhånden som virksomhederne anvender det agentmæssige paradigme, opstår der en ny sikkerhedsudfordring: Hvordan flyder slutbrugeridentitet gennem et netværk af autonome AI-agenter? I traditionelle API-arkitekturer godkendes en bruger en gang, og applikationen kalder backendtjenester på brugerens vegne. Identitetskæden er kort, velforstået og administreres typisk i et enkelt Trust. Agentiske arkitekturer har dog meget længere kæder, hvor en enkelt anmodning udsendes på tværs af forskellige agenter, tjenester og MCP-servere (Model Context Protocol), der hver potentielt krydser servicegrænser, Trust domæner og endda organisationsgrænser. Uden en bevidst strategi for udbredelse af identitet står virksomheder over for et valg mellem sikkerhed og funktionalitet – et dilemma, som ingen arkitekt skal have at stå over for.

MuleSoft håndterer kompleksiteten af identitetsudbredelse med sin funktion Trusted Agent Identity. Denne løsning bruger en politikbaseret, gatewayadministreret strategi til at sikre, at slutbrugeridentitet bevares på tværs af forskellige interaktionstyper – herunder agent-til-agent-protokoller (A2A), MCP-værktøjskald og REST API-anmodninger.Ved at centralisere identitetsstyring på Flex Gateway-laget gennem udgående godkendelsespolitikker kan virksomheder sikre hele deres agentnetværk uden at ændre backend-tjenester eller agenter.

Dette dokument gennemgår identitetsudbredelsesudfordringen ved brug af en progressiv række scenarier, hvor hver introducerer yderligere kompleksitet. Disse scenarier illustrerer sammen, hvorfor Trusted Agent Identity er et grundlæggende krav for enhver agentimplementering på virksomhedsskala.

I en konventionel applikation er identitetsforløbet (OAuth JWT-forløb) nemt: Brugeren logger ind, modtager et token, og applikationen bruger tokenet til at få adgang til backend-ressourcer. Tokenet er integreret med brugerens identitet – herunder hvem de er, og hvad de er autoriseret til at gøre – og rejser med hver anmodning. Opkaldskæden er kort, typisk et eller to hop, og identitetsudbredelse løses.

Agentiske arkitekturer har dog meget længere opkaldskæder, hvor en enkelt brugeranmodning kan udløses på tværs af forskellige agenter, backendtjenester og MCP-servere (Model Context Protocol).Hver anmodningsdestination udgør et separat hop. Mens disse udfordringer – som multi-hop-identitetsudbredelse, blandede autorisationsmodeller, krydsdomæne Trust-grænser – er almindelige i enhver distribueret API-opsætning, er det, der er særligt, hvordan det aktuelle økosystem reagerer som standard. I dag er det dominerende mønster for agent-til-agent- og agent-til-API-kommunikation baseret på klientlegitimationsoplysninger, API-nøgler eller delte hemmeligheder. Dette betyder:

Brugeridentitet går som standard tabt. Når en agent kalder en MCP-server eller downstream-API ved brug af klientlegitimationsoplysninger, indeholder anmodningen agentens tjenesteidentitet og ikke slutbrugerens. Downstream-tjenesten har ingen mulighed for at vide, hvilken bruger der startede handlingen, hvilket gør det umuligt med pr. bruger-autorisation og revisionsspor.
Brug af blandede godkendelser ignoreres. Ikke alle downstream-tjenester kræver brugerkontekst.Mens nogle administrerer brugerspecifikke oplysninger som transaktioner eller porteføljer, leverer andre offentlige data eller data på systemniveau, f.eks. referencemateriale eller markedstendenser.Da den aktuelle standard udelukkende er afhængig af klientlegitimationsoplysninger, er der ingen måde at skelne mellem disse behov eller selektivt udbrede brugeridentitet, når det er nødvendigt.
Grænser for krydsdomæne Trust er ikke håndteret. Agenter i B2B- og regulerede scenarier kan have brug for at interagere med systemer, der er styret af helt separate identitetsudbydere (IdPs). Et eksternt banksystem kan f.eks. ikke fortolke et virksomheds-SSO-token (single-sign-on), men det skal stadig modtage brugerens samtykke og hensigt. Forløbet Client Credentials (Klientlegitimationsoplysninger) har ingen mekanisme til dette.

Resultatet er et hul mellem virksomhedskravet for brugerattribut, adgang med mindst rettigheder og det aktuelle økosystems afhængighed af godkendelse på serviceniveau, der mangler brugerkontekst. Lukning af dette hul kræver en bevidst, lagdelt tilgang til identitetsudbredelse. For at illustrere disse begreber bruger følgende scenarier Finport, en fiktiv fintech-applikation, til at give praktiske eksempler på disse arkitektoniske mønstre.

Finport er en fiktiv forbrugerorienteret webapplikation til administration af FinTech-portefølje, der er understøttet af en agentisk arkitektur. En agentforhandler (bygget ved hjælp af MuleSoft Agentforhandler) koordinerer flere downstream agenter og MCP-servere for at opfylde brugeranmodninger.

Finport viser tre kernefunktioner, der hver har et særskilt identitetskrav:

“Vis mig min portefølje.”: Brugeren anmoder om sine personlige beholdninger og transaktionshistorik. Da disse data er brugerspecifikke, skal downstream Portfolio Service Agent og Portfolio MCP Server vide, hvilken brugers data der skal returneres, og skal kontrollere, at brugeren er autoriseret til at få adgang til dem. Brugeridentitet skal udbredes gennem hvert hop.
“Hvad er de aktuelle markedstendenser?”: Brugeren anmoder om offentlige markedsdata og aktivpriser. Da dataene er offentlige og ikke varierer efter bruger, har downstream Market Data Agent og Asset Market MCP Server ikke brug for eller forventer et anvendelseskontoken. Mæglerens egne tjenestelegitimationsoplysninger er tilstrækkelige.
Overfør $5.000 til min eksterne opsparingskonto.: Brugeren starter en overførsel af midler til en bank, der bruger en anden IdP (f.eks. Auth0 i stedet for Okta). Brugerens Finport-token er meningsløst for bankens system. Brugeren skal godkende direkte hos banken (indbygget i samtalen), før overførslen kan fortsætte.

Hver af disse funktioner knyttes til et andet identitetsudbredelsesmønster. Følgende scenarier opbygges gradvist fra en standardbasislinje (uden agenter) gennem hvert særskilt mønster, der illustrerer, hvordan udgående politikker i Flex Gateway håndterer hvert krav uden at redigere agenterne eller backendtjenesterne.

Før du introducerer agenter, er det vigtigt at etablere basislinjen: en bruger, der godkender med en klientapplikation og får adgang til en backendtjeneste.

Forløbet:

Brugeren åbner Finport og omdirigeres til IdP’ens loginside (f.eks. Okta) .
Brugeren godkender (brugernavn, adgangskode, SSO, godkendelse med flere faktorer (MFA) og alle andre krav).
IdP udsteder et signeret JWT-adgangstoken til Finport-applikationen.
Finport har nu et brugertoken, der repræsenterer brugerens identitet: hvem de er, hvilke omfang de er tildelt, og hvornår tokenet udløber. Den kan præsentere den for enhver downstream-tjeneste på vegne af denne bruger.

Hvad dette fastlægger: Denne proces følger OAuth 2.0-standardarkitekturmønsteret. Det indledende brugertoken, der er valideret af en betroet IdP, fungerer som det vigtige grundlag for alle efterfølgende handlinger. Hvert efterfølgende scenarie bygger på dette token.

Spørgsmålet: Når brugeren er godkendt, starter den handlinger som f.eks. overførsler af midler, markedsanalyser eller porteføljegennemgange. Disse anmodninger behandles gennem en agentbroker og kan involvere flere downstream-agenter eller MCP-servere. Dette rejser kritiske spørgsmål: Hvordan vedligeholdes brugerens identitet på tværs af disse distribuerede anmodninger? Hvad sker der, når en downstream-tjeneste bruger en helt anden IdP?

Brugeren beder Finport-agenten om at “Vis mig min portefølje.” Denne interaktion udløser en backend kæde startende med Finport Agent Broker, der er bygget ved hjælp af MuleSoft Agent Broker. Mægleren overdrager opgaven til en Portfolio Service Agent, som til gengæld forespørger på en Portfolio MCP Server. Brugerens indledende godkendelsestoken skal nu rejse gennem flere hop for at få adgang til de ønskede porteføljeregistreringer.

Overførsel af det oprindelige token overtræder princippet om mindste rettigheder, mens brug af en servicekonto mister brugerens identitet.

Finport-agenten modtager brugerens token, men den kan ikke blot videresende det samme token til porteføljeserviceagenten, da det ville være i strid med princippet om mindste rettigheder og ikke ville omfatte anmodningen om downstream-tjenesten korrekt. Omvendt vil brug af en servicekonto resultere i et samlet tab af brugeridentitet. Portfolio Service Agent og Portfolio MCP Server ville ikke have mulighed for at vide, hvilken brugers portefølje der skal returneres, og revisionssporet ville tilskrive hver handling til mæglerens tjenesteidentitet snarere end slutbrugeren.

Flex Gateway løser disse identitetsudbredelseskompleksiteter gennemsigtigt gennem sin Outbound OAuth 2.0-tokenudvekslingspolitik. Denne løsning opfanger udgående anmodninger ved hvert hop i opkaldskæden og udveksler det indgående brugertoken med IdP for en ny legitimationsoplysning, der er tilpasset specifikt for downstream-tjenesten. Politikken On-Behalf-Of (OBO) understøtter både OAuth 2.0-tokenudvekslingsprotokoller (RFC 8693) og Microsoft Entra ID On-Behalf-Of-protokoller.

Nøgle arkitektonisk fordel: Hele denne proces håndteres af Flex Gateway udgående politik. Mægleren og agenterne indeholder nul-godkendelseslogik. I stedet fokuserer de udelukkende på forretningslogik, mens gatewaylaget håndhæver identitetsudbredelse.

Forløbet:

Brugeren godkendes med Okta, og Finport-applikationen sender en anmodning gennem Flex Gateway.
Mægleren modtager det validerede brugertoken og bestemmer, hvilken porteføljeserviceagent der skal bruges.
Flex Gateways udgående OBO-politik udveksler brugertokenet med IdP for et token, der er tildelt til porteføljeserviceagenten.
Portfolio serviceagent modtager et korrekt omfanget token og kalder Portfolio MCP-serveren.
Flex Gateway udveksler tokenet igen, denne gang omfanget for MCP-serveren.
Portfolio MCP-serveren returnerer brugerens specifikke porteføljedata.
Der findes et komplet revisionsspor. Hvert hop kan tilskrives den oprindelige slutbruger.

Hvorfor det betyder noget: Uden OBO-tokenudveksling skal virksomheder vælge mellem at videresende det oprindelige token, hvilket overtræder mindste rettigheder, eller bruge servicekonti, hvilket risikerer at miste brugeridentitet. OBO-mønsteret eliminerer denne afvejning, da brugerens identitet bevares ved hvert hop, hvert token er tilpasset til dets mål, og agenterne selv forbliver fuldstændig uvidende om identitetsmekanikkerne.

Ikke alle downstream-tjenester kræver brugerkontekst. Brugeren spørger Finport-agenten, “Hvad er de aktuelle markedstendenser?” I modsætning til porteføljeanmodningen i scenarie 1 er markedstendensdata offentlige, når de ikke varierer efter bruger. Den downstream Market Data Agent og Asset Market MCP Server har ikke brug for eller forventer et brugeromfangstoken.

Udbredelse af brugertokener, hvor de ikke er nødvendige, udvider angrebsområdet.

Hvis Finport Agent Broker skulle udbrede brugerens token til Market Data Agent ved brug af OBO-mønsteret fra scenarie 1, ville det fungere, men ville være unødvendigt. Udbredelse af brugertokener, hvor de ikke er nødvendige, udvider angrebsområdet, skaber unødvendige afhængigheder på IdP for tokenudvekslinger og overtræder princippet om mindste rettigheder. Market Data Agent behøver blot at vide, at anmodningen kommer fra en autoriseret tjeneste, ikke hvilken bruger der spørger.

Flex Gateways politik for udgående OAuth 2.0-klientlegitimationsoplysninger håndterer dette gennemsigtigt. I stedet for at udveksle brugerens token, indsætter politikken mæglerens egne tjenestelegitimationsoplysninger via en klientlegitimationsoplysningstildeling i den udgående anmodning. Downstream Market Data Agent modtager et korrekt godkendt serviceniveautoken, hvor der ikke udbredes nogen brugeridentitet, da der ikke er brug for noget.

Nøgle arkitektonisk fordel: Identitetsudbredelsesstrategien er ikke en størrelse, der passer til alle, snarere er den bestemt pr. downstream-rute baseret på dataenes karakter og kravene til måltjenesten. Flex Gateways udgående politikker gør dette konfigurerbart pr. rute. Den samme Finport Agent Broker kan deltage i både OBO-forløb (i scenarie 1) og S2S-forløb uden nogen kodeændringer. Politikkonfigurationen på udgangsgatewayen bestemmer, hvilket mønster der gælder for hvilket downstream-kald.

Forløbet:

Brugeren spørger Finport-agenten, “Hvad er de aktuelle markedstendenser?”
Mægleren bestemmer, at der er brug for Market Data Agent for at fuldføre anmodningen.
Flex Gateways politik for udgående klientlegitimationsoplysninger henter et serviceniveautoken ved brug af mæglerens egne legitimationsoplysninger (ingen brugertoken udveksles eller udbredes).
Market Data Agent modtager en korrekt godkendt tjenesteanmodning og kalder MCP-serveren for aktivmarkedet.
MCP-serveren for aktivmarkedet returnerer de offentlige markedsdata.
Der findes ingen brugeridentitet i kæden efter design, da der ikke er brug for nogen til denne type data.

Hvorfor det betyder noget: Flex Gateways politikstyrede struktur sætter arkitekter i stand til at vælge den optimale identitetsmodel for hver interaktion og løser det vanskelige valg mellem universel brugertokenudbredelse – hvilket øger overhead- og sikkerhedsrisici – og global brug af servicekonto, hvilket ofre brugerkontekst og compliance.

Det mest komplekse identitetsscenarie opstår, når en agent har brug for at interagere med et system, der styres af et helt andet IdP, et der ikke genkender det eksisterende brugertoken.

Scenariet: Finport-brugeren beder Finport-agenten om at overføre $5.000 til min eksterne opsparingskonto. Denne anmodning involverer to forskellige downstream-stier:

Portfolio Serviceagent (OBO) sti til at bekræfte brugerens beholdninger
Transaktionsagenten → Transaktions-MCP-serveren → Brugerens banksti til at udføre den faktiske overførsel

Transaktionsagenten skal interagere med brugerens bank, som bruger sin egen IdP. Brugerens Okta token fra Finport er meningsløs for bankens system, da banken ikke har noget Trust forhold til Finports IdP. Hverken OBO-mønsteret (fra Scenario 1) eller S2S-mønsteret (fra Scenario 2) kan løse dette. OBO udveksler tokener i samme IdP, og S2S bruger servicelegitimationsoplysninger, der slet ikke indeholder nogen brugeridentitet. Banken kræver, at brugeren godkendes direkte med sine egne banklegitimationsoplysninger, potentielt inklusive MFA.

Politikken for udgående A2A-godkendelseskode i opgave på Flex Gateway bruger en udfordrings-svar-mekanisme i agentsamtalen. Hvis der mangler et sekundært token, når du kontakter banken, returnerer politikken en godkendelseskrævet udfordring. Denne udfordring inkluderer alle nødvendige detaljer – f.eks. slutpunkter, omfang og PKCE-parametre – for klienten at starte et OAuth 2.0-forløb med bankens udbyder.

Finport-appen viser derefter bankens login direkte til direkte brugergodkendelse. Når den er fuldført, returnerer klienten tokenet i A2A-anmodningen. Politikken udtrækker dette token for bankens system og rydder det fra meddelelsens brødtekst for at sikre sikkerhed.

Nøgle arkitektonisk fordel: Gateway-politiklaget organiserer hele godkendelsesprocessen på tværs af domæner, så hverken mægleren eller agenterne nogensinde interagerer med rå legitimationsoplysninger eller kræver Knowledge af bankens IdP. Ved at bruge denne struktur for udfordringsvar bevarer brugerne fuld kontrol: de giver eksplicit samtykke til at godkende med eksterne systemer, mens det resulterende token sendes sikkert via politiklaget.

Forløbet:

Brugeren beder Finport om at starte en viderestilling. Anmodningen flyder gennem mægleren.
Brokerens fans ud, ved brug af porteføljen (OBO) til at bekræfte beholdninger og transaktionen (i opgave) til at udføre overførslen.
Transaktionsstien udløser en godkendelseskrævet udfordring fra politikken i opgaven på Flex Gateway.
Udfordringen udbredes tilbage til Finport-applikationen, som præsenterer bankens loginforløb for brugeren direkte.
Brugeren godkendes med sin bank, herunder MFA, hvis det kræves.
Banktokenet er inkluderet i den efterfølgende A2A-anmodning. Politikken udtrækker den, indstiller den i godkendelsessidehovedet og videresender anmodningen.
Transaktions-MCP-serveren modtager anmodningen med bankens token og udfører overførslen.

Hvorfor det betyder noget: Krydsdomæneidentitet er en større udfordring i agentarkitekturer. Uden opgavegodkendelse skal virksomheder enten etablere komplekse Trust på forhånd mellem hvert IdPin i netværket, eller bede brugere om at angive banklegitimationsoplysninger til en agent. Mønsteret i opgaven løser dette ved at tillade direkte brugergodkendelse med eksterne udbydere. Politikken administrerer tokenmekanik, mens agenterne holdes adskilt fra eksterne identitetsdomæner.

På tværs af alle tre scenarier gælder der et enkelt arkitektonisk princip: Identitetsudbredelse håndhæves på gatewaylaget, ikke i agenter eller tjenester. Agenterne og MCP-servere indeholder nul-godkendelseslogik. Deres rolle er begrænset til behandling af godkendte anmodninger og returnering af resultater, mens Flex Gateway-udgående politiklag administrerer alle identitetsrelaterede handlinger.

Dette fungerer, fordi Flex Gateways udgående godkendelsespolitikker opfanger trafik på det rigtige tidspunkt: efter agenten har truffet sin distributionsbeslutning, men før anmodningen når downstream-tjenesten. Politikken transformerer tokenet – uanset om det er en OBO-udveksling, injektion af klientlegitimationsoplysninger eller udfordringssvar i opgaven – og videresender en korrekt godkendt anmodning. Downstream-tjenesten ved aldrig forskellen, derfor behøver agenten aldrig at være bekymret. Godkendelseslogik er centraliseret ved gatewayen, ikke spredt på tværs af tjenester. Backendtjenesterne kræver ingen kodeændringer, og den samme politikkonfiguration kan genbruges på tværs af flere ruter.

Denne tilgang er også protokolagnostisk. Da politikkerne fungerer på HTTP-laget, anvendes de ensartet, uanset om agenten kommunikerer via REST, MCP, A2A eller webhooks. Som dokumenteret i Agent Fabric Deep Dive, distribueres al A2A- og MCP-trafik gennem Flex Gateway for at sikre, at politikker anvendes på hvert slutpunkt, hvilket betyder, at identitetsudbredelse håndhæves ensartet uanset kommunikationsprotokollen.

Tre mønstre, der kan sammensættes, dækker det fulde spektrum af identitetskrav i en agentarkitektur:

Mønster	Politik	Brugeridentitet	Brugerinteraktion	Anvendelsessituation
On-Of (OBO)	OAuth 2.0 OBO-legitimationsoplysningers injektionspolitik	Bevarede	Ingen (gennemsigtig)	Brugerspecifikke data i det samme Trust
Server-til-Server (S2S)	Udgående OAuth 2.0-klientlegitimationsoplysninger	Ikke udbredt	Ingen	Offentlige data, handlinger på systemniveau
Task Authorization Code	Udgående A2A-godkendelseskode i opgave	Primær + Sekundær	Påkrævet (inlinegodkendelse)	Krydsdomæne, multi-identitetsudbyder, handlinger med høj risiko

Disse mønstre udelukker ikke hinanden. Som Finport-scenarierne viser, kan en enkelt agentbroker bruge OBO til et downstream-opkald, S2S til et andet og In-Task til et tredje. Politikkonfigurationen på hver udgående rute bestemmer, hvilket mønster der gælder. Der er ingen agentkodeændringer og ingen serviceændringer, kun en politik.

De gateway-håndhævede mønstre, der er beskrevet ovenfor, sikrer individuelle interaktioner, men identitetsudbredelse er ikke et isoleret problem. Det er et grundlæggende lag af den bredere MuleSoft Agent Fabric-styringsmodel. Som beskrevet i Agent Fabric Deep Dive, er Agent Fabric bygget på fire søjler: Udforsk, orkestrer, styr og observer, og hver af dem er afhængig af en pålidelig identitetskæde for at fungere effektivt.

Opdag: Agentregistret katalogiserer agenter og deres funktioner. Agentmetadata, herunder godkendelseskrav, gør det muligt for mæglere at forstå, hvilke identitetsmønstre hver agent forventer.
Orkestrer: Agentbrokeren koordinerer arbejdsflows med flere agenter. Flex Gateway håndterer gennemsigtigt identitetstransformation ved hvert spring, så mægleren kan fokusere på opgavedebyring og distribution.
Styr: Al A2A- og MCP-trafik distribueres gennem Flex Gateway, selvom målsystemet ikke er sikret, for at sikre, at politikker anvendes på hvert slutpunkt. Udgående godkendelsespolitikker er en del af styringslaget.
Observer: Agentvisualiser giver observation i realtid gennem et dynamisk, interaktivt kort over agentinteraktioner. Med brugeridentitet bevaret ved hvert spring, giver spor og logfiler brugertildelbare revisionsspor på tværs af agentnetværket.

Uden betroet identitetsudbredelse er styring ufuldstændig. Du kan katalogisere og orkestrere agenter, men du kan ikke sikre, at de handler inden for grænserne for brugerens autorisation. Trusted Agent Identity lukker dette hul og sikrer, at sikkerhed og brugerkontekst forbliver centralt for agentarbejdsflows.

Hvis du vil implementere disse mønstre:

Forstå mappen Udgående policer. Gennemse det komplette sæt af udgående godkendelsespolitikker, der er tilgængelige for Flex Gateway.
Begynd med OBO. OAuth 2.0-tokenudvekslingspolitikken håndterer de mest almindelige behov for identitetsudbredelse: bevarelse af brugerkontekst på tværs af agenthop.
Tilføj In-Task for krydsdomænescenarier: Når dit agentnetværk krydser Trust-grænser, giver A2A-politikken for autorisationskode i opgave mekanismen for udfordringsrespons til at få sekundære legitimationsoplysninger fra brugeren.
Leverage Agent Fabric. Definer dit agentnetværk i agent-netværks-YAML med politikkonfigurationer, der angiver identitetsmodellen pr. rute. Platformen håndterer resten.

For detaljerede gennemførelsesvejledninger henvises der til kompletterende gennemførelsesvejledning.

Nikhil Aggarwal er fremhævede tekniker hos Salesforce, hvor han leder arkitektur for MuleSoft og Salesforce Automation Clouds. Nikhil har over 18 års erfaring med at levere produkter i stor skala og er passioneret for skalerbar arkitektur, intuitive udvikleroplevelser og opbygning af højtydende teams. Før Salesforce ledte han flere initiativer i Microsoft Power Platform, Dataverse og Office 365 fra koncept til lancering. Hans arbejde fortsætter med at forme, hvordan moderne virksomheder tilslutter systemer, automatiserer arbejdsflows og låser forretningsværdien op i den første æra af AI.

Akash Trivedi er direktør for teknik i Salesforce med over 18 års erfaring med opbygning af skalerbare, sikre, højtydende virksomhedssystemer. Han arbejder på skæringspunktet mellem AI, virksomhedsarkitektur og procesintelligens med fokus på cloud-oprindelige platforme og pålidelige løsninger, der fungerer på skala. Før Salesforce havde han ingeniørroller hos Microsoft, hvor han bidrog til produkter, herunder Copilot, Dataverse og Power Platform.