Luotettu agentin identiteetti agenteille Enterprise

Kun yritykset omaksua agenttinen paradigma, uusi tietoturva haaste syntyy: Miten loppukäyttäjien identiteetti kulkee itsenäisten tekoälyn agenttien verkoston kautta? Tavallisissa API-arkkitehtuurissa käyttäjä todentaa itsensä kerran ja sovellus kutsuu käyttäjän puolesta taustapalveluita. Identiteettiketju on lyhyt, ymmärrettävä ja sitä hallitaan tavallisesti yhdessä Trust toimialueessa. Agenttien arkkitehtuurit sisältävät kuitenkin paljon pidempiä ketjuja, joissa yksi pyyntö lähetetään eri agenttien, palveluiden ja mallin kontekstiprotokollan (MCP) palvelimille, jotka kaikki saattavat ylittää palvelurajoitukset, Trust toimialueet ja jopa organisaation rajat. Jos yrityksillä ei ole tarkoituksellista strategiaa henkilöllisyyden levittämiseksi, heidän täytyy valita tietoturvan ja toiminnallisuuden välillä – eli dilemman, jota mikään arkkitehti ei pitäisi kohdata.

MuleSoft korjaa identiteettien monimutkaisuuden käyttämällä sen luotettua agentin identiteettiä -ominaisuutta. Tämä ratkaisu käyttää käytäntöihin perustuvaa yhdyskäytävän hallitsemaa strategiaa varmistaakseen, että loppukäyttäjien henkilöllisyys säilytetään eri vuorovaikutustyypeissä — mukaan lukien agentista agentille (A2A) -protokollat, MCP-työkalun kutsut ja REST API -pyynnöt.Keskittämällä henkilöllisyyden hallintaa Flex Gateway -kerroksessa lähtevien todennuskäytäntöjen avulla yritykset voivat suojata koko agentin verkostonsa muokkaamatta taustapalveluita tai agentteja.

Tämä asiakirja käsittelee identiteetin propagoinnin haasteen käyttämällä edistyvää sarjaa skenaarioita, joista jokainen tuo lisää monimutkaisuutta. Yhteensä nämä skenaariot osoittavat, miksi luotettu agentin identiteetti on olennainen vaatimus kaikkien yritystason agenttien käyttöönotolle.

Tavallisessa sovelluksessa henkilöllisyyden kulku (OAuth JWT -kulku) on yksinkertainen: Käyttäjä kirjautuu sisään, saa valtuuden ja sovellus käyttää valtuutta käyttääkseen taustaresursseja. Valtuus upotetaan käyttäjän henkilöllisyyden kanssa – mukaan lukien kuka hän on ja mitä hän on valtuutettu tekemään – ja se toimii jokaisen pyynnön yhteydessä. Puheluketju on lyhyt, tavallisesti yksi tai kaksi hyppiä, ja identiteetin leviäminen ratkaistaan.

Agenttien arkkitehtuurit sisältävät kuitenkin paljon pidempiä puheluketjuja, joissa yksi käyttäjäpyyntö saattaa näkyä useissa agenteissa, taustapalveluissa ja mallin kontekstiprotokollan (MCP) palvelimissa.Jokainen pyynnön kohde muodostaa erillisen hyppyn. Vaikka nämä haasteet – kuten monivaiheisen identiteetin propagointi, yhdistetyt valtuutusmallit, toimialueiden väliset luottamusrajat – ovat yleisiä kaikissa jaetuissa API-määrityksissä, tämänhetkinen ekosysteemi reagoi oletusarvoisesti eri tavalla.__ Nykyään agentilta agentille- ja agentilta API:lle -viestintävaihtoehdot perustuvat asiakastunnuksiin, API-avaimiin tai jaettuihin salaisuuksiin. Tämä tarkoittaa, että:

