Trusted Agent Identity voor de Agentic Enterprise

Naarmate bedrijven het agentische paradigma omarmen, ontstaat er een nieuwe beveiligingsuitdaging: Hoe stroomt de identiteit van eindgebruikers door een netwerk van autonome AI-agenten? In traditionele API-architecturen authenticeert een gebruiker eenmaal en roept de toepassing back-endservices aan namens de gebruiker. De identiteitsketen is kort, goed begrepen en wordt doorgaans beheerd binnen één Trust domein. Agentische architecturen bieden echter veel langere ketens waarin één verzoek wordt verspreid over verschillende agenten, services en Model Context Protocol-servers (MCP-servers), waarbij elk potentieel servicegrenzen, Trust domeinen en zelfs organisatorische grenzen overschrijdt. Zonder een weloverwogen strategie voor identiteitsverspreiding staan ondernemingen voor de keuze tussen beveiliging en functionaliteit – een dilemma waarmee geen architect te maken zou moeten krijgen.

MuleSoft lost de complexiteiten van identiteitsverspreiding op met de voorziening Trusted Agent Identity. Deze oplossing maakt gebruik van een op beleid gebaseerde, door gateways beheerde strategie om ervoor te zorgen dat de identiteit van eindgebruikers wordt gehandhaafd binnen verschillende interactietypen—inclusief A2A-protocollen (agent-naar-agent), MCP-toolaanroepen en REST-API-verzoeken. Door identiteitsbeheer op de Flex Gateway-laag te centraliseren via uitgaande authenticatiebeleidsvormen, kunnen ondernemingen hun gehele agentennetwerk beveiligen zonder back-endservices of agenten te wijzigen.

Dit document doorloopt de uitdaging van identiteitsverspreiding aan de hand van een progressieve reeks scenario’s, waarbij elke scenario extra complexiteit introduceert. Samen illustreren deze scenario’s waarom Trusted Agent Identity een basisvereiste is voor elke implementatie van agenten op ondernemingsniveau.

In een conventionele toepassing is de identiteitsstroom (OAuth JWT-stroom) eenvoudig: De gebruiker logt in, ontvangt een token en de toepassing gebruikt het token voor toegang tot back-endresources. Het token is ingebed in de identiteit van de gebruiker, inclusief wie deze is en waartoe deze gemachtigd is, en gaat met elk verzoek mee. De aanroepketen is kort, meestal één of twee sprongen, en identiteitsverspreiding is opgelost.

Agentische architecturen bieden echter veel langere gespreksketens waarin één gebruikersverzoek kan worden verspreid over verschillende agenten, back-endservices en Model Context Protocol-servers (MCP-servers).Elke bestemming van het verzoek vormt een afzonderlijke sprong. Hoewel deze uitdagingen – zoals multi-hop identiteit propagatie, gemengde autorisatiemodellen, cross-domein Trust grenzen – zijn gemeenschappelijk in elke gedistribueerde API set-up, wat is onderscheidend is hoe het huidige ecosysteem reageert standaard .. Vandaag de dag is het dominante patroon voor agent-naar-agent- en agent-naar-API-communicatie gebaseerd op clientinloggegevens, API-sleutels of gedeelde geheimen. Dit betekent:

Gebruikersidentiteit gaat standaard verloren. Wanneer een agent een MCP-server of downstream-API aanroept met behulp van clientinloggegevens, draagt het verzoek de service-identiteit van de agent en niet die van de eindgebruiker. De service verderop in de stroom weet niet welke gebruiker de actie heeft geïnitieerd, waardoor autorisatie- en controletrajecten per gebruiker onmogelijk zijn.
Gemengde autorisatiebehoeften worden genegeerd. Niet elke service verderop in de stroom vereist gebruikerscontext.Sommigen beheren gebruikersspecifieke informatie zoals transacties of portefeuilles, terwijl andere gegevens op openbaar niveau of op systeemniveau bieden, zoals referentiemateriaal of markttrends.Omdat de huidige standaard uitsluitend op clientinloggegevens is gebaseerd, is er geen manier om onderscheid te maken tussen deze behoeften of om gebruikersidentiteit alleen selectief door te geven wanneer dat nodig is.
Grenzen van Cross-domain Trust worden niet aangepakt. Agenten in B2B en gereguleerde scenario’s moeten mogelijk werken met systemen die worden beheerd door volledig afzonderlijke identiteitsleveranciers (IdP’s). Zo kan een extern banksysteem een Single Sign-On-token (SSO-token) van een bedrijf niet interpreteren, terwijl het toch de instemming en intentie van de gebruiker moet ontvangen. De stroom voor clientinloggegevens heeft hiervoor geen mechanisme.

Het resultaat is een kloof tussen de ondernemingsvereiste voor door de gebruiker toewijsbare toegang met de minste rechten en de afhankelijkheid van het huidige ecosysteem van authenticatie op serviceniveau zonder gebruikerscontext. Het dichten van deze kloof vereist een bewuste, gelaagde benadering van identiteitsverspreiding. Ter illustratie van deze concepten maken de volgende scenario’s gebruik van Finport, een fictieve fintech-toepassing, om praktische voorbeelden van deze architectonische patronen te geven.

Finport is een fictieve voor consumenten bestemde Fintech-webtoepassing voor portfoliobeheer, ondersteund door een agentische architectuur. Een Agentbroker (samengesteld met behulp van MuleSoft Agentbroker) coördineert meerdere agenten verderop in de stroom en MCP-servers om aan gebruikersverzoeken te voldoen.

Finport biedt drie kernfunctionaliteiten, elk met een eigen identiteitsvereiste:

“Laat me mijn portfolio zien.”: De gebruiker vraagt zijn of haar persoonlijke holdings en transactiehistorie op. Omdat deze gegevens gebruikersspecifiek zijn, moeten de downstream Portfolio serviceagent en Portfolio MCP Server weten welke gebruikersgegevens moeten worden geretourneerd en moeten ze controleren of de gebruiker gemachtigd is om er toegang toe te krijgen. Gebruikersidentiteit moet bij elke hop worden doorgegeven.
“Wat zijn de huidige markttrends?”: De gebruiker verzoekt om openbare-marktgegevens en activumprijzen. Omdat de gegevens openbaar zijn en niet per gebruiker verschillen, hebben de Market Data Agent verderop in de stroom en de Asset Market MCP Server geen token met gebruikersbereik nodig of verwachten deze niet. De eigen servicegegevens van de makelaar zijn voldoende.
“Maak 5000 dollar over naar mijn externe spaarrekening.”: De gebruiker initieert een fondsoverdracht naar een bank die een andere IdP gebruikt (bijvoorbeeld Auth0 in plaats van Okta). Het Finport-token van de gebruiker is betekenisloos voor het systeem van de bank. De gebruiker moet rechtstreeks bij de bank authenticeren (inline binnen het gesprek) voordat de overdracht kan doorgaan.

Elk van deze functionaliteiten verwijst naar een ander identiteitsverspreidingspatroon. De volgende scenario’s worden geleidelijk opgebouwd vanuit een standaard baseline (zonder agenten) door elk afzonderlijk patroon, ter illustratie van de manier waarop uitgaande beleidsvormen in Flex Gateway elke vereiste aanpakken zonder de agenten of back-endservices te wijzigen.

Voordat u agenten introduceert, is het essentieel om de baseline vast te stellen: een gebruiker die authenticeert met een clienttoepassing en toegang heeft tot een back-endservice.

De stroom:

De gebruiker opent Finport en wordt omgeleid naar de inlogpagina van de IdP (bijvoorbeeld Okta) .
De gebruiker authenticeert (gebruikersnaam, wachtwoord, SSO, multi-factorenauthenticatie (MFA) en eventuele andere vereisten).
De IdP verstrekt een ondertekend JWT-toegangstoken aan de Finport-toepassing.
Finport heeft nu een gebruikerstoken dat de identiteit van de gebruiker vertegenwoordigt: wie het zijn, welke bereiken ze hebben gekregen en wanneer het token verloopt. Het kan het namens deze gebruiker presenteren aan elke downstream service.

Wat dit vastlegt: Dit proces volgt het standaard OAuth 2.0-architectuurpatroon. Het initiële gebruikerstoken, gevalideerd door een vertrouwde IdP, dient als de essentiële basis voor alle daaropvolgende bewerkingen. Elk volgend scenario bouwt voort op dit token.

De vraag: Eenmaal geauthenticeerd, initieert de gebruiker acties zoals fondsoverdrachten, marktanalyse of portefeuillebeoordelingen. Deze verzoeken worden verwerkt via een Agentmakelaar en kunnen betrekking hebben op meerdere downstreamagenten of MCP-servers. Dit roept kritische vragen op: Hoe wordt de identiteit van de gebruiker onderhouden voor deze gedistribueerde verzoeken? Wat gebeurt er wanneer een downstream service een compleet andere IdP gebruikt?

De gebruiker vraagt de Finport-agent om “Toon me mijn portfolio”. Deze interactie activeert een back-endketen die begint met de Finport Agent Broker, die is samengesteld met behulp van MuleSoft Agent Broker. De broker draagt de taak over aan een Portfolio serviceagent, die op zijn beurt een query uitvoert op een Portfolio MCP Server. Het initiële authenticatietoken van de gebruiker moet nu meerdere hops doorlopen om toegang te krijgen tot de aangevraagde portfoliorecords.

Het doorgeven van het oorspronkelijke token schendt het principe van de minste rechten, terwijl het gebruik van een serviceaccount de identiteit van de gebruiker verliest.

De Finport Agent ontvangt het token van de gebruiker, maar kan dat token niet zomaar doorsturen naar de Portfolio serviceagent, omdat dit het principe van de minste rechten schendt en het verzoek voor de downstream service niet op de juiste manier zou bestrijken. Omgekeerd leidt het gebruik van een serviceaccount tot een totaal verlies van gebruikersidentiteit. De Portfolio serviceagent en de Portfolio MCP-server zouden geen manier hebben om te weten welke portefeuille van de gebruiker moet worden geretourneerd, en het controletraject zou elke actie toewijzen aan de service-identiteit van de makelaar in plaats van de eindgebruiker.

Flex Gateway lost deze identiteitspropagatiecomplexiteiten transparant op via het uitgaande OAuth 2.0-tokenuitwisselingsbeleid. Deze oplossing onderschept uitgaande verzoeken bij elke sprong in de aanroepketen, waarbij het inkomende gebruikerstoken wordt ingewisseld met het IdP voor een nieuw inloggegeven dat specifiek voor de downstream service is bedoeld. Het OBO-beleid (On-Behalf-Of) ondersteunt zowel OAuth 2.0-tokenuitwisseling (RFC 8693) als Microsoft Entra ID On-Behalf-Of.

Belangrijkste architectonische voordeel: Dit gehele proces wordt afgehandeld door het uitgaande Flex Gateway-beleid. De makelaar en agenten bevatten authenticatielogica van nul. In plaats daarvan richten ze zich puur op bedrijfslogica, terwijl de gatewaylaag identiteitsverspreiding afdwingt.

De stroom:

De gebruiker authenticeert met Okta en de Finport-toepassing verzendt een aanvraag via Flex Gateway.
De makelaar ontvangt het gevalideerde gebruikerstoken en bepaalt welke serviceagent nodig is.
Het uitgaande OBO-beleid van Flex Gateway wisselt het gebruikerstoken in met de IdP voor een token dat is gericht op de serviceagent Portfolio.
De Portfolio serviceagent ontvangt een goed bereiktoken en roept de Portfolio MCP Server aan.
Flex Gateway wisselt het token opnieuw uit, ditmaal voor de MCP Server.
De MCP-server Portfolio retourneert de specifieke portfoliogegevens van de gebruiker.
Er bestaat een volledig controletraject. Elke hop is toe te schrijven aan de oorspronkelijke eindgebruiker.

