What happens when the agent calls a tool that calls an API?

One more hop

So far the agent has called the calendar API directly. Often something sits in between. Alice asks the agent to find a time for a meeting. The agent calls a scheduling tool, which in MCP would be a server. The tool needs to see Alice’s calendar, so it calls the calendar API.

The agent has a token for the tool: Alice approved it, and its audience is the tool. Now the tool has to call the calendar API. What does it send?

There are three things it could reach for. Before you look, guess which of them lets the calendar API answer all three of its questions.

{
  "sub": "alice",
  "client_id": "calendar-assistant",
  "aud": "https://scheduler.example",
  "scope": "meetings.schedule"
}

GET /events?day=tomorrow HTTP/1.1
Host: calendar.example
X-API-Key: sk_scheduler_41c0…
X-User: alice

{
  "sub": "alice",
  "aud": "https://calendar.example",
  "scope": "calendar.read",
  "act": { "sub": "scheduling-tool" }
}

Why forwarding is the dangerous one

Forwarding feels harmless. It is the same user and the same request, and the token is right there. The harm is in what it requires of the calendar API: accepting a token that was addressed to someone else.

An API that does that can be used by any service holding any token from the same authorization server. A tool you connected for one purpose can quietly use your token for another. And an API that accepts tokens that were not addressed to it can be steered, by any caller holding one, into acting with authority that caller should not have. Security people call a service misused that way a confused deputy.

The audience check from the token lesson is the defense, and it only works if no service ever asks another to skip it.

What to do instead

The tool asks for a token of its own for the next hop. It takes the token it was handed back to the authorization server and asks for a new one, addressed to the calendar API. The authorization server decides whether this tool may act for Alice there, and if so issues it. That trade is a token exchange, and this is what then arrives at the calendar API:

{
  "sub": "alice",
  "aud": "https://calendar.example",
  "scope": "calendar.read",
  "act": { "sub": "scheduling-tool" }
}

Still about Alice, now addressed to the calendar API, and no wider than this step needs. So the rule is short: exchange, never forward.

Two ways to write “for Alice”

A token made for the next hop can be written two ways.

• It can name only Alice. The calendar API then believes Alice is calling in person, and its logs will say so. This is impersonation.
• It can name Alice, and separately the software acting for her. This is delegation, and the second name is called the actor. It is the act line in the token above.

Delegation is the one to want. The API can apply Alice’s permissions and the tool’s limits together, block one misbehaving tool without locking Alice out, and say afterward what did what. With impersonation the log shows Alice doing things at 3 a.m. that Alice never did.

One caution. Whether the new token carries an actor depends on the authorization server that issues it, and whether anything is done with it depends on the API. Check what your authorization server actually issues, and what your API actually reads, before you rely on it.

Where you will meet this

• An MCP server that calls another API. It must not pass along the token the client sent it. It gets a token of its own for the API behind it, by exchange or by asking the user to connect that account directly.
• An agent that hands work to another agent. The same question one level up: what does the second agent receive, and what can the service behind it tell?
• A request that crosses into another company. Their authorization server does not know your users, so there are two trades: one at home for a short-lived grant, and one there for a token.
• A request passed between services inside your own infrastructure. One variant makes a single exchange at the edge, for a short-lived token built to travel from service to service. What is never forwarded is a token addressed to someone else.