Käyttäjän henkilöllisyys menetetään oletusarvoisesti. Kun agentti kutsuu MCP-palvelinta tai downstream API -rajapintaa asiakassovelluksen tunnuksilla, pyyntö sisältää agentin palvelun identiteetin, eikä loppukäyttäjän. Alempana oleva palvelu ei voi tietää, kuka käyttäjä käynnisti toiminnon, joten käyttäjäkohtainen valtuutus ja kirjausketjut ovat mahdottomia.
Yhdistettyjen valtuutusten tarpeet ohitetaan. Kaikki myöhemmät palvelut eivät vaadi käyttäjäkontekstia.Vaikka jotkin hallitsevat käyttäjäkohtaisia tietoja, kuten transaktioita tai portfolioita, toiset tarjoavat julkista tai järjestelmätason dataa, kuten viitemateriaalia tai markkinatrendejä.Koska tämänhetkinen standardi perustuu yksinomaan asiakastunnuksiin, näiden tarpeiden erottaminen tai käyttäjän identiteetin valikoiminen ei ole mahdollista vain tarvittaessa.
Toimialueiden välisiä Trust-rajoituksia ei käsitellä. B2B- ja säänneltyjen skenaarioiden agenttien täytyy ehkä vuorovaikuttaa täysin erillisten henkilöllisyydentarjoajien (IdPs) hallitsemien järjestelmien kanssa. Esimerkiksi ulkoinen pankkijärjestelmä ei voi tulkita yrityksen kertakirjautumisen (SSO) valtuutta, mutta sen täytyy silti saada käyttäjän suostumus ja tarkoitus. Asiakastunnusten kululla ei ole tätä mekanismia.

Tämä johtaa siihen, että organisaation vaatimus käyttäjille kohdistettavan vähiten käyttöoikeuksia käyttävän käyttöoikeuden ja nykyisen ekosysteemin riippuvuus palvelutason todennuksesta, jolla ei ole käyttäjäkontekstiä, ovat erillään. Tämän aukon sulkeminen vaatii tarkoituksenmukaisen ja kerroksittaisen lähestymistavan identiteetin leviämiseen. Seuraavat skenaariot kuvaavat näitä käsitteitä käyttämällä fiktiivistä fintech-sovellusta Finport, joka tarjoaa käytännön esimerkkejä näistä arkkitehtuurikuvioista.

Finport on kuluttajille tarkoitettu fiktiivinen Fintech-portfolion hallinta -verkkosovellus, jota tukee agenttiarkkitehtuuri. Agent Broker (luotu käyttämällä MuleSoft Agent Brokeria) koordinoi useita myöhempiä agentteja ja MCP-palvelimia käyttäjäpyyntöjen täyttämiseksi.

Finport näyttää kolme ydintoimintoa, joilla jokaisella on oma identiteettivaatimuksensa:

"Näytä minulle portfolioni.": Käyttäjä pyytää henkilökohtaisia omistusosuuksiaan ja transaktiohistoriaansa. Koska nämä tiedot koskevat vain käyttäjiä, alempien portfolio palveluagenttien ja portfolio MCP -palvelimen täytyy tietää, mitä käyttäjätietoja haluat palauttaa ja varmistaa, että käyttäjällä on oikeus käyttää niitä. Käyttäjän identiteetti täytyy levittää jokaisen hyppyn kautta.
"Mikä on tämänhetkinen markkinatrendi?": Käyttäjä pyytää julkisia markkinatietoja ja omaisuuksien hintoja. Koska data on julkinen eikä se vaihtele käyttäjän mukaan, myöhemmät Market Data Agent- ja Asset Market MCP Server -palvelimet eivät tarvitse tai odota käyttäjän vaikutusalueeseen perustuvaa valtuutta. Välittäjän omat palvelun tunnukset riittävät.
"Siirrä 5 000 dollaria ulkoiseen säästötiliini.": Käyttäjä käynnistää varojen siirron pankkiin, joka käyttää toista henkilöllisyydentarjoajaa (esimerkiksi Auth0 Okta-arvon sijaan). Käyttäjän Finport-valtuus ei ole merkityksellinen pankin järjestelmälle. Käyttäjän täytyy todentaa itsensä suoraan pankista (suorassa keskustelussa) ennen kuin siirto voidaan jatkaa.

