The server loses the ability to distinguish a permitted request from a reused or forged one. Tool access becomes detached from the identity that should govern it, which weakens least privilege, revocation, and auditability. In practice, the assistant may still work, but the organisation no longer knows whether the caller was authorised to use the tool.
Why per-call identity verification is the control boundary for MCP tools
MCP tool access is only trustworthy when each call is checked against the identity and authority that should own it. If the server accepts a tool request without re-validating who is calling, it can no longer tell whether the request came from the intended actor or from a reused token, replayed session, or forged request. That breaks the security boundary the tool model depends on.
For MCP, the issue is not whether the assistant can invoke the tool, but whether the server can bind that invocation to the right caller and policy state. The Model Context Protocol authorization specification treats servers as resource servers with audience-bound tokens, which is the architectural response to exactly this class of trust failure.
When that check is missing, the server starts treating access as a generic transport event instead of an authorised act. That means a caller can drift away from its intended identity over time, especially when tokens are forwarded, cached, or reused across sessions. In practice, the tool may still answer, but the server has lost the ability to prove that the request was legitimate at the moment it was made.
What actually breaks in practice
The immediate breakage is in authorization continuity. A request may look valid once, then be replayed or repurposed later without the server re-checking whether the same identity still has the same right to act. That weakens least privilege because the server is no longer making a fresh access decision per call.
It also breaks revocation and offboarding logic. If access is only assumed from an earlier check, then removing a grant, rotating a credential, or ending a session may not stop subsequent tool use. The NHI Authentication Guide is useful here because it covers the authentication material that should be re-bound to service, workload, and agent calls rather than trusted indefinitely.
Auditability degrades too. Logs may show that a tool was used, but not that the caller was re-verified under the current policy context. That makes it harder to answer basic questions such as who invoked the tool, under what authority, and whether the access path was still valid when the action occurred.
Where the risk shows up in an MCP deployment
The risk is highest when an MCP server trusts a bearer token, a session artifact, or an upstream caller without checking whether the presented identity still matches the policy that granted tool access. That is especially dangerous when the tool can read data, change state, or trigger downstream actions on behalf of the caller.
The MCP Security Guide is the most direct internal reference for this trust boundary, because it covers token passthrough, confused deputy conditions, and the role of gateways in preventing the server from over-trusting the client path. The AI Agent Identity Security deployment guide adds the lifecycle angle: agent identity should be short-lived, scoped, and revalidated so tool authority does not persist longer than the task itself.
At scale, this becomes a blast-radius problem. One weakly checked call path can let the wrong identity reuse a tool privilege across many prompts, sessions, or environments, which is why MCP controls need to be designed around per-request trust rather than around a one-time login event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address 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 Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Per-call identity checks prevent agent/tool calls from being reused under the wrong authority. |
| Recommendation — Bind each tool call to current caller identity and scope before allowing execution. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Missing per-call verification lets reused or forged requests reach the tool surface. |
| Recommendation — Require fresh authentication context for each API-backed tool request. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Per-call verification depends on controlled lifecycle and use of authenticators and tokens. |
| AC-6 — Least Privilege | Tool use must stay tied to the minimum authority granted to the caller. | |
| AU-2 — Event Logging | Each call needs traceable identity and authorization evidence for auditability. | |
| Recommendation — Rotate, bound, and validate authenticators so they cannot be reused beyond intended authority. Enforce least-privilege authorization on every tool invocation. Log caller identity, decision context, and tool outcome for every invocation. | ||
Practitioner Guidance
What to verify: Confirm that the server re-evaluates the caller’s current identity and audience on every tool invocation, not just at session start. If the design cannot show that binding, treat the tool path as implicitly over-trusted.
Decision rule: If a tool can affect production data, secrets, or downstream systems, require per-call authorization checks and reject designs that rely only on prior authentication or transport trust. If the tool is read-only and low impact, the tolerance is still limited, because stale identity state can still defeat audit and revocation.
What good looks like: The server can explain, for any individual tool call, which identity was accepted, what policy allowed it, and why that authority was still valid at that moment.
Practitioner takeaway: The control is not “did the caller authenticate once”, it is “can the server prove the caller was still entitled to use this tool at the instant of each call”.
Related resources from NHI Mgmt Group
- What breaks when Postgres MCP access is not governed at the tool-call layer?
- What breaks when pagination is flattened into a single MCP tool call instead of being designed explicitly?
- What breaks when an MCP server's tool descriptions do not match its actual actions?
- What breaks when MCP tools are approved at the server level but not at the tool level?