Trusted Agent Identity: Identity Propagation in MuleSoft Agent Fabric

This technical guidance details the implementation of secure identity propagation within MuleSoft Flex Gateway. It outlines the use of two specific OAuth 2.0 patterns:

OAuth 2.0 Token Exchange and In-Task Authorization Code patterns

These patterns enable:

• Gateway-enforced security: Authentication policies applied at the MuleSoft Flex Gateway layer without backend code changes
• User context preservation: Original user identity Subject (sub) claim maintained across service boundaries
• Least privilege access: Service-specific tokens with minimal required scopes
• Step-up authentication: Multi-factor authentication (MFA) enforcement for high-risk operations

The challenge: Identity in multi-service architectures

Modern enterprise architectures including AI agent networks, MCP tools, microservices, and API ecosystems require secure identity propagation across service boundaries. Key challenges include:

• Identity propagation: User identity must flow through multi-hop service calls (e.g. Frontend → Agent A → Agent B → API) while maintaining audit trails 
• Service isolation: Each service must receive tokens scoped to its specific permissions. A token for Service A should not grant access to Service B 
• Dynamic authentication strength: Low-risk operations may require basic authentication, while high-risk operations require MFA
• Multi-IdP scenarios: Enterprise B2B and regulated industries often require authentication from multiple identity providers, such as corporate SSO for initial access, and banking IdP for transactions 
• Zero-trust architecture: Every service boundary requires independent token validation with no implicit trust 
• Regulatory compliance: Financial services, healthcare, and privacy regulations mandate specific authentication methods and audit trails

Where traditional approaches fail 

Let’s take a look at reasons traditional approaches fail. 

Passing user tokens directly (Security risk) 

• Violates least privilege: Token has audience (aud) claim containing all services, not just the one being called
• No service isolation: Compromised Agent B can use token to access Agent C without additional authorization
• Audit trail confusion: Cannot distinguish which service made which call; all appear to come from user
• Token lifetime risk: Long-lived token increases exposure window if compromised
• Privilege escalation: Any service with the token can access any other service in the audience list

Service accounts only (No user context) 

• Lost user context: Cannot determine which user initiated the request; sub (subject) claim is service account, not user
• No audit trail: All requests appear to come from service account, violating regulatory requirements
• Authorization failures: Cannot enforce user-specific permissions 
• Compliance violations: GDPR, HIPAA, SOX require user identity in audit logs
• Security risk: Service account compromise affects all users

Frontend-managed token exchange 

• Increased attack surface: Frontend must manage multiple tokens in browser memory/storage
• Complexity: Frontend must know entire service topology and request tokens for each
• Latency: Multiple token requests to IdP before making actual API calls
• Security risk: Tokens exposed in browser memory, vulnerable to XSS attacks
• Scalability: Frontend logic changes every time service topology changes

Solutions for these approaches 

MuleSoft Flex Gateway provides two policy-based authentication patterns: OAuth 2.0 Token Exchange (OBO) and In-Task Authorization Code for A2A Protocol-Based Agents. 

Pattern 1: OAuth 2.0 Token Exchange (OBO) 

Pattern 2: In-Task Authorization Code for A2A Protocol-Based Agents 

Architecture overview

Flex Gateway’s outbound authentication policies are the optimal interception point for token exchange and step-up authentication because they:

• Intercept at the right layer: Policies execute after inbound validation but before backend calls, enabling transparent token transformation
• Have centralized security: Authentication logic enforced at gateway layer, not scattered across services
• Face zero backend changes: Services receive properly scoped tokens without code modifications

How outbound policies work

Request Flow:

• Client → ingress gateway: Client sends request with user token
• Inbound validation: Gateway validates user token (signature, expiration, audience)
• Broker processing: Agent broker receives validated request, determines which downstream services to call
• Outbound interception: Before calling downstream services, outbound policy intercepts the request
• Token transformation:
  • OAuth2 OBO Credential Injection Policy: Exchanges incoming bearer tokens using the OAuth 2.0 Token Exchange (RFC 8693) or Microsoft Entra ID On-Behalf-Of protocols
  • A2A In-Task Authorization Code Policy: Ensures secondary credentials are present for in-task authentication using OAuth 2.0 Authorization Code flow
• Backend call: Service receives properly scoped token with preserved user identity
• Response: Service response flows back through gateway to client

Token exchange between services

When services call other services (service-to-service communication), the outbound policy ensures proper token scoping:

User Token (aud: broker) 
  → Broker receives request
    → Calls Agent A
      → Outbound Policy: Exchange for Agent A token (aud: agent-a, sub: user-id)
    → Calls Agent B  
      → Outbound Policy: Exchange for Agent B token (aud: agent-b, sub: user-id)
    → Calls API
      → Outbound Policy: Exchange for API token (aud: api, sub: user-id)

Pattern 1: OAuth 2.0 Token Exchange (On-Behalf-Of) 

User token structure

The user token is issued by the Primary IdP to client: 

{
  "iss": "
  "sub": "user-123-unique-id",
  "azp": "web-application",
  "aud": ["service-a", "service-b"],
  "exp": 1705262400,
  "iat": 1705258800,
  "auth_time": 1705258800,
  "jti": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "acr": "1",
  "amr": ["pwd"],
  "session_state": "8f7e6d5c-4b3a-2918-7654-321098fedcba",
  "preferred_username": "john.doe",
  "email": "john.doe@example.com",
  "email_verified": true,
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "scope": "openid profile email",
  "sid": "8f7e6d5c-4b3a-2918-7654-321098fedcba",
  "typ": "Bearer"
}

Claim explanations

OBO Token 

The OBO Token is issued by Primary IdP for Service A: 