Jokainen näistä ominaisuuksista kartoitetaan eri identiteetin propagointikuvioon. Seuraavat skenaariot luodaan asteittain vakiomuotoisesta perustasosta (ilman agentteja) jokaisen erillisen kuviossa, joka osoittaa, miten Flex Gateway -ominaisuuden lähtevät käytännöt käsittelevät kunkin vaatimuksen muokkaamatta agentteja tai taustapalveluita.

Ennen kuin esittelet agentteja, on tärkeää määrittää perustasot: käyttäjä, joka todentaa itsensä asiakassovelluksella ja käyttää taustapalvelua.

Kulku:

Käyttäjä avaa Finportin ja hänet ohjataan henkilöllisyydentarjoajan sisäänkirjautumissivulle (esimerkiksi Okta) .
Käyttäjä todentaa itsensä (käyttäjänimi, salasana, SSO, monimenetelmäinen todennus (MFA) ja muut vaatimukset).
Henkilöllisyydentarjoaja myöntää Finport-sovellukselle allekirjoitetun JWT-käyttöoikeusvaltuuden.
Finportilla on nyt käyttäjävaltuus, joka edustaa käyttäjän henkilöllisyyttä: kuka ne ovat, mitä vaikutusalueita niille on myönnetty ja milloin valtuus vanhenee. Se voi esittää sen mille tahansa myöhemmälle palvelulle tämän käyttäjän puolesta.

Mitä tämä määrittää: Tämä prosessi noudattaa vakiomuotoista OAuth 2.0 -arkkitehtuurikuviota. Luotetun henkilöllisyydentarjoajan vahvistama alustava käyttäjävaltuus on olennainen perusta kaikille myöhemmille toiminnoille. Jokainen myöhempi skenaario perustuu tähän valtuuteen.

Kysymys: Kun käyttäjä on todennettu, hän käynnistää toimintoja, kuten rahoitussiirtoja, markkina-analyysejä tai portfolion tarkastuksia. Nämä pyynnöt käsitellään agenttien välittäjän kautta ja ne voivat sisältää useita myöhempiä agentteja tai MCP-palvelimia. Tämä herättää tärkeitä kysymyksiä: Miten käyttäjän henkilöllisyyttä säilytetään näissä jaetuissa pyynnöissä? Mitä tapahtuu, kun alempi palvelu käyttää täysin muuta henkilöllisyydentarjoajaa?

Käyttäjä pyytää Finport-agenttia "Näyttämään portfolioni". Tämä vuorovaikutus käynnistää taustaketjun, joka alkaa Finport Agent Brokerilla, joka on laadittu käyttämällä MuleSoft Agent Brokeria. Välittäjä siirtää tehtävän Portfolio palveluagentille, joka puolestaan kyselee Portfolio MCP -palvelinta. Käyttäjän alustavan todennusvaltuuden täytyy nyt siirtyä useiden siirtojen läpi käyttääkseen pyydettyjä porttitietueita.

Alkuperäisen valtuuden välittäminen rikkoo vähiten käyttöoikeuksia -periaatetta, kun taas palvelutilin käyttäminen menettää käyttäjän henkilöllisyyden.

Finport-agentti saa käyttäjän valtuuden, mutta se ei voi yksinkertaisesti välittää samaa valtuutta portfolio palveluagentille, koska se rikkoisi vähiten käyttöoikeuksia koskevaa periaatetta eikä se sovellisi asianmukaisesti alemman palvelun pyyntöä. Palvelutilin käyttäminen puolestaan johtaa kokonaisvaltaiseen käyttäjän henkilöllisyyden menettämiseen. Portfolio palveluagentti ja Portfolio MCP -palvelin eivät tiedä, mille käyttäjälle portfolio palautetaan, ja kirjausketju kohdistaisi kaikki toiminnot välittäjän palvelun identiteettiin loppukäyttäjän sijaan.

