The trust assumption that a valid token is reaching the intended service breaks first. If local routing can be altered, token validity no longer proves that the call path is trustworthy or that the agent is talking to the right endpoint. Teams need to treat local configuration integrity as part of the authorisation boundary, not as a separate operations issue.
Where the trust boundary actually fails
When local MCP routing can be rewritten by code on a developer workstation, the problem is not just routing reliability. The security boundary shifts to the local host, because the workstation can redirect a legitimate client toward a different MCP endpoint without changing the token itself. That means authentication evidence can still look valid while the target service is no longer the one the user or agent intended.
This is why MCP guidance treats local configuration integrity as part of the authorisation path, not as a separate operational detail. If the client can be pointed at the wrong server, the security question becomes whether the endpoint being reached is the intended one, whether the audience and issuer assumptions still hold, and whether token passthrough or local config changes have quietly broken the trust chain. MCP Security Guide and the Model Context Protocol: Authorization specification both reflect that routing and authorization cannot be separated cleanly once local endpoint control is mutable.
Why a valid token no longer proves the right call path
The key break is in the assumption that possession of a valid token implies a trustworthy request path. A token can still be perfectly valid while the workstation rewrites the route, proxies the call, or swaps the server behind the client. In that case, the token authenticates something, but not necessarily the endpoint or workflow the operator expected.
That is especially important for developer laptops and local tooling, where configuration files, environment variables, launch scripts, and helper processes can all influence where requests go. In a routed MCP setup, the client may believe it is talking to a trusted internal service, while the effective destination is a different local or remote process with different privileges, logging, or data handling. The practical control question becomes endpoint binding and local integrity, not token validity alone.
For practitioners, the useful mental model is that routing is part of authorization context when the client is making a privileged decision on behalf of a user or agent. If local code can alter that context, then the token can be correct and the overall decision can still be unsafe. OWASP API Security Top 10 is relevant here because broken authorization often starts with the wrong object, server, or function being reached, even when authentication appears intact.
What changes in practice for agent and MCP deployments
Teams should separate three checks that often get blurred together: who the client is, what token it presents, and what endpoint it actually reaches. If any local process can rewrite routing, then endpoint selection must be treated as a security-sensitive control plane decision. That means configuration provenance, signed or centrally managed settings, and explicit endpoint allowlists matter more than convenience-driven local overrides.
In agentic environments, this also changes how you think about delegated access. The agent may be acting within a legitimate workflow, but the local workstation becomes part of the trust boundary for where that delegation is delivered. The more the agent can invoke tools or forward credentials automatically, the more important it is to verify that the selected server, the expected audience, and the intended tool surface still match. AI Agent Identity Security: The 2026 Deployment Guide and The agentic AI applications guide are useful navigation points for that broader delegation problem.
Risk and Threat Considerations
Local routing rewrite creates a classic trust-confusion condition: the requester remains legitimate, but the destination is no longer assured. That exposes token replay, endpoint substitution, and silent redirection risks, especially when a workstation compromise or malicious local code can alter config before the call is made.
Failure mechanism: An attacker or hostile local process changes the MCP client’s routing so a valid token is presented to an unintended endpoint, or to an endpoint that can observe, relay, or misuse the request.
Impact: The system may authorize the wrong service, leak sensitive requests or responses, and create a false sense of safety because authentication still appears to have succeeded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token validity can be detached from the intended endpoint by local routing changes. |
| API5 — Broken Function Level Authorization | Routing rewrites can redirect a client to the wrong function or service path. | |
| Recommendation — Bind tokens to the intended audience and verify endpoint identity before accepting a request. Restrict each client to the intended function and server path, not just a valid token. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Mutable local routing expands the effective authority of workstation code and config. |
| CM-5 — Access Restrictions for Change | Local config rewrites are a change-control problem when they alter security-relevant routes. | |
| IA-5 — Authenticator Management | The issue depends on how tokens are issued, scoped, and protected during use. | |
| Recommendation — Limit local tools and processes to the minimum routing and credential scope they need. Restrict who can modify MCP routing and require approval for security-relevant config changes. Scope and rotate authenticators so a valid token cannot be reused against the wrong destination. | ||
Practitioner Guidance
What to verify: Check whether the MCP client binds tokens to a specific audience and whether the destination server is enforced, not just configured. If a workstation can edit routing silently, treat that as an authorization-control weakness rather than a support issue.
Decision rule: If local routing is mutable, prefer centrally managed configuration, endpoint allowlists, and explicit server identity checks before allowing token passthrough or automated tool execution. Local overrides should be exception-only and observable.
Common mistake: Teams often harden the token format but ignore the local path that delivers it. That leaves the strongest credential in the stack attached to the weakest trust boundary.
Practitioner takeaway: In routed MCP flows, the security decision is not only whether the token is valid, but whether the workstation can still prove the token reached the intended service.
Related resources from NHI Mgmt Group
- What breaks when local MCP configuration can be rewritten by untrusted code?
- What breaks when Claude Code hooks are left as local developer settings?
- What breaks when MCP access is left to local developer configuration?
- How should security teams reduce local file exposure when running MCP servers on developer machines?