Scope Integrity, Proof-of-Possession, and Enforceable Token Exchange for Agentic AI Systems

Abstract

An agent identity model is the design that defines how a system proves which agent is acting, which user the agent is acting for, what authority the agent has, and how that authority is preserved across downstream calls.

In agentic AI systems, delegation solves one major identity problem: it preserves the original human user context across agent-to-agent chains. Delegation means that an agent acts on behalf of a user while the token still preserves both identities: the original user and the acting agent.

A delegated token can carry the original user in the sub claim and the acting agent chain in the act claim. But delegation alone is not enough.

A production-ready agent identity model must also prevent privilege expansion, ensure tokens are used only by the agents they were issued to, and enforce clear token exchange policy. The core principle is:

Delegation is not enough. Production-grade agent identity also needs scope integrity, proof-of-possession, and enforceable token exchange policy.

1. Why Delegation Still Needs Enforcement

In an agentic system, a user may interact with one agent, while that agent delegates work to other agents or services.

For example:

User -> Agent 1 -> Agent 2 -> Agent 3 -> Resource Server

A delegated token can preserve:

sub = original user

act = Agent 3
  act = Agent 2
    act = Agent 1

This makes the request path inspectable. However, it does not automatically answer three production questions:

1. Did each downstream agent receive only the permissions it needed?

2. Is the token being used by the agent it was issued to?

3. Is token exchange limited to valid agent-to-agent paths?

Without enforcement, delegation can still allow scope amplification, token replay, and overly broad exchange permissions.

2. Scope Integrity Across Agent Chains

Delegation carries identity context, but it does not automatically guarantee safe scopes.

Safe scopes are the permissions a downstream agent is allowed to receive because they are present in the upstream token and are necessary for that downstream agent’s specific task. A safe scope is never broader than the scope already granted earlier in the chain.

The rule should be:

Each hop in a delegation chain can only carry equal or lesser scope than the token it received.

Agent 2 cannot request scopes absent from Agent 1’s token. Agent 3 cannot request scopes absent from Agent 2’s token. Scope can narrow through the chain, but it must not expand.

A weak model looks like this:

Agent 1 token: read:data
Agent 2 requests: read:data write:data

If the authorisation server accepts this exchange, Agent 2 has gained authority that was not present in the upstream token.

A safer model requires explicit downscoping:

Subject token scope: read:data write:request notify:user
Requested downstream scope: read:data
Result: allowed

But this should fail:

Subject token scope: read:data
Requested downstream scope: read:data write:data
Result: rejected

RFC 8693 OAuth 2.0 Token Exchange defines a mechanism for exchanging one token for another token that represents a delegated or impersonated identity.

RFC 8693 permits a scope parameter in the exchange request. The requesting agent can declare the scopes needed for the downstream call, and the authorisation server should enforce that the requested scopes are a subset of the subject token’s scopes.

A scope escalation attempt should be treated as a security signal, not just a routine failure.

3. Why Bearer Tokens Are Risky in Agent Chains

A bearer token model is a token model where possession of the token is enough to use it. Whoever holds the bearer token can present it to access a resource, unless additional constraints are enforced.

Delegation and scope integrity answer who is acting and what they may do. They do not prove that the token is being used by the intended agent.

If a bearer token is intercepted at any point in an agent-to-agent chain, another actor may be able to replay it.

Agent chains increase this risk because every agent-to-agent call is another possible interception point. Agents may also run across different environments or infrastructure boundaries.

Audience binding means a token is issued for a specific intended recipient or resource audience. A resource server should validate the audience claim to ensure the token was meant for it.

Audience binding helps, but it does not fully solve token replay if a compromised agent intercepts a token before it is used by the intended downstream agent.

For high-assurance agentic systems, tokens should be sender-constrained.

4. DPoP and Proof-of-Possession

DPoP, or Demonstrating Proof of Possession, binds an access token to a key pair held by a specific agent.

The flow is:

1. The agent generates an asymmetric key pair.

2. The agent includes the public key in the token request.

3. The authorisation server binds the issued token to that key.

4. On each request, the agent generates a signed DPoP proof.

5. The resource server validates the proof against the key bound to the token.

The DPoP proof is a signed JWT containing request-specific data such as the HTTP method, request URI, and timestamp.

This changes the security property of the token. A token issued to Agent 2 cannot be used by Agent 3 unless Agent 3 can generate a valid proof using Agent 2’s private key.