Flex Gateway ratkaisee nämä identiteetin propagoinnin monimutkaisuudet läpinäkyvästi sen lähtevän OAuth 2.0 -valtuuden vaihtokäytännön avulla. Tämä ratkaisu havaitsee lähtevät pyynnöt joka kerta, kun puheluketju hyppää, ja vaihtaa saapuvan käyttäjävaltuuden henkilöllisyydentarjoajalle uudelle tunnukselle, joka on tarkoitettu vain alempaan palveluun. On-Behalf-Of (OBO) -käytäntö tukee sekä OAuth 2.0 Token Exchange (RFC 8693) että Microsoft Entra ID On-Behalf-Of -protokollia.

Tärkeimmät arkkitehtoniset hyödyt: Koko prosessin käsittelee Flex Gateway -lähtevä käytäntö. Välittäjä ja agentit sisältävät todennuslogiikan, joka on nolla. Sen sijaan ne keskittyvät pelkästään liiketoimintalogiikkaan, kun taas yhdyskäytäväkerros pakottaa identiteetin leviämisen.

Kulku:

Käyttäjä todentaa itsensä Okta:lla ja Finport-sovellus lähettää pyynnön Flex-yhdyskäytävän kautta.
Välittäjä saa vahvistetun käyttäjävaltuuden ja määrittää, mikä palveluagentti tarvitaan.
Flex Gateway -lähtevä OBO-käytäntö vaihtaa käyttäjävaltuuden henkilöllisyydentarjoajan kanssa valtuuden, joka on rajoitettu portfolio palveluagentille.
Portfolio palveluagentti saa asiaankuuluvan vaikutusalueen valtuuden ja kutsuu Portfolio MCP -palvelinta.
Flex Gateway vaihtaa valtuuden uudelleen, tällä kertaa MCP-palvelimelle.
Portfolio MCP -palvelin palauttaa käyttäjän portfolion tiedot.
Täysi kirjausketju on olemassa. Jokainen hyppy johtuu alkuperäisestä loppukäyttäjästä.

Miksi tämä on tärkeää: Ilman OBO-valtuuden vaihtoa yritysten täytyy valita välittää alkuperäinen valtuus, joka rikkoo vähiten käyttöoikeuksia, tai käyttää palvelutilejä, jotka saattavat menettää käyttäjän henkilöllisyyden. OBO-kuvio poistaa tämän kompromissin, koska käyttäjän henkilöllisyys säilytetään jokaisella hyppäyksellä, jokainen valtuus on rajoitettu kohteeseensa, ja agentit itse eivät ole täysin tietoisia henkilöllisyyden mekanismeista.

Kaikki downstream-palvelut eivät vaadi käyttäjäkontekstia. Käyttäjä kysyy Finport-agentilta, "Mikä on tämänhetkinen markkinatrendi?" Toisin kuin skenaariossa 1 olevassa portfolion pyynnössä, markkinatrenditiedot ovat julkisia, kun ne eivät muutu käyttäjän mukaan. Alhainen Market Data Agent ja Asset Market MCP Server eivät tarvitse tai odota käyttäjän vaikutusalueeseen perustuvaa valtuutta.

Käyttäjävaltuuksien laajentaminen, kun niitä ei tarvita, laajentaa hyökkäysaluetta.

Jos Finport Agent Broker propagoi käyttäjän valtuuden Market Data Agent -palveluun käyttämällä skenaarion 1 OBO-kuviota, se toimisi, mutta ei tarpeellista. Käyttäjävaltuuksien monistaminen, kun niitä ei tarvita, laajentaa hyökkäyspinta-alaa, luo tarpeettomia riippuvuuksia henkilöllisyydentarjoajasta valtuuksien vaihtoa varten ja rikkoo vähiten käyttöoikeuksia koskevaa periaatetta. Markkinatietojen agentin täytyy vain tietää, että pyyntö tulee valtuutetusta palvelusta, eikä mitä käyttäjä kysyy.

