Modern distributed agentic architectures demand secure, seamless, and context-aware identity propagation throughout services and agentic networks – whether human, machine, or agentic actors. Today, we’re excited to introduce a foundational capability for enterprise integration: Trusted Agent Identity for MuleSoft Agent Fabric.
This capability enables systems to carry precise user identity claims across boundaries, unlock just-in-time and in-context secondary authentication, and unify user-centric trust across web protocols and integration patterns – from A2A (Agent-to-Agent) to MCP (Model Context Protocol) and more generally beyond – to any APIs managed through Flex Gateways.
In particular, this solution leverages OAuth2 and OpenID Connect (OIDC) protocols with short-lived, access-scoped and signed security tokens, that include the identity of both ends of the communication link (eg client and serving agent or MCP server) along with the signing issuer (Identity Provider). This helps ensure that the agents and MCP interactions are responsible by default, without too many specific security requirements within individual agents.
The identity challenge in distributed agent integrations
In traditional architectures, once a request leaves the boundary of the originating context, user identity and authentication context are often lost or reduced to a generic token. While this works in user-system or system-system identity scenarios, an agentic network carries with it additional complexity.
In an agentic network, there can be multiple degrees of separation between the originating user, and the upstream service or agent taking action on behalf of that user. If traditional models of authentication are used in an agentic network, this can create issues such as:
- Coarse access decisions: All backend calls may use a single service identity in order to facilitate smooth operation of the network
- Limited audit and traceability of user intent due to the lack of propagation of user identity
- Reauthentication prompts for sensitive actions
- Security risks due to detached identity claims
What enterprises need is authenticated context that travels with the request – not just a generic bearer token – such that every service can make intelligent decisions based on who initiated the action, what they are authorized to do, and whether additional checks are required now.
What identity context propagation reveals
- Fine-grained authorization across agents: Services can make real-time access decisions using the actual user’s privileges, not a generic service account. This reduces blast radius and meets zero-trust principles. For example, a backend payment service can verify not just that the request originated from an orchestration gateway (such as Agent Broker), but that it was initiated by an authorized, risk-cleared user with the proper role.
- Just-in-time secondary authentication: Systems can trigger additional verification only when needed (eg high-risk transactions) without breaking flow: step-up prompts (MFA), contextual policies (location, device), and risk-adaptive responses. All of this is powered by propagated identity context.
- Auditability and traceability: Since identity claims carry through service chains, observability systems gain: user-centric trails, enhanced compliance reporting, and fine-tuned incident forensics.
- Consistent security across agents and systems: Whether an agent is third-party or homegrown, propagated identity context means that trust doesn’t stop at network boundaries. By abstracting identity concerns to the gateway level, you can enforce the same identity controls across any system, regardless of where it is hosted.
How existing standards enable identity propagation
At the heart of modern trust delegation are two protocols:
- OAuth 2.0: The industry standard for delegated authorization
- OpenID Connect (OIDC): An identity layer on top of OAuth 2.0 enabling authentication and identity claims
Together, these protocols provide on-behalf-of (OBO) token flows and identity claims via OIDC.
On-behalf-of (OBO) token flows
OAuth 2.0’s OBO flow allows an Agent or service to obtain a new access token from an authorization server on behalf of an authenticated user. This means:
- Service A can call Service B as the user
- Downstream services receive identity claims tied to the user, not just the caller service
- Authorization decisions can incorporate user context, not just static service credentials
- MuleSoft Flex Gateway, a key component of MuleSoft Agent Fabric, automates the protocol handshakes to simplify identity and access management for agents built on any framework and running in any on-prem or public cloud environments, including those managed by Salesforce or MuleSoft
OBO flows are essential for secure A2A and MCP interactions where downstream systems must trust not only that a request came from a service, but why and for whom.
Identity claims via OIDC
OIDC standardizes identity information in ID Tokens and JWT claims, such as sub (subject/user identifier), email, roles, groups, and custom claims representing entitlements, risk scores, and context.
By propagating these claims, systems achieve fine-grained authorization and contextual routing. Agents should request only the minimal access from users that is required to do their jobs. In error, rogue, or malicious situations, users may deny approving access to unexpected privileges.
Powered by MuleSoft Flex Gateway
Trusted Agent Identity is implemented by a key component of Agent Fabric, Flex Gateway. Through Agent Fabric, you can implement robust identity controls on any agent or service:
- agent scanner can discover the agents running in various enterprise environments (such as Google Vertex AI, Amazon Bedrock or Microsoft Copilot Studio).
- The discovered agents can be registered into Agent Registry, making them available for orchestration by Agent Broker.
- When the agents are part of an agent network, they need to communicate through Anypoint Flex Gateway. Trusted Agent Identity is enforced by policies at the gateway layer, abstracting away the need for agents or systems to implement these controls.
- Delegated user identity flows through the agentic network.
High-level flow: How it works
- User authenticates via OIDC at the edge (eg, API gateway)
- System issues an OIDC ID Token + OAuth 2.0 Access Token
- Downstream services use OAuth OBO flow via Flex Gateway to obtain new tokens on behalf of the user
- Tokens carry identity claims, including custom and contextual data
- Services make authorization or other related policy decisions using propagated claims
- When necessary, secondary authentication is invoked based on policy
This pattern ensures that every hop carries intent and identity, not just authorization scopes.
Agent Fabric Flex Gateway related policies
- OAuth2 OBO Credential Injection: Exchanges an incoming bearer token for a new token targeting an upstream service using the OAuth2 Token Exchange protocol.
- In-Task Authorization Code Policy: Handles secondary credentials for in-task authentication in A2A scenarios using the OAuth2 Authorization Code flow. Extracts OAuth2 tokens from message data and injects them into Authorization headers for upstream calls.
Use cases and a real-world example
- Enterprise integration and B2B gateways: Secure partner API calls while preserving originating user identity for audit and compliance.
- Microservices and zero-trust architecture: Decentralized identity propagation enables each service to evaluate who and why, not merely what.
- Risk-adaptive access controls: Trigger secondary authentication only for high-risk activities – without breaking seamless interactions.
Fintech industry use case
Agentic identity is built on the Token Exchange concept where a security token captures the user or agentic identity of both sides of the communication link. If the access requires user-specific sensitive information, then the identity of the user is also included in the signed security token on-behalf-of whom the resource access is required and authorized.
While all protocol handshakes are based on industry standards, they do not have to be implemented by every agent. They can configure all ingress and egress traffic to pass through Flex Gateway to enable governance and observability into their Agentic Network.
To simplify the scenario and diagram above, Flex Gateway is assumed to have been set up between all communication links between any two Agents and/or MCP servers.
- User-to-service (U2S) flow: A user (investor) wants to manage their stock portfolio. They log into the FinPort Application using Okta, which enables agentic workflows by exposing a chat interface to its users. They ask to view their stock portfolio. The Agent Broker leverages available Agents, MCP servers and LLMs to build an execution plan.
- Service on Behalf of (OBO) user flow: The Agent Broker (through egress Flex Gateway) exchanges user token with OBO (on-behalf-of) token and leverages the Portfolio Agent to access this user-specific information, which requires an OBO token. All OAuth2 token exchange protocol handshakes are handled by Egress Flex Gateway.
- Service to Service (S2S) flow: The user wants to review the stock market trends and this is user independent data. This requires the Broker to acquire a service to service (S2S) token and authenticate as itself to the Market Data Agent. This enables the Broker to show the stock value predictions and trends and enable the user to make transaction decisions.
- In-task authentication using secondary credentials: The user decides to transfer money, which is a privileged operation. This flow requires additional authorization from a second identity provider (the user’s bank). The A2A protocol supports in-task authentication, and it’s leveraged for the user to allow the money transfer, by authorizing the transaction through another IDP.
How to get started
To implement identity propagation with OAuth 2.0 and OIDC, do the following:
- Ensure that your Identity Providers are OAuth2/OIDC compliant: Many standard IDPs support industry standard protocols.
- Ensure line of sight connectivity to MuleSoft Agent Fabric infrastructure: Enterprises may have segmented agent networks across various subnets with varying degrees of access to the Internet and/or the Corporate Intra-Net. Ensure network connectivity between agents, gateways and identity providers.
- Configure your authorization server to support OIDC identity tokens with custom claims and OAuth 2.0 OBO token exchange
- Ensure services validate JWTsenforce claim checks, and support token exchange flows. This can be handled automatically by Flex Gateway using relevant governance policies.
- Optionally define policies for the following: Secondary authentication triggers, claim mapping and trust boundaries, and token lifetime and refresh rules.
Next steps
Identity and context authentication propagation via Trusted Agent Identity is a foundational capability for modern distributed platforms – particularly for agentic networks where machine and human intents interleave. To learn more, read about MuleSoft Agent Fabric.