When working with engineering teams on multi-agent systems, the conversation usually starts with orchestration patterns and protocol choices. But there’s a more fundamental problem that catches teams off guard: who’s this agent actually acting as? If you can’t answer that question with certainty for every single agent action, you’re not building a production system – you’re building a security and audit nightmare.
The identity gap creates real risk
In traditional systems, identity is straightforward: users log in, systems authenticate, and permissions are checked. But when your agent calls three other agents, each invoking different services, that clarity disappears. Somewhere along the delegation chain, user context gets lost. And when identity disappears, your audit trail disappears with it. This identity gap creates four categories of risk:
- Imprecise security controls: Without user context, downstream systems can’t make fine-grained access decisions. Everything becomes binary: grant access or don’t, when what you need is “grant access to this user’s specific data and actions”
- Expanded risk profiles: Solving identity through over-privileged service accounts increases the potential blast radius in a breach. One compromised agent puts the entire infrastructure at risk
- Broken user experiences: Users hit unnecessary re-authentication barriers or can’t authenticate at all because the delegation chain broke somewhere upstream
- Audit blind spots: When agents act through service accounts, your logs show what happened but not who authorized it. This is a compliance showstopper in regulated industries
Every agent action must be traceable to a human identity. Not a service account. Not a generic AI user. An actual person who requested, authorized, or performed that action. The teams that architect this correctly from day one will move orders of magnitude faster than those who try to retrofit identity later.
The problem: User identity is lost by default
When an agent calls an MCP server or downstream API using client credentials, the request carries the agent’s service identity, not the end user’s. In agentic architectures that fan out across services, trust domains, and organizational borders, this means per-user authorization and audit trails disappear at the first hop. Without deliberate identity propagation, the typical workaround is over-privileged service accounts with blanket access, where every action looks identical in logs regardless of who initiated it.
The solution: Gateway-enforced identity propagation
The architectural shift we need is from ‘agent acts as user’ to ‘agent acts on behalf of user’. And that distinction matters. The pattern that works, and what we’ve been implementing at MuleSoft, is policy-based, gateway-managed identity propagation. Here’s the key principle: identity propagation is enforced at the gateway layer, not within agents or services.
The agents and MCP servers contain zero authentication logic and so they focus purely on business logic while the gateway layer enforces identity propagation. This is protocol-agnostic because the policies operate at the HTTP layer, they apply consistently whether the agent communicates via REST, MCP, gRPC, or webhooks.
The gateway intercepts outbound requests at every step in the call chain, exchanging the incoming user token with the Identity Provider for a new credential scoped specifically for the downstream service. We’re leveraging standard protocols like OAuth 2.1 and OIDC, and integrating with existing Identity Providers like Okta or Entra ID.
What this gives you:
- Every agent action carries both the agent identity, and the user identity it’s acting on behalf of
- Downstream services and MCP servers can make user-aware authorization decisions
- Full audit trails showing which user authorized which agent to do what
- Developers build agents in any language or framework without writing additional authentication logic
- Authentication when you need it (human in the loop) for sensitive transactions
3 architectural patterns that make this real
There are three distinct patterns for identity propagation across agentic architectures, each solving different trust boundary problems.
1. On-Behalf-Of (OBO): Single-identity provider
This pattern maintains end user identity across the entire workflow, even as requests traverse multiple agents and services within the same trust domain.
Technical implementation
MuleSoft Omni Gateway uses OAuth 2.0 Token Exchange (RFC 8693) to intercept outbound requests and acquire tokens scoped for each downstream service. The acquired token carries three distinct identities: the agent making the call, the specific downstream service it’s destined for, and the end user it’s acting on behalf of.
This gives every service a clear, auditable answer to “who’s calling, where’s this request going, and on whose behalf?”. This preserves user identity without granting the agent’s privileges to downstream services, enabling them to perform user-aware authorization. The Omni Gateway handles this token exchange transparently.
The pattern in action
A user asks an enterprise agent to show their portfolio. The agent queries downstream systems to pull financial holdings, equity positions, and asset details on the user’s behalf, where each system is located within the same trust domain. Rather than the agent presenting a shared service credential at each hop, the Omni Gateway silently exchanges the user’s token at every step so that the underlying backend returns only that user’s holdings. The user gets a complete, correctly scoped portfolio view without ever re-authenticating.
Use case
User-specific data access within the same trust domain. No user interaction required (beyond the initial authentication with the app) since the underlying token exchanges are transparent.
2. In-Task Authorization: Multiple identity providers
OBO flow works great when everything sits inside the same trust domain. But what happens when your agent needs to act on resources in a different organization’s system with its own identity provider and its own MFA requirement? Token exchange alone can’t cross that boundary. This is what the In-Task Authorization pattern handles: cross-domain workflows where agents need to access resources in a different trust domain, often involving operations that require additional user authorization.
Technical implementation
MuleSoft Omni Gateway uses A2A protocol’s In-Task Authorization mechanism, a challenge-response mechanism within the agent conversation. When the agent attempts an operation requiring secondary authentication, Omni Gateway returns TASK_STATE_AUTH_REQUIRED with authorization payload. This challenge includes all necessary details for the client to initiate an OAuth 2.0 flow with the corresponding identity provider.
The pattern in action
A user asks an agent to transfer funds from their bank account into their brokerage account. In order to initiate the transfer, the bank’s system requires explicit user authorization. The agent conversation pauses mid-task, prompts the user to authenticate directly with their bank, and only then completes the transfer. The approval is tied to that specific user, that specific action, at that specific moment.
Use case
Cross-domain operations in multi-identity-provider scenarios requiring inline user authorization.
3. On-Behalf-Of Flow with OIDC-CIBA
In-Task Authorization flow works great when the user is actively in the conversation and can step through an OAuth flow inline. But what happens when you want explicit user approval for a high-risk action without bringing in a login redirect into the agent’s conversation experience. The In-Task Authorization flow can’t address that need. This is what Client-Initiated Backchannel Authentication (CIBA) handles where the agent requests authorization out-of-band, letting the user approve on their registered device, and resume the conversation seamlessly once approval comes through.
Technical implementation
Your agent pauses and sends an auth request to the user’s registered device (eg a push notification). Once approved on their phone, the Omni Gateway injects the authorized grant and the agent completes the transaction. You don’t build custom polling loops or manage device registration since the agent code simply awaits an authorization response while the Omni Gateway handles the backchannel orchestration.
The pattern in action
A user instructs an agent to bulk sell their positions and reinvest in index funds. The agent orchestrates across multiple downstream services. Most calls flow through standard OBO, but when one specific position crosses the $10K threshold, the Omni Gateway pauses that call, sends a push notification to the user’s phone with a binding message (eg “Approve sale of XYZ holding?”) to approve it, and resumes once the user taps approve.
Use case
Long-running autonomous workflows where explicit user approval is required at specific decision points, without interrupting or restarting the overall agent flow.
Architecting agent patterns
Real agent workflows rarely fit into one pattern. A portfolio assistant might use OBO to retrieve a user’s assets from internal services, In-Task Authorization to call an external bank’s system, and CIBA for high-value trade approvals – all in one conversation. Because identity propagation is handled by MuleSoft’s Omni Gateway, agents don’t need to know which pattern to use at each conversation step.
Omni Gateway selects the right one based on the downstream service’s requirement while the agent’s logic stays the same. This is what makes the implementation practical. You’re not choosing a single pattern at design time – you’re enabling all three and letting the policy decide.
| If you need to… | Use this pattern |
|---|---|
| Let an agent fetch a user’s data across internal services without re-prompting | OBO |
| Let an agent perform an action that requires consent from a different Identity provider | In-Task Authorization |
| Get explicit user approval for a high-risk action without changing the agent conversation experience | CIBA |
| Get user approval on a device different from where the agent is running | CIBA |
| Compose multiple patterns in one workflow (read via OBO, approve high-value writes via CIBA) | All three, layered |
When each pattern applies:
| OBO | In-Task Authorization | CIBA | |
|---|---|---|---|
| Trust domain | Seed | Cross domain | Seed |
| User interaction required? | No (transparent) | Yes (inline) | Yes (out of band) |
| Best for | Routine data access on user’s behalf | Cross-org operations need explicit consent | High-risk actions needing approval without altering the conversation flow |
| User experience | Seamless, invisible | Inline OAuth challenge | Push notification, tap to approve |
Further reading
If you want to dig deeper into the technical implementation, learn more with Trusted Agent Identity: Identity Propagation in MuleSoft Agent Fabric; it goes deep on how identity propagates through agentic architectures, with detailed OAuth 2.0/OIDC flow diagrams. Take the next step towards a fully auditable agent architecture, explore Trusted Agent Identity and MuleSoft Agent Fabric.