Flex Gateway:n Outbound OAuth 2.0 Client Credentials -käytäntö käsittelee tämän avoimesti. Käytännöt eivät vaihda käyttäjän valtuutta, vaan ne syöttävät välittäjän omat palvelun tunnukset asiakkaiden tunnusten myöntämisen kautta lähtevään pyyntöön. Alhainen markkinatietojen agentti saa oikein todennetun palvelutasovaltuuden, jossa käyttäjäidentiteettiä ei lisätä, koska sellaista ei tarvita.

Tärkeimmät arkkitehtoniset hyödyt: Henkilöllisyyden propagointistrategia ei sovellu kaikille, vaan se määritetään alempana olevalle reitille datan luonteen ja kohdepalvelun vaatimusten perusteella. Flex-yhdyskäytännöt sallivat tämän määrittämisen reitittäin. Sama Finport Agent Broker voi osallistua OBO-kulkuihin (skenaariossa 1) ja S2S-kulkuihin ilman koodimuutoksia. Poistumisen yhdyskäytännön kokoonpano määrittää, mitä kuviota sovelletaan alempaan puheluun.

Kulku:

Käyttäjä kysyy Finport-agentilta, "Mikä on tämänhetkinen markkinatrendi?"
Välittäjä määrittää, että pyynnön täyttäminen vaatii Markkinointidatan agentin.
Flex Gateway -lähtevien asiakastunnusten käytäntö saa palvelutason valtuuden käyttämällä välittäjän omia tunnuksia (käyttäjän valtuutta ei vaihdeta tai levitetä).
Markkinatietojen agentti vastaanottaa asianmukaisesti todennetun palvelupyynnön ja kutsuu Omaisuuden markkinan MCP-palvelinta.
Omaisuuden markkinan MCP-palvelin palauttaa julkisen markkinatiedot.
Ketju ei sisällä käyttäjäidentiteettiä suunnitellusti, koska sitä ei tarvita tämäntyyppisille tiedoille.

Miksi tämä on tärkeää: Flex Gateway -käytäntöihin perustuva kehysjärjestelmä sallii arkkitehtien valita jokaiselle vuorovaikutukselle optimaalisen identiteettimallin, mikä ratkaisee vaikean valinnan yleisen käyttäjävaltuuksien leviämisen välillä — mikä lisää kustannuksia ja tietoturvariskejä — ja globaalin palvelutilin käytön välillä, mikä uhkaa käyttäjäkontekstiä ja vaatimustenmukaisuutta.

Monimutkaisin identiteettiskenaario ilmenee, kun agentin täytyy vuorovaikuttaa järjestelmän kanssa, jota hallitsee täysin eri henkilöllisyydentarjoaja, joka ei tunnista olemassa olevaa käyttäjävaltuutta.

Skenaario: Finport-käyttäjä pyytää Finport-agenttia "siirtämään 5 000 dollaria ulkoiseen säästötiliini." Tämä pyyntö sisältää kaksi erillistä downstream-polkua:

Palveluportaalin palveluagentti (OBO) -polku käyttäjän omistusosuuksien vahvistamiseksi
Transaktion agentti → Transaktion MCP -palvelin → Käyttäjän pankkipolku todellisen siirron suorittamiseen

Maksutapahtumien agentin täytyy vuorovaikuttaa käyttäjän pankin kanssa, joka käyttää omaa henkilöllisyydentarjoajaansa. Käyttäjän Okta-valtuus Finportista ei ole merkityksellinen pankin järjestelmälle, koska pankilla ei ole Trust Finportin henkilöllisyydentarjoajan kanssa. OBO-kuvio (skenaariosta 1) tai S2S-kuvio (skenaariosta 2) eivät voi ratkaista tätä ongelmaa. OBO vaihtaa valtuuksia samassa henkilöllisyydentarjoajassa, ja S2S käyttää palvelun tunnuksia, jotka eivät sisällä käyttäjän identiteettiä ollenkaan. Pankki vaatii käyttäjää todentamaan itsensä suoraan omilla pankkitunnuksillaan, mahdollisesti MFA:lla.

