Imagine an agent reads a customer's case from Service A and then calls Service B to update a reservation. It forwards the bearer token it received for A. The signature and expiration check out, and the user is allowed to edit that reservation. B should still reject that token if it was issued for A.

An access token is not a general statement that “this user is allowed everywhere.” The audience tells a resource server which service the token was meant for. A token for A should not be replayable at B. OAuth's resource indicator specification explains why restricting tokens to intended resources matters. The JWT access-token profile requires the resource server to validate that its own identifier appears in the audience.

The agent needs a credential for B, issued through an authorized delegation or token exchange flow. It should carry the relevant user or subject, the acting service where the scheme supports it, B as the target, and permissions narrow enough for the requested operation. RFC 8693 describes token exchange and the distinction between the subject and the actor. Whether a particular identity provider issues such a token is an implementation and policy decision.

Even that token does not by itself approve every action. B checks the case or reservation boundary, operation, tenant, current policy and any required human approval. The agent cannot turn read access on A into write access on B by phrasing the tool call differently. Log the actor and subject separately so an audit can say who requested the change and which service performed it.

If the interviewer asks, “Why not give the agent a service account that can call both?”, I would ask whose authorization B is supposed to enforce. A broad service account hides the end user's scope and makes a confused-deputy failure easy. Sometimes a service credential is appropriate for a background job, but then the job needs its own explicit grant and scoped authorization model. A valid signature is only the start of the decision.