{
  "iss": "
  "sub": "user-123-unique-id",
  "azp": "service-a",
  "aud": ["service-a"],
  "exp": 1705259700,
  "iat": 1705258800,
  "auth_time": 1705258800,
  "jti": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
  "acr": "1",
  "amr": ["pwd"],
  "scope": "agent:read openid"
}

Key claim transformations

Why this approach? 

Use cases

Pattern 2: In-task authentication with secondary IdP

In-Task Authorization Code enables step-up authentication with a secondary identity provider for A2A agentic scenarios. This policy is specifically designed for the A2A Protocol’s In-Task Authentication pattern, where agents pass secondary credentials in the request body using the A2A message format. 

When an agent attempts to access a protected resource, the gateway challenges the agent with a WWW-Authenticate challenge, prompting the agent to obtain a secondary token via Authorization Code Flow with PKCE. This policy is designed exclusively for A2A agentic workflows. 

The token extraction path (params.message.parts[].data.auth_credentials.accessToken) follows the A2A Protocol message structure. 

• A2A protocol compliance: Follows A2A In-Task Authentication specification for secondary credentials
• WWW-authenticate challenge: Returns auth challenge if no token found in request
• Token extraction: Extracts token from A2A message body at params.message.parts[].data.auth_credentials.accessToken
• Header injection: Sets Authorization header with Bearer format for upstream services
• Credential removal: Removes credentials from body to prevent token leakage

The policy trusts that the agent obtained a valid token through the OAuth2 flow and injects it into the Authorization header. Authentication Context Class Reference (ACR) and Authentication Methods Reference (AMR) enforcement is not performed by the policy itself. These claims should be validated by the upstream service or a separate inbound validation policy if required.

Token structure

Secondary token:

{
  "iss": "
  "sub": "user-secondary-id",
  "azp": "sensitive-service",
  "aud": ["sensitive-service"],
  "acr": "urn:okta:loa:2fa:any",
  "amr": ["pwd", "mfa", "otp"],
  "scope": "transfer:execute openid"
}

Claims:

• iss: Different issuer (IdP1 vs IdP2)
• sub: User identity from secondary IdP
• aud: Target service audience

While tokens may contain acr and amr claims indicating authentication strength, the In-Task policy does not validate these claims. If ACR/AMR enforcement is required, implement validation in the upstream service or use a separate inbound policy.

Use cases

Pattern selection guide 

Implementation guide 

Let’s go over the prerequisites you’ll need for implementation. 

Identity provider 

Supported identity providers 

MuleSoft Flex Gateway:

• Version 1.11.4 or higher
• CH2 Runtime
• Access to API Manager

Backend services:

• JWT validation capability
• JWKS endpoint access for signature verification
• TLS/HTTPS support
• Ability to extract and validate claims: sub, iss, aud, azp, exp, nbf

Identity Provider configuration

IdP configuration is provider-specific. Refer to your IdP’s documentation for detailed setup instructions: 

connections:
  agent-connection:
    kind: agent
    ref:
      name: my-agent
    spec:
      url: 
      authentication:
        kind: oauth2-obo
        flow: oauth2-token-exchange  # or microsoft-entra-obo
        tokenEndpoint: 
        clientId: clientId
        clientSecret: clientSecret
        targetType: audience
        targetValue: s/my-agent
        scope: Read  # Optional for RFC 8693, required for Entra OBO
        timeout: 50000  # Optional, default: 10000ms

connections:
  agent-connection:
    kind: agent
    ref:
      name: my-agent
    spec:
      url: 
      authentication:
        kind: in-task-authorization-code
        secondaryAuthProvider: providerName
        authorizationEndpoint: 
        tokenEndpoint: 
        scopes: Read
        redirectUri: 
        responseType: code
        tokenAudience: s/my-agent
        codeChallengeMethod: S256
        bodyEncoding: form
        challengeResponseStatusCode: 200  # Optional, default: 200
        tokenTimeout: 300  # Optional, default: 300s

brokers:
  my-broker:
    spec:
      links:
        - agent:
            ref:
              name: agent-without-auth
        - agent:
            ref:
              name: agent-with-auth
            headersToPropagate: [Authorization, custom-header]
        - agent:
            ref:
              name: another-agent
            headersToPropagate: [Authorization]

schemaVersion: 1.0.0
label: Employee Onboarding Network

brokers:
  employee-onboarding-broker:
    spec:
      links:
        - agent:
            ref:
              name: hr-agent
        - agent:
            ref:
              name: badging-agent
            headersToPropagate: [Authorization]
        - agent:
            ref:
              name: transfer-agent
            headersToPropagate: [Authorization]

agents:
  hr-agent:
    label: HR System Agent
  badging-agent:
    label: Badging Agent
  transfer-agent:
    label: Transfer Agent

connections:
  hr-agent-connection:
    kind: agent
    ref:
      name: hr-agent
    spec:
      url: 
  
  badging-agent-connection:
    kind: agent
    ref:
      name: badging-agent
    spec:
      url: 
      authentication:
        kind: oauth2-obo
        flow: oauth2-token-exchange
        tokenEndpoint: 
        clientId: badging-client
        clientSecret: badging-secret
        targetType: audience
        targetValue: s/badging
        scope: Read
        timeout: 50000
  
  transfer-agent-connection:
    kind: agent
    ref:
      name: transfer-agent
    spec:
      url: 
      authentication:
        kind: in-task-authorization-code
        secondaryAuthProvider: bankingIdP
        authorizationEndpoint: 
        tokenEndpoint: 
        scopes: transfer:execute
        redirectUri: 
        responseType: code
        tokenAudience: s/transfer
        codeChallengeMethod: S256
        bodyEncoding: form
        challengeResponseStatusCode: 200
        tokenTimeout: 300