Flex-yhdyskäytävän lähtevän A2A-valtuutuskoodin käytäntö käyttää agentin keskustelussa haasteiden ja vastausten mekanismia. Jos toissijainen valtuus puuttuu, kun pankkiin otetaan yhteyttä, käytäntö palauttaa todennusta vaativan haasteen. Tämä haaste sisältää kaikki tarvittavat tiedot — kuten päätepisteet, vaikutusalueet ja PKCE-parametrit — jotta asiakassovellus voi käynnistää OAuth 2.0 -kulun pankin tarjoajan kanssa.

Sen jälkeen Finport-sovellus näyttää pankin sisäänkirjautumisen suoraan käyttäjän todentamista varten. Kun tämä on valmis, asiakassovellus palauttaa A2A-pyynnössä olevan valtuuden. Käytäntö noutaa tämän valtuuden pankin järjestelmälle ja poistaa sen viestin tekstiosasta tietoturvan varmistamiseksi.

Tärkeimmät arkkitehtoniset hyödyt: Portaalikäytännön kerros organisoi koko toimialueiden välisen todennusprosessin varmistaakseen, että välittäjä tai agentit eivät koskaan vuorovaikuta raakatunnuksilla tai vaadi Knowledgea pankin henkilöllisyydentarjoajasta. Käyttämällä tätä haasteiden vastausten kehysjärjestelmää käyttäjät voivat hallita seuraavia kohteita täysin: ne tarjoavat suostumuksen todennukseen ulkoisilla järjestelmillä, kun taas tuloksena oleva valtuus lähetetään turvallisesti käytäntökerroksen kautta.

Kulku:

Käyttäjä pyytää Finportia käynnistämään siirron. Pyyntö kulkee välittäjän läpi.
Välittäjä suositellaan käyttämällä portfoliota (OBO) omistusosuuksien vahvistamiseen ja transaktiota (In-Task) siirron suorittamiseen.
Transaktiopolku käynnistää todennusta vaativan haasteen Flex-yhdyskäytävän Tehtävä-käytännöstä.
Haaste leviää takaisin Finport-sovellukseen, joka esittää pankin sisäänkirjautumiskulun käyttäjälle suoraan.
Käyttäjä todentaa itsensä pankkinsa kautta, mukaan lukien MFA tarvittaessa.
Seuraava A2A-pyyntö sisältää pankkivaltuuden. Käytäntö noutaa sen, asettaa sen Valtuutus-otsakkeeseen ja välittää pyynnön.
Transaktion MCP-palvelin vastaanottaa pyynnön pankin valtuudella ja suorittaa siirron.

Miksi tämä on tärkeää: Toimialueiden välinen identiteetti on tärkeä haaste agenttien arkkitehtuurissa. Ilman tehtävän sisäistä todennusta yritysten täytyy joko luoda monimutkaisia Trust valmiiksi kaikkien verkoston henkilöllisyydentarjoajien välille tai pyytää käyttäjiä antamaan agenteille pankkitunnuksia. Tehtävässä oleva kuvio ratkaisee tämän sallimalla suoran käyttäjien todennuksen ulkoisilla tarjoajilla. Käytäntö hallitsee valtuuksien mekanismeja ja pitää agentit irti ulkoisista identiteettoimialueista.

Kaikissa kolmessa skenaariossa yksi arkkitehtoninen periaate sisältää: Identiteetin leviämistä käytetään yhdyskäytävän kerroksessa, ei agenteissa tai palveluissa. Agentit ja MCP-palvelimet sisältävät nollatodennuslogiikkaa. Heidän roolinsa rajoittuu todennettujen pyyntöjen käsittelyyn ja tulosten palauttamiseen, kun taas Flex Gateway -lähtevä käytäntökerros hallitsee kaikkia identiteettiin liittyviä toimintoja.