Waarom dit belangrijk is: Zonder OBO-tokenuitwisseling moeten bedrijven kiezen tussen het doorsturen van het oorspronkelijke token, dat de minste rechten schendt, en het gebruik van serviceaccounts, die gebruikersidentiteit dreigen te verliezen. Het OBO-patroon elimineert dit nadeel, omdat de identiteit van de gebruiker bij elke hop behouden blijft, elk token naar het doel ervan is gericht en de agenten zelf zich volledig niet bewust blijven van de identiteitsmechanismen.

Niet elke service verderop in de stroom vereist gebruikerscontext. De gebruiker vraagt de Finport-agent: “Wat zijn de huidige markttrends?” In tegenstelling tot het portfolioverzoek in scenario 1 zijn markttrendgegevens openbaar wanneer deze niet per gebruiker verschillen. De downstream Market Data Agent en Asset Market MCP Server hebben geen token met gebruikersbereik nodig of verwachten dit niet.

Het propageren van gebruikerstokens waar ze niet nodig zijn, vergroot het aanvalsoppervlak.

Als de Finport Agent Broker het token van de gebruiker zou doorgeven aan de Market Data Agent met behulp van het OBO-patroon uit scenario 1, zou het werken, maar niet nodig zijn. Door gebruikerstokens te propageren waar ze niet nodig zijn, wordt het aanvalsoppervlak vergroot, ontstaan onnodige afhankelijkheden van de IdP voor tokenuitwisselingen en wordt het principe van de minste rechten geschonden. De Market Data Agent hoeft alleen te weten dat het verzoek afkomstig is van een geautoriseerde service, niet van welke gebruiker het vraagt.

Het beleid Uitgaande OAuth 2.0-clientinloggegevens van Flex Gateway handelt dit transparant af. In plaats van het token van de gebruiker uit te wisselen, injecteert het beleid de eigen servicegegevens van de makelaar via een toekenning van clientinloggegevens in het uitgaande verzoek. De Market Data Agent verderop in de stroom ontvangt een correct geauthenticeerd serviceniveautoken waarbij geen gebruikersidentiteit wordt gepropageerd omdat er geen nodig is.

Belangrijkste architectonische voordeel: De strategie voor identiteitsverspreiding is niet ‘one-size-fits-all’, maar wordt bepaald per stroomafwaartse route op basis van de aard van de gegevens en de vereisten van de doelservice. Het uitgaande beleid van Flex Gateway maakt dit configureerbaar per route. Dezelfde Finport Agent Broker kan deelnemen aan zowel OBO-stromen (in scenario 1) als S2S-stromen zonder codewijzigingen. De beleidsconfiguratie voor de uitgaande gateway bepaalt welk patroon van toepassing is op welk gesprek verderop in de stroom.

De stroom:

De gebruiker vraagt de Finport-agent: “Wat zijn de huidige markttrends?”
De makelaar bepaalt dat de Market Data Agent nodig is om aan het verzoek te voldoen.
Het beleid voor uitgaande clientinloggegevens van Flex Gateway verkrijgt een serviceniveautoken met behulp van de eigen inloggegevens van de makelaar (er wordt geen gebruikerstoken uitgewisseld of verspreid).
De Market Data Agent ontvangt een correct geauthenticeerd serviceverzoek en roept de MCP-server van Activummarkt aan.
De MCP-server Activummarkt retourneert de openbare-marktgegevens.
Er is geen gebruikersidentiteit aanwezig in de keten omdat er geen identiteit nodig is voor dit type gegevens.

