A salesperson asks an AI agent: “Look up this customer’s recent orders, then open a support ticket with the results.” To a person, that’s clear. To the systems behind it, a few key facts are missing: who authorized this, which agent is actually doing it, and how far it’s allowed to go.

To finish the job, the agent has to cross at least two systems: the customer database and the ticketing system. At each one it presents a token, a digital pass that proves “I’m allowed to do this.” Here teams tend to take one of two shortcuts: let the agent work under a shared service account, or pass the token the user got at sign-in unchanged all the way down. Both shortcuts make the process run, and both make it impossible to tell who authorized what when something goes wrong.

The steadier approach: every time the agent moves to the next system, it gets a new token meant only for that system, with only the permissions this job needs.

What’s wrong with each shortcut

With a shared service account, the user disappears. If every action runs under one agent account, the customer database only records “the agent looked up this record.” Which salesperson asked? Were they allowed to see this customer? The record doesn’t say. The agent account also usually has more permissions than any single user, which lets everyone see, through the agent, things they couldn’t see themselves.

With a token passed down the chain, the recipient is wrong. Every token states, when issued, which system it is meant for. That field is called the audience. The token a user gets at sign-in has the first system as its audience. If the agent hands it straight to the ticketing system, it’s walking in with a pass made out to someone else. A technical post AWS published in July 2026 points out that this can turn every downstream tool into an exploitable deputy, because the tokens they receive were never issued to them. Microsoft’s documentation for this kind of flow says in a warning box: don’t send tokens issued to a middle-tier service anywhere other than their intended audience.

A new key at every stop: exchanging on the user’s behalf

This “go to the next system on the user’s behalf” pattern is usually called on-behalf-of, or OBO. Its core move is an exchange: the agent takes the user’s token to the authorization server (the system that issues tokens) and asks for a new one. The new token is only for the specified next system, and its permissions can’t exceed what the user was originally allowed.

The new token has to remember two roles. RFC 8693, the internet standard that describes this exchange, separates them: the subject is the person being represented, here the salesperson, and the actor is the party actually doing the work, the agent. In the AWS post’s implementation, the token is exchanged before every downstream tool call, so the new token keeps the user’s identity, records the acting agent, is bound to a single receiving system, and carries only the permissions that system needs.

With this in place, the customer database’s record becomes: “The agent, on behalf of a specific salesperson, looked up this record with read-only access.” Each additional downstream system means another exchange. A token for the customer database can’t then be used to open a ticket.

Advertisement

Sort out the kind of work first

Not every agent job should use OBO. Before mapping the handoffs, decide which kind of work this is:

  • It really acts for a specific user, and both the authorization system and the downstream systems support exchange: use OBO, get a new token at each stop, and keep the subject and actor.
  • It doesn’t act for any user, such as a daily scheduled job that organizes public data: use the agent’s own identity, with permissions covering only that background task. Don’t invent a user just to fit OBO.
  • It acts for a user, but the downstream system doesn’t support exchange: don’t pass the original token along. Stop at the middle layer and have a narrower backend function do the work, or have a person confirm in the downstream system.
  • You can’t say which system the new token is for, or it asks for more permission than this action needs: refuse. These fields must not be left to the agent to guess.

A successful exchange doesn’t make the action right

A successful token exchange only means “this agent may represent this user at this system.” It doesn’t mean the action is right. Looking up an order can be approved automatically under rules agreed in advance, but high-impact writes such as deleting data, issuing refunds, or changing permissions still need a responsible person to confirm who authorized it, what it does, how big the impact is, and how to undo it, even after a successful exchange. Authorization checks also can’t live only in the agent’s prompt; the backend has to enforce them. See Before AI Support Can Change Accounts, Identity Must Come From the System, Not the Chat.

The exchange mechanism has something to protect as well. The AWS post warns that the agent credential used for exchanges is the most sensitive key in the whole chain; if it leaks, someone can request tokens for any user. Logs also shouldn’t store full tokens, only fields like subject, audience, and actor.

Map one path that’s actually running

Pick an agent that already works across systems and map only the path it takes most often. Write each stop in the same one-line format:

user represented → acting agent → token issuer → receiving system → allowed action → when it's refused

Then ask two questions. Is there a stop where only a shared account is visible? Is the same token accepted by two different systems? If either answer is yes, narrow that stop first before letting the agent do more. If the agent doesn’t have its own identity yet, start with An AI Agent in Your ERP Needs Its Own Identity So Logs Can Tell Whether a Person or AI Acted.

AI handoff card

I want to check whether identity is handed off clearly at every stop when an AI agent works across systems.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-agent-on-behalf-of-token-handoff-map/
Its view: when an agent calls several systems on a user's behalf, don't use a shared account and don't pass the same token down the chain. At every stop, get a new token meant only for that stop, with only the permissions this job needs, and keep both "who is represented" and "who is acting."

Ask me 3 questions first:
1. What is the path this agent takes most often: which systems in order, and what happens at each?
2. At each stop, what identity does the agent use: the user's token, a newly exchanged token, or a shared service account?
3. Does this path include any action that writes, deletes, pays, or changes permissions?

Based on my answers, give me:
- One line per stop: user represented / acting agent / receiving system / allowed action / refusal conditions, marking any field you can't confirm as "to confirm";
- The stops that use a shared account, or where the same token is accepted by different systems;
- A status for each stop: confirmed / to confirm / must block;
- Which high-impact actions still need a person's confirmation even after a successful exchange.
Don't guess my system settings. If information is missing, ask me first.
Advertisement

Share

Share this mini class

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

References