Tämä toimii, koska Flex Gatewayn lähtevät todennuskäytännöt havaitsevat liikenteen oikeasta paikasta: kun agentti on tehnyt reitityspäätöksensä, mutta ennen kuin pyyntö saapuu alempaan palveluun. Käytäntö muuntaa valtuuden – olipa kyseessä sitten OBO-vaihto, asiakkaan tunnusten syöttö tai tehtävässä oleva haasteen vastaus – ja lähettää oikean todennetun pyynnön. Alempi palvelu ei koskaan huomaa eroa, joten agentin ei tarvitse koskaan huolehtia. Todennuslogiikka on keskitetty yhdyskäytävään, ei eri palveluihin. Taustapalvelut eivät vaadi koodin muutoksia, ja samaa käytännön kokoonpanoa voidaan käyttää uudelleen useissa reiteissä.

Tämä lähestymistapa on myös protokollan agnostic. Koska käytännöt toimivat HTTP-kerroksella, niitä sovelletaan yhdenmukaisesti riippumatta siitä, kommunikoiko agentti REST:n, MCP:n, A2A:n tai Webhooksin kautta. Kaikki A2A- ja MCP-liikenne reititetään Flex Gatewayn kautta, jotta käytäntöjä sovelletaan kaikkiin päätepisteisiin, mikä tarkoittaa, että identiteettien leviämistä noudatetaan yhdenmukaisesti viestintäprotokollasta riippumatta.

Kolme yhdistettävää kuviota kattavat agenttien arkkitehtuurin identiteettivaatimusten kokonaisuuden:

Kuvio	Käytäntö	Käyttäjän identiteetti	Käyttäjän vuorovaikutus	Käyttöskenaario
Käyttöönotettu (OBO)	OAuth 2.0 OBO-tunnusten injektiokäytäntö	Säilytetty	Ei mitään (läpinäkyvä)	Käyttäjäkohtaiset tiedot samassa Trust toimialueessa
Palvelin palvelimelle (S2S)	lähtevät OAuth 2.0 -asiakastunnukset	Ei propagoitu	Ei mitään	Julkinen data, järjestelmätason toiminnot
Tehtävän sisäinen valtuutuskoodi	Lähtevä A2A-valtuutuskoodi tehtävässä	Ensisijainen + Toissijainen	Pakollinen (suoratodennus)	Toimialueiden väliset, usean henkilöllisyydentarjoajan, riskialttiat toiminnot

Nämä kuviot eivät sulje toisiaan pois. Kuten Finport-skenaariot näyttävät, yksi agenttien välittäjä voi käyttää OBO:a yhdelle alempana toimivalle puhelulle, S2S:llä toiselle ja Tehtävässä kolmannelle. Kunkin lähtevän reitin käytännön kokoonpano määrittää, mikä kuvio on käytössä. Agentin koodia ei muuteta eikä palvelua muokata, vain käytäntöä.

Yllä kuvatut yhdyskäytävän pakottamat kuviot suojaavat yksittäisiä vuorovaikutuksia, mutta identiteettien leviäminen ei ole erillinen huolenaihe. Se on laajemman MuleSoft Agent Fabric -hallintamallin perustasoa. Agent Fabric perustuu neljään pilariin, niin kuin Agentin kangas syventyy: Discover, Orchestrate, Govern ja Observe, jotka kaikki ovat riippuvaisia luotettavasta identiteettiketjusta toimimaan tehokkaasti.

