How should teams govern MCP servers that act as token brokers?

How to Treat an MCP Server in the Trust Chain

An MCP server that brokers tokens should be governed as an active delegation layer, because it can reshape who gets access to what, and under which audience or exchange policy. The practical question is not whether the server is “just passing tokens”, but whether it can mint, exchange, forward, or scope credentials in ways that change the trust boundary for downstream services.

That means the server needs its own access model, its own token handling rules, and clear separation between the client relationship and each downstream resource relationship. When those boundaries are vague, the broker becomes a reusable path rather than a constrained integration point.

For teams using the Model Context Protocol: Authorization specification, the key design principle is audience binding, not token reuse. If the server is allowed to present a client token broadly, the server effectively inherits more authority than the original workflow intended.

What Good Governance Looks Like for Token-Brokering Servers

Good governance starts by defining the MCP server’s role precisely. If it performs token exchange or on-behalf-of flows, the exchange policy should state which upstream identities are allowed, which downstream services are eligible, and what claims or audiences must be present before a token can be accepted.

Separate trust relationships are important because a broker often sits between multiple principals with different risk profiles. A single permissive trust path can let one successful authentication be replayed across several services, which erodes attribution and makes later access reviews less meaningful.

Use the RFC 8693 token exchange model when you need explicit delegation boundaries, and combine it with RFC 8707 resource indicators so the resulting token is audience-restricted. That pairing keeps the broker from becoming a generic credential relay.

Where possible, strengthen the design with sender-constrained tokens using RFC 8705 mutual-TLS client authentication or RFC 9449 proof-of-possession. Those controls reduce the value of a stolen token because the token is no longer a simple bearer artifact.

Preventing the Broker from Becoming a Reusable Credential Path

The main failure mode is over-broad reusability. If the MCP server can exchange once and then reuse the resulting token across tools, tenants, or downstream APIs, it becomes a concentration point for privilege and abuse.

That risk is especially clear when teams treat the server as a passive proxy instead of an actor with its own authority. In practice, this is where MCP Security Guide is most useful: it frames token passthrough, local server credentials, gateways, and confused deputy conditions as governance problems, not just implementation details.

Keep the broker from accumulating standing power by scoping exchanges to the smallest useful audience, limiting token lifetime, and separating the server’s own credentials from the user or agent context it brokers. If the server needs broad downstream reach, that should be an explicit exception, not the default operating model.

For teams building agent workflows, the broader governance lesson is reinforced by the OWASP Agentic AI Top 10, especially the identity and privilege abuse pattern. The broker is part of the control surface, so its permissions and delegation rules must be reviewable like any other privileged integration.

Risk and Threat Considerations

An MCP token broker can create outsized exposure if it accepts tokens too broadly, forwards them without audience restriction, or reuses them across services. In that state, compromise of the broker, or misuse of its exchange logic, can expose multiple downstream systems through a single trust path.

Failure mechanism: The server receives or exchanges credentials without tight audience binding, then presents them to multiple resources or tools in a way that preserves access beyond the original intent.

Impact: Attackers can turn one foothold into repeated access, lose attribution clarity, and move laterally through every downstream service that trusts the broker.

Practitioner Guidance

What to verify: Confirm that every exchange flow has a documented upstream identity, a specific downstream audience, and an expiration policy that matches the sensitivity of the target service. If the server cannot explain why a token was valid for a given destination, the governance model is too loose.

Decision rule: If the server can present a token to more than one downstream resource, require explicit per-resource trust policy and review the blast radius as if the server itself were privileged infrastructure. If not, keep the broker narrow and purpose-built.

Practitioner takeaway: Govern the MCP server as a delegated authority with bounded reach, not as a convenience layer, because the difference between those two models is whether one integration remains observable and attributable or quietly becomes a reusable access path.

Related resources from NHI Mgmt Group

• How should security teams govern an AI gateway that brokers LLM traffic, MCP servers, and agents across enterprise environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?