In token exchange flows, each exchanged token should be bound to the key of the requesting agent, not the key of the agent whose token is being exchanged. That ensures each hop receives a token only it can use.

5. Per-Agent Key Management

DPoP makes key management part of the agent runtime.

Each agent needs to:

• Generate and hold its own asymmetric key pair

• Rotate keys on a defined schedule

• Store private keys appropriately for the deployment risk profile

• Generate fresh DPoP proofs per request

• Use correct jti and iat values to prevent replay

Private key storage may involve an HSM, cloud KMS, or secrets manager, depending on the deployment.

This should be designed from the beginning. Adding DPoP later requires changes to every agent’s HTTP client layer, every resource server’s token validation path, and the token exchange flow.

6. Keycloak Token Exchange Controls

Keycloak provides building blocks for token exchange, but production safety depends on how it is configured.

Token exchange is enabled at the realm level and controlled through client-level permissions. Exchange between arbitrary clients should not be broadly allowed.

The permission model should match the intended call topology:

Agent 2 may exchange tokens issued to Agent 1.
Agent 3 may exchange tokens issued to Agent 2.

A broad model such as this weakens the design:

Any agent may exchange tokens issued to any other agent.

Token exchange permissions should be managed through configuration, not ad hoc console changes, so the delegation model remains reviewable and less prone to drift.

7. act Claim Handling

When Keycloak performs token exchange using delegation rather than impersonation, it includes the act claim, which identifies the current acting agent and can preserve the chain of upstream agents involved in the request, in exchanged tokens. The claim is present in the JWT payload and returned by introspection.

Resource servers that need to make decisions based on the full delegation chain must explicitly read and interpret the act claim.

This is important because many OAuth2 client libraries do not automatically interpret nested act claims as an authorisation chain. If downstream services only check token validity, issuer, audience, subject, and scope, they may miss the actor path that explains how the request arrived.

Delegation is useful only when resource servers consume the delegation context.

8. Policy Enforcement and Custom SPI

Keycloak supports scope constraints at the policy level, but strict scope integrity requires deliberate enforcement.

SPI, in this context, refers to a Keycloak extension mechanism that allows custom logic to be added to the platform. A custom Token Exchange validator SPI or custom event listener can intercept token exchange requests, validate scope intersection, reject exchanges that expand privilege, and emit structured events.

The enforcement rule is simple:

requested_scope must be a subset of subject_token_scope

This makes scope expansion technically impossible rather than merely discouraged by policy.

9. Session Lifetime and Downstream Token Expiry

Each exchanged token is a distinct token with its own lifetime. In an agent chain, downstream tokens should not outlive the upstream token that produced them.

A risky condition is:

Upstream token expired or revoked
Downstream token still valid

A safer model requires one of two controls:

1. Downstream token lifetime is no greater than the remaining lifetime of the subject token.

2. Downstream tokens are revoked when upstream tokens expire or are revoked.

This decision should be made before production. Development-friendly lifetime settings can otherwise become difficult-to-debug production behaviour.

10. Hard-to-Reverse Decisions

Several choices become expensive to change after deployment.

These decisions should be made before the agent architecture becomes complex.

11. Production Design Checklist

Conclusion

Delegation preserves the original user and the acting agent chain, but it does not by itself make agent identity production-ready.

A secure agentic identity model also needs:

• Scope downscoping across every hop

• Protection against scope amplification

• Sender-constrained tokens using DPoP

• Per-agent key management

• Explicit token exchange permissions

• Resource server support for the act claim

• Strong policy or SPI-based enforcement

• Downstream token lifetimes bounded by upstream authority

The final lesson is clear:

Delegation is not enough. Agent identity becomes production-ready only when delegation is paired with scope integrity, proof-of-possession, and enforceable token exchange policy.

Writer’s Overview

Ajit Gupta – Co-Founder & CEO, Midships  

Ajit leads Midships Group’s transition from a specialist identity consultancy to a portfolio of autonomous, AI-native business units. He focuses on long-term business relevance through platform thinking, customer outcomes, and scalable operating models.

Short bio: Ajit is a strategic founder with deep expertise in IAM, platform delivery, and AI services, driving Midships’ expansion across Asia, the Middle East, and beyond.

📧 ajit@midships.io  

🔗 LinkedIn: Ajit Gupta