Waarom dit belangrijk is: Het beleidsgestuurde framework van Flex Gateway stelt architecten in staat om het optimale identiteitsmodel voor elke interactie te selecteren. Dit lost de moeilijke keuze op tussen universele gebruikerstokenverspreiding (die overhead- en beveiligingsrisico’s vergroot) en globaal gebruik van serviceaccounts, dat ten koste gaat van gebruikerscontext en naleving.

Het meest complexe identiteitsscenario doet zich voor wanneer een agent interactie moet hebben met een systeem dat wordt bestuurd door een compleet andere IdP, een systeem dat het bestaande gebruikerstoken niet herkent.

Het scenario: De Finport-gebruiker vraagt de Finport-agent om ”$ 5000 over te maken naar mijn externe spaarrekening”. Dit verzoek omvat twee afzonderlijke downstreamtrajecten:

Het OBO-pad (Portfolio Serviceagent) om de holdings van de gebruiker te verifiëren
Het pad Transactieagent → Transactie MCP-server → Bank van gebruiker om de feitelijke overdracht uit te voeren

De transactieagent moet een interactie hebben met de bank van de gebruiker, die zijn eigen IdP gebruikt. Het Okta-token van de gebruiker uit Finport is betekenisloos voor het systeem van de bank, omdat de bank geen Trust relatie heeft met Finport’s IdP. Noch het OBO-patroon (uit scenario 1), noch het S2S-patroon (uit scenario 2) kan dit oplossen. OBO wisselt tokens uit binnen dezelfde IdP en S2S gebruikt serviceinloggegevens die helemaal geen gebruikersidentiteit dragen. De bank vereist dat de gebruiker zich rechtstreeks authenticeert met zijn of haar eigen bankgegevens, waaronder mogelijk ook MFA.

Het beleid Uitgaande A2A in-task autorisatiecode voor Flex Gateway gebruikt een challenge-responsmechanisme binnen het gesprek tussen agenten. Als er een secundair token ontbreekt bij het opnemen van contact met de bank, retourneert het beleid een door de authenticatie vereiste challenge. Deze uitdaging omvat alle noodzakelijke details—zoals eindpunten, bereiken en PKCE-parameters—voor de client om een OAuth 2.0-stroom te starten met de provider van de bank.

De Finport-app geeft vervolgens de inlogpoging van de bank inline weer voor directe gebruikersauthenticatie. Eenmaal voltooid retourneert de client het token in het A2A-verzoek. Het beleid extraheert dit token voor het systeem van de bank en verwijdert het uit de hoofdtekst van het bericht om de beveiliging te waarborgen.

Belangrijkste architectonische voordeel: De gatewaybeleidslaag orkestreert het gehele interdomeinauthenticatieproces, waardoor wordt gegarandeerd dat noch de makelaar, noch de agenten ooit met ruwe inloggegevens werken of Knowledge van de IdP van de bank vereisen. Door dit framework voor uitdagingsreacties te gebruiken, behouden gebruikers de volledige controle: ze geven expliciete toestemming voor authenticatie met externe systemen, terwijl het resulterende token veilig wordt verzonden via de beleidslaag.

De stroom:

De gebruiker vraagt Finport om een overdracht te starten. Het verzoek gaat via de makelaar.
De makelaar waaiert uit, met behulp van de portefeuille (OBO) om holdings te verifiëren en de transactie (In-Task) om de overdracht uit te voeren.
Het transactiepad activeert een door de authenticatie vereiste uitdaging vanuit het beleid In-task voor Flex Gateway.
De uitdaging wordt teruggestuurd naar de Finport-toepassing, die de inlogstroom van de bank inline aan de gebruiker presenteert.
De gebruiker verifieert bij zijn of haar bank, inclusief MFA indien nodig.
Het banktoken wordt opgenomen in de daaropvolgende A2A-aanvraag. Het beleid extraheert het, stelt het in de koptekst Autorisatie in en stuurt de aanvraag door.
De Transaction MCP Server ontvangt het verzoek met het token van de bank en voert de overdracht uit.

