An employee asks an internal AI agent to retrieve customer information and add the result to a ticket. The first API has authenticated the employee. But the agent must now cross two more system boundaries: one into the customer database and another into the ticketing system.

What identity should each system see?

Using a shared service account gives the downstream services only a generic answer: an agent performed the action. Forwarding the employee’s original token is not safer; that credential may have been issued for the first API, not for either downstream service. A valid signature does not make a token valid for every recipient.

The safer design is to treat each boundary as a new identity handoff. At every hop, the system must be able to establish four things: which user is represented, which agent is executing the request, which API may receive the token, and which actions that token permits.

Preserve both identities instead of choosing one

On-behalf-of, commonly shortened to OBO, describes an intermediary performing an action for a user. Rather than forwarding the incoming credential unchanged, the intermediary asks the authorization server to exchange it for a new token intended for the next API. The resulting permissions should be no broader than the intersection of the user’s original authorization and the permissions allowed by system policy.

This exchange does not eliminate the agent’s own identity. In implementations that require client authentication, the agent uses its service identity at the token endpoint, while delegation data preserves the identity of the user it represents. RFC 8693 calls these roles the subject and the actor: the subject is the principal represented by the operation, and the actor is the party performing or forwarding it.

An authorization system may or may not express the actor through an act claim. Regardless of token format, the audit trail should make both roles recoverable. If the agent has no distinct service identity yet, begin with Why Does an AI Agent in an ERP System Need Its Own Identity?. Identifying the agent must not erase the user context.

AWS illustrated this pattern in July 2026 through a multi-tenant Amazon Bedrock AgentCore Gateway implementation. Its example exchanges tokens on behalf of users and binds each token to an audience—the API permitted to receive it. The implementation is tied to that product, but the boundary it addresses appears in any agent workflow that calls multiple systems.

Trace one token handoff in five steps

A diagram that says only “user → agent → API” hides the decisions that determine whether delegation is safe. Expand every token receipt and exchange, and apply these five checks at each hop:

  1. Validate the intended recipient of the incoming token. Check its issuer, expiration time, and audience at the agent’s entry API. Reject a token whose audience names a different service, even if its signature is valid. Membership in the same internal environment is not sufficient reason to accept it.

  2. Keep the subject and actor distinct. Record both the user being represented and the agent making the downstream request. A log that contains only a shared service account cannot demonstrate a traceable delegation relationship.

  3. Identify exactly one downstream resource. In the exchange request, name the next API as the resource or audience. Use a concrete target such as the ticketing API, not a broad label such as “internal services.” When the new token arrives, confirm that its audience matches that API.

  4. Reduce the scope to the current action. Permission to read customer data must not silently include permission to delete customers or export the database. The issued scope must fit within all three limits: the user’s original authorization, the agent’s approved capabilities, and the downstream service’s policy.

  5. Retain evidence for approvals and rejections. Record the exchange time, subject, actor, target audience, requested scope, issued scope, and rejection reason—but never log the complete token. Those fields should let the team determine who authorized an action, which agent executed it, which service accepted it, and why it was allowed.

Run the exchange and audience check again whenever the agent moves to another downstream system. A token issued for the customer data API must not be reused for the ticketing API. Microsoft’s OBO documentation applies the same principle: an intermediary obtains a new token for the downstream web API rather than treating the previous credential as a general-purpose token.

The model’s prompt is not an authorization boundary. Four Authorization Questions for AI Agents: Identity, Permission, Reason, Consequence covers the checks that the backend must enforce rather than allowing the agent to decide them.

Advertisement

Choose the path that matches the kind of work

The correct identity flow depends first on whether the task genuinely represents a user, and then on whether every system in the chain can validate that delegation.

  • A specific user is represented, and both the authorization system and downstream API support delegation: Exchange the token, preserve the subject and actor, and issue a separate audience-bound token for each downstream service.
  • No user is represented—for example, a scheduled job organizing public data: Use the agent’s workload identity and restrict it to the permissions required by that background job. Do not invent a user identity merely to use OBO.
  • A user is represented, but the downstream system cannot support OBO or validate the delegation relationship: Do not forward the incoming token. End the delegated flow at the intermediary, expose a narrower operation through a controlled backend, or require a person to confirm the action in the downstream system.
  • The target audience cannot be proven, or the scope exceeds what the current action needs: Reject the exchange or API request. The agent must not infer either value for itself.

A named data or system owner must review the subject, actor, target API, requested scope, expected impact, and rollback plan before a high-impact write is allowed to proceed. Automatic execution is limited to reversible, low-impact reads covered by an approved policy.

A chain is not ready for automatic high-impact actions if any hop hides the user behind a shared account or asks an API to accept a token issued for another recipient.

Test the design with one real call chain

Select an agent that already works across multiple systems, but map only its most common path. Write one line for every hop in this format:

user subject → executing actor → token issuer → target audience/resource → issued scope → rejection conditions

Now inspect the map for two failures. Does any hop identify only a shared service account? Do two services with different audiences accept the same token? If either answer is yes, narrow and correct that handoff before adding more automation.

AI handoff card

Act as a security operations analyst. Paste the full call chain into `INPUT_CALL_CHAIN`, then produce one compact token-handoff record per hop that supports a delegation-risk decision.

Use this field schema: `incoming_token` = issuer, audience, expiry; `identity` = subject, actor; `exchange` = target resource or audience, endpoint, rejection code and reason; `permitted_scope` = permitted scope and explicit authorization boundaries; `propagation` = shared service account trace and original-token forwarding trace; `risk_state` = Confirmed, To confirm, or Blocked.

Do not infer missing permissions or values. Mark every unknown as `To confirm`. Output the per-hop records only.

INPUT_CALL_CHAIN:

Everyday four-panel comic

An analyst faces many doors and keys across four scenes, then chooses one small key to open only the intended room

  1. An analyst receives a folder and a key.
  2. More doors and keys appear, expanding his choices.
  3. He pauses at a staffed counter and selects one smaller, specific key.
  4. He opens one chosen room, leaving the other doors and keys for later.
Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References