Identity plane
The Consul Agentic Runtime Fabric identity plane carries delegated user authority between participating agents and tools. On-behalf-of (OBO) token exchange adds user context to Consul workload identity without making Consul the issuer of user access tokens.
Consul registers participating services as OAuth clients with the configured identity provider. Identity processors beside each service exchange and verify tokens at every hop. To learn how model, tool, and identity paths fit together, refer to the Consul Agentic Runtime Fabric architecture.
Introduction
Workload identity answers which service is making a connection. Delegated user identity answers which user the service represents and what authority applies at the destination. Both matter when an agent invokes another agent or tool for a user.
| Concern | Owner | What it establishes |
|---|---|---|
| Workload identity and mesh connectivity | Consul and the mesh data plane | Which workload connects and whether mesh policy permits that connection. |
| User and OBO access-token issuance | Customer identity and access management (IAM) system | Delegated authority issued under the customer's identity policy. |
| Outgoing delegation | Caller-side identity processor | Exchange user context for authority scoped to the next destination. |
| Incoming verification | Destination-side identity processor | Verify delegated authority before using its claims in destination policy. |
Workload trust and delegated authority have separate credentials and lifecycles. OAuth signing-key rotation does not replace workload certificate rotation, and a valid mesh connection does not make a user token valid.
Service participation and credentials
Participating services require an IAM integration with configured registration, audience mappings, verification material, and exchange permissions. The Consul-side integration coordinates service participation with the customer IAM.
The design authenticates token exchange with a signed OAuth client assertion rather than placing a long-lived client secret in application configuration. Encrypted credential delivery isolates signing material from cleartext Consul configuration and limits its use to the identity-processing runtime.
OAuth client signing keys are distinct from Consul workload TLS keys. Public verification material can be distributed for validation. Private signing material must not appear in catalog metadata, application configuration, logs, or plaintext proxy configuration.
Delegation between services
On an outgoing call, the identity processor resolves the next destination from trusted routing information. It maps that destination to the IAM audience and exchanges the user's token using the OAuth token exchange protocol defined in RFC 8693.
The processor verifies the returned token before projecting identity claims. It replaces untrusted caller-supplied identity headers with claims derived from verified authority. The request then travels over the permitted mesh connection.
At the destination, the inbound identity processor verifies the delegated token before destination policy consumes its claims. Inbound verification does not perform a new token exchange.
When that destination calls another participating service, its outbound processor performs an exchange for the next audience. Authority for one destination is not permission to reuse the same token at every subsequent hop.
Policy and failure behavior
Mesh policy, delegated-user policy, and tool policy remain separate checks. Verified user claims supply policy inputs. They do not grant unrestricted tool access. Human approval, when required, is an additional condition rather than a replacement for token verification.
For a protected delegated call, missing user context, an unresolved audience, a rejected exchange, or failed token verification must prevent forwarding under delegated authority. Failure must not silently downgrade the call to anonymous or workload-only access.
Cached tokens provide bounded reuse, not indefinite operation without IAM. Reuse must remain scoped to the user context, destination audience, credential generation, and token validity. Expired or invalid cached authority must not extend a user's access during an outage.
Dependencies and boundaries
- Customer IAM supplies token issuance, exchange policy, and verification information.
- Trusted service-to-audience mappings constrain each outgoing exchange.
- The identity runtime requires protected signing material and a supported key-rotation path.
- Destination policy consumes verified claims, never caller assertions treated as trusted headers.
The identity component owns registration, token exchange, verification, key management, and bounded cached-token behavior. It does not implement managed-model authentication. Calls without delegated user context are outside this OBO flow and require their own explicit authorization policy.