:Tutki Agenttien rekisteri kattaa agentit ja heidän ominaisuutensa. Agenttien metadata, mukaan lukien todennusvaatimukset, sallii välittäjien ymmärtää, mitä identiteettikuvioita kukin agentti odottaa.
Orkestraatti: Agent Broker koordinoi usean agentin työnkulut. Flex Gateway käsittelee identiteetin transformaation läpinäkyvästi jokaisella hyppykerralla, jotta välittäjä voi keskittyä tehtävien pilkkomiseen ja reitittämiseen.
:Hallitse Kaikki A2A- ja MCP-liikenne reititetään Flex-yhdyskäytävän kautta, vaikka kohdejärjestelmä ei olisikaan suojattu, jotta käytäntöjä sovelletaan kaikkiin päätepisteisiin. Lähtevät todennuskäytännöt ovat osa hallintakerrosta.
Huomioi: Agent Visualizer tarjoaa reaaliaikaisen havaittavuuden agenttien vuorovaikutusten dynaamisen ja interaktiivisen kartan avulla. Kun käyttäjäidentiteetti säilytetään joka kerta, seuranta ja lokit tarjoavat käyttäjille kohdistettavia kirjausketjuja agenttien verkostossa.

Ilman luotettua identiteetin propagointia hallinta ei ole täydellistä. Voit katalogoida ja orkestroida agentteja, mutta et voi varmistaa, että he toimivat käyttäjän valtuutuksen rajoissa. Trusted Agent Identity sulkee tämän aukon varmistaakseen, että tietoturva ja käyttäjäkonteksti pysyvät keskeisellä sijalla agenttien työnkuluissa.

Näiden kuvioiden toteuttaminen:

Ymmärrä lähtevien käytäntöjen hakemisto. Tutustu Flex Gatewaylle saatavilla oleviin koko joukkoon lähteviä todennuskäytäntöjä.
Aloita OBO:lla. OAuth 2.0 -valtuuden vaihto -käytäntö kattaa yleisimmät identiteetin propagointitarpeet: käyttäjän asiayhteyden säilyttäminen agenteissa.
Tehtävän sisäinen lisäys toimialueiden välisille skenaarioille: Kun agenttiesi verkosto ylittää Trust-rajat, A2A-valtuutuskoodin käytäntö tarjoaa haasteiden ja vastausten mekanismin, jolla käyttäjä voi noutaa toissijaisia tunnuksia.
Vaikutusalustan agentin kangas. Määritä agenttiesi verkosto agenttien ja agenttien YAML-verkostossa käytäntöjen kokoonpanoilla, jotka määrittävät identiteettimallin per reitti. Sovellusalusta käsittelee loput.

Lisätietoja toteutuksesta on toteutusoppaassa.

Nikhil Aggarwal on arvostettu insinööri Salesforcessa, jossa hän johtaa MuleSoft- ja Salesforce Automation Cloud -arkkitehtuuria. Nikhililla on yli 18 vuoden kokemus suurten tuotteiden tarjoamisesta ja hän on intohimoinen skaalattavaan arkkitehtuuriin, intuitiivisiin kehityskokemuksiin ja tehokkaiden tiimien rakentamiseen. Ennen Salesforcea hän johti useita Microsoft Power Platform-, Dataverse- ja Office 365 -aloitteita konseptista julkaisuun. Hänen työnsä edustaa edelleen sitä, miten nykyaikaiset yritykset yhdistävät järjestelmiä, automatisoivat työnkulkuja ja avaavat liiketoiminnan arvoa tekoälyn alkuvaiheessa.

Akash Trivedi on Salesforcen insinöörijohtaja, jolla on yli 18 vuoden kokemus skaalattavien, turvallisten ja tehokkaiden yritysjärjestelmien rakentamisesta. Hän työskentelee tekoälyn, yritysarkkitehtuurin ja prosessiä koskevan älykkyyden risteyksessä keskittyen pilvipohjaisiin alustoihin ja luotettaviin ratkaisuihin, jotka toimivat laajalti. Ennen Salesforcea hänellä oli insinöörirooleja Microsoftissa, jossa hän osallistui tuotteisiin, kuten Copilot, Dataverse ja Power Platform.