I would ask what resource the token was issued for. A token is not a general proof that “this is Alice.” It represents a grant to a particular audience under particular scopes and lifetime. If a host sends a token meant for the MCP server and that server forwards it to an accounting API, the downstream service is being asked to accept a credential that was not issued for it. If it accepts it anyway, that is a boundary failure, not evidence that forwarding is safe. The current MCP authorization specification requires a server to validate that an access token was issued specifically for that server as its intended audience. MCP's security guidance calls unvalidated token passthrough an anti-pattern.

I would separate the two hops. The host authenticates to the MCP server with a token for that server. The MCP server authenticates to the accounting API with a token issued for the accounting API, obtained through a supported delegated flow or token exchange with an authorization service. The user, tenant, approved purpose, and allowed invoice scope must survive the delegation, but the same bearer bytes need not. Each resource validates audience, issuer, expiry, client or workload identity where applicable, and permissions. The server should ask only for the downstream authority needed for read_invoice, not carry a broad employee session token that can call unrelated APIs.

There is also an application policy gate. Before invoking the tool, the agent platform decides whether this user may read this invoice in this tenant for this task. The MCP server then enforces its own boundary, and the accounting API enforces resource authorization over the invoice. A readOnlyHint or a description is useful for orchestration, but it is not a grant. This is a more specific issue than a tool catalog changing under a run: even a perfectly stable, honest server can leak authority if it forwards the wrong credential.

What if the accounting API already accepts the host's token? I would treat that as a migration problem. Inventory which clients rely on the loose audience check, issue correctly scoped tokens, update clients, then enforce audience validation with a staged rollout and telemetry for rejected calls. Do not solve an authorization migration by teaching the agent to forward every token it sees. If both services intentionally share a single resource audience, document and review that trust domain. The question is whether that shared audience is really the intended resource boundary. A shared domain can enlarge the blast radius of a compromised MCP server, so narrow it where the invoice data merits separation.

Suppose the MCP server is a proxy to a third-party accounting service and dynamically registered agent clients share its one upstream OAuth client ID. The design now needs per-client consent as well. MCP's security guidance describes a confused deputy flow in which an upstream consent cookie for the shared client can help an attacker obtain an authorization code for a different dynamically registered MCP client if the proxy skips its own per-client consent. Bind the request, client, redirect URI, user and consent at the proxy before starting upstream authorization. Token exchange by itself does not repair a broken consent flow.

Finally, test the uncomfortable case. Compromise the MCP server in a staging threat exercise. What can its token read, for how long, and can it reach another tenant or a write API? The answer determines whether this server is eligible for sensitive invoices at all. Keep an audit chain of host invocation, delegated token grant metadata, downstream request identity, and returned invoice reference without logging bearer tokens. “Internal” and “read-only” do not answer the audience or delegated-authority question.