Identity propagation and call chain audit - Identity as a Service

Why identity propagation matters

Compliance and security audits aim to answer a single question: Who did what, to which data, at what time, and through which path?

In Agent-based architectures, this question is far more complex. A single action like "check my leave balance" may involve one end user, one client application, one Agent, multiple downstream services, and several Token Exchange operations. Standard access logs cannot capture this chain of custody. Agent ID Guard preserves the original user identity across every Token Exchange hop, so each downstream API call remains traceable to an individual user regardless of how many intermediaries exist.

Use cases

Typical compliance requirements include:

Financial systems require that all data access be traceable to an individual user.
Security teams need to answer: "For any downstream API call, which frontend entry point, which Agent instance, and which upstream token triggered it?"
Regulatory frameworks require that unauthorized access be locatable and demonstrable within 90 days.

An access log showing "user = Alice" alone is insufficient — the Agent and client that acted on Alice's behalf must also be identified.

How identity propagation works

Agent ID Guard preserves and extends three key fields in the outbound access token issued during an RFC 8693 Token Exchange:

Field	Meaning	Use case
`sub`	The unique user identifier, carried over from the inbound access token.	Enables row-level authorization and auditing, preserving identity across service boundaries.
`client_id`	The client that currently holds the token — equal to the app ID of the Agent that initiated the Token Exchange.	Identifies the calling Agent to downstream services.
`_idaas_imp`	Upstream source information, including the upstream token's `jti` and `client_id`.	Enables reverse tracing: which inbound access token and which upstream client this outbound token was derived from.
`_idaas_exchange_count`	Exchange depth counter — increments by one for each Token Exchange hop.	Prevents infinite delegation; Agent ID Guard can reject requests that exceed the configured exchange depth limit.

Audit traceability

The outbound access token carries the token ID (jti) and client ID of the inbound access token it was derived from:

{
  "_idaas_imp": {
    "jti": "ATTU...(jti of the original inbound token)...",
    "client_id": "app_nfiiybmikzo2fnmabpectnxxxx"
  }
}

Combined with Agent ID Guard audit logs, these fields let you reconstruct the full call chain:

Call chain audit trace diagram

Agent ID Guard embeds upstream evidence directly into the downstream token at issuance. No custom logic is required in your Agent or downstream services.

Why agents cannot forge identity

An Agent cannot fabricate an arbitrary sub value, even when calling a downstream service directly. The following safeguards prevent impersonation:

Outbound access tokens are issued only through an RFC 8693 Token Exchange, which requires submitting a valid inbound access token as the subject token.
When Agent ID Guard issues an outbound access token, the sub claim is forced from the subject token's sub. Agent ID Guard signs the token with its own private key, and a valid authorization relationship must exist between the requested downstream service permissions and the sub.
The Agent's client secret or private key proves only "I am this Agent" — it cannot be used to sign user tokens directly.
Downstream services validate the issuer (iss), audience (aud), and signature using Agent ID Guard's JWKS public key. They trust the sub claim without needing to trust the Agent itself.

Verification

Run the following checks to verify that identity propagation and call chain audit work as expected:

Check	Expected result
Decode the outbound access token (for example, using jwt.io or a JWT CLI tool) and check the `sub` claim.	Matches the logged-in user.
Decode the outbound access token and check `_idaas_imp.client_id`.	Matches the app ID of the client that initiated the call.
Decode the outbound access token and check `_idaas_exchange_count`.	Typically `1` for a single-hop chain; increments with multi-level Agent forwarding.
Modify the Agent's code to forge a `sub` and attempt to issue an outbound access token.	Downstream JWKS signature validation fails and the request is rejected.
Revoke the inbound authorization from the client to the Agent, then attempt a Token Exchange.	The Token Exchange fails because the underlying inbound access token is no longer available.