Waarom dit belangrijk is: Identiteit tussen domeinen is een grote uitdaging in agentische architecturen. Zonder in-task authenticatie moeten ondernemingen vooraf complexe Trust relaties opzetten tussen elke IdPin in het netwerk of gebruikers vragen om bankgegevens aan een agent te verstrekken. Het In-Task-patroon lost dit op door directe gebruikersauthenticatie bij externe aanbieders toe te staan; het beleid beheert tokenmechanica terwijl agenten worden losgekoppeld van externe identiteitsdomeinen.

Voor alle drie de scenario’s geldt één architectonisch principe: Identiteitsverspreiding wordt afgedwongen op de gatewaylaag, niet binnen agenten of services. De agenten en MCP-servers bevatten nul authenticatielogica. Hun rol is beperkt tot het verwerken van geauthenticeerde verzoeken en het retourneren van resultaten, terwijl de uitgaande beleidslaag Flex Gateway alle identiteitsgerelateerde bewerkingen beheert.

Dit werkt omdat het uitgaande authenticatiebeleid van Flex Gateway verkeer op het juiste punt onderschept: nadat de agent zijn routeringsbeslissing heeft genomen, maar voordat het verzoek de downstream service bereikt. Het beleid transformeert het token - of het nu een OBO-uitwisseling, injectie van clientinloggegevens of in-task challenge-respons is - en stuurt een correct geauthenticeerd verzoek door. De downstream service kent nooit het verschil, daarom hoeft de agent er nooit om te geven. Authenticatielogica is gecentraliseerd bij de gateway, niet verspreid over services. De back-endservices vereisen geen codewijzigingen en dezelfde beleidsconfiguratie kan over meerdere routes worden hergebruikt.

Deze benadering is ook protocolonafhankelijk. Omdat de beleidsvormen op de HTTP-laag werken, zijn ze consistent van toepassing, ongeacht of de agent communiceert via REST, MCP, A2A of webhooks. Zoals gedocumenteerd in de Agent Fabric Deep Dive, wordt al het A2A- en MCP-verkeer gerouteerd via Flex Gateway om ervoor te zorgen dat beleidsvormen worden toegepast op elk eindpunt, wat betekent dat identiteitsverspreiding uniform wordt afgedwongen, ongeacht het communicatieprotocol.

Drie samenstelbare patronen bestrijken het volledige spectrum van identiteitsvereisten in een agentische architectuur:

Patroon	Beleid	Gebruikersidentiteit	Gebruikersinteractie	Gebruikscase
On-Behalf-Of (OBO)	Injectiebeleid voor OAuth 2.0-OBO-inloggegevens	Behouden	Geen (transparant)	Gebruikersspecifieke gegevens binnen hetzelfde Trust domein
Server-naar-server (S2S)	Uitgaande OAuth 2.0-clientgegevens	Niet gepropageerd	Geen	Openbare gegevens, bewerkingen op systeemniveau
In-task autorisatiecode	Uitgaande A2A in-task autorisatiecode	Primair + secundair	Verplicht (inline authenticatie	Domeinoverschrijdend, multi-identiteitsleverancier, bewerkingen met hoog risico

Deze patronen sluiten elkaar niet uit. Zoals uit de Finport-scenario’s blijkt, kan één agentmakelaar OBO gebruiken voor het ene gesprek verderop in de stroom, S2S voor het andere en In-Task voor een derde. De beleidsconfiguratie voor elke uitgaande route bepaalt welk patroon van toepassing is. Er zijn geen agentcodewijzigingen en geen servicewijzigingen, alleen beleid.

De hierboven beschreven door gateways afgedwongen patronen beveiligen individuele interacties, maar identiteitsverspreiding is geen geïsoleerd probleem. Het is een basislaag van het bredere governancemodel van MuleSoft Agent Fabric. Zoals beschreven in de Agent Fabric Deep Dive, is Agent Fabric gebouwd op vier pijlers: Ontdekken, Orkestreren, Beheren en Observeren, en elke component is afhankelijk van een betrouwbare identiteitsketen om effectief te functioneren.

Ontdekken: Het agentenregister catalogiseert agenten en hun mogelijkheden. Met metagegevens van agenten, inclusief authenticatievereisten, krijgen makelaars inzicht in welke identiteitspatronen elke agent verwacht.
Orkestreren: Agentmakelaar coördineert werkstromen voor meerdere agenten. Flex Gateway handelt de identiteitstransformatie bij elke hop transparant af, zodat de makelaar zich kan richten op taakontbinding en routering.
Regeren: Al het A2A- en MCP-verkeer wordt gerouteerd via Flex Gateway, zelfs als het doelsysteem niet is beveiligd, om ervoor te zorgen dat beleidsvormen op elk eindpunt worden toegepast. Beleidsvormen voor uitgaande authenticatie maken deel uit van de governancelaag.
Observeren: Agent Visualizer biedt real-time observatie door middel van een dynamische, interactieve kaart van agentinteracties. Omdat de gebruikersidentiteit bij elke sprong behouden blijft, bieden traceringen en logboeken door de gebruiker toewijsbare controletrajecten binnen het agentnetwerk.

Zonder vertrouwde identiteitsverspreiding is governance onvolledig. U kunt agenten catalogiseren en ordenen, maar u kunt er niet voor zorgen dat ze handelen binnen de grenzen van de autorisatie van de gebruiker. Trusted Agent Identity vult dit hiaat en zorgt ervoor dat beveiliging en gebruikerscontext centraal blijven staan in agentische werkstromen.

Als u deze patronen wilt implementeren:

Inzicht in de directory Uitgaand beleid. Bekijk de volledige set uitgaande authenticatiebeleidsvormen die beschikbaar zijn voor Flex Gateway.
Begin met OBO. Het OAuth 2.0-tokenuitwisselingsbeleid richt zich op de meest voorkomende behoefte aan identiteitsverspreiding: gebruikerscontext behouden binnen agenthops.
In-task toevoegen voor scenario’s tussen domeinen: Wanneer uw agentnetwerk Trust grenzen overschrijdt, biedt het A2A In-Task Authorization Code-beleid het uitdagings-reactiemechanisme voor het verkrijgen van secundaire inloggegevens van de gebruiker.
Hefboom Agent Fabric. Definieer uw agentnetwerk in de agent-netwerk-YAML met beleidsconfiguraties die het identiteitsmodel per route bepalen. Het platform doet de rest.

Raadpleeg de implementatiehandleiding voor bedrijven voor gedetailleerde implementatierichtlijnen.

Nikhil Aggarwal is een Distinguished Engineer bij Salesforce, waar hij architectuur leidt voor MuleSoft en Salesforce Automation Clouds. Nikhil heeft meer dan 18 jaar ervaring met het leveren van grootschalige producten en heeft een passie voor schaalbare architectuur, intuïtieve ontwikkelaarservaringen en het samenstellen van goed presterende teams. Voorafgaand aan Salesforce leidde hij meerdere initiatieven in Microsoft Power Platform, Dataverse en Office 365 van concept tot introductie. Zijn werk vormt nog steeds de manier waarop moderne ondernemingen systemen verbinden, werkstromen automatiseren en bedrijfswaarde ontsluiten in het AI-eerste tijdperk.

Akash Trivedi is een Director of Engineering bij Salesforce met meer dan 18 jaar ervaring in het bouwen van schaalbare, veilige en hoogwaardige ondernemingssystemen. Hij werkt op het snijvlak van AI, enterprisearchitectuur en process intelligence, met een focus op cloud-native platforms en betrouwbare oplossingen die op schaal opereren. Voor Salesforce bekleedde hij technische functies bij Microsoft, waar hij bijdroeg aan producten zoals Copilot, Dataverse en Power Platform.