Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side. The user’s general login must never become blanket permission for any application that can reach the MCP endpoint. Consent records, exact client identifiers, and server-side policy checks are the controls that prevent confused deputy abuse.
Why This Matters for Security Teams
Per-client authorization in MCP is not just an access-control detail. It is the control that stops one approved application from inheriting another application’s privilege, especially when both sit behind the same human login. For agentic and tool-using workloads, static RBAC is often too coarse because the request path changes at runtime and the tool being called may not match the user’s original intent. Current guidance in the OWASP Agentic AI Top 10 and OWASP Agentic Applications Top 10 both points to the same issue: autonomous systems need runtime checks, not trust-by-proxy.
That means the server must verify which client is calling, what scope was consented to, and whether the operation is still allowed at the moment of execution. A valid user session is not enough. If the MCP server accepts any request that arrives with a generic bearer token, it becomes vulnerable to confused deputy abuse, scope creep, and cross-client data exposure. In practice, teams usually discover the gap only after an approved client has already been used to perform an action that no one explicitly authorised.
How It Works in Practice
The safest pattern is to treat the MCP server as the final policy enforcement point. Each request should carry a verifiable client identity, a scoped consent record, and a workload identity or equivalent cryptographic proof of who is acting. The server then evaluates policy at request time, not just at login time. That is consistent with the direction of OWASP Top 10 for Agentic Applications 2026 and the governance approach described in NIST AI RMF, where context and accountability matter as much as authentication.
Operationally, this usually means:
- Binding each token or session to a specific client ID, not just a user.
- Checking the approved tool, resource, and operation against server-side policy on every call.
- Issuing just-in-time, short-lived credentials for high-risk operations instead of long-lived secrets.
- Recording consent so the server can prove which client was allowed to do what, and when.
- Using policy-as-code so changes to scope do not depend on application developers to enforce them correctly.
This is especially important for agentic workflows because an AI agent may chain tools, retry actions, or change plans mid-task. NHIMG research on Analysis of Claude Code Security shows why execution context and tool boundaries matter when automation is allowed to act with delegated authority. The control objective is simple: even if the human is authenticated, the server must still answer whether this exact client is allowed to perform this exact action for this exact purpose. These controls tend to break down when multiple clients share one integration token or when the server relies on upstream application logic instead of enforcing policy itself.
Common Variations and Edge Cases
Tighter per-client controls often increase integration overhead, so organisations have to balance security with developer usability and support burden. That tradeoff is real, especially when an MCP deployment serves many internal apps, plugins, or agent runtimes. There is no universal standard for this yet, but current guidance suggests the strongest implementations use short-lived credentials, explicit consent records, and runtime authorisation checks rather than broad, persistent grants.
One common edge case is a “trusted” first-party client that later becomes a deputy for other software. Another is a gateway or proxy that rewrites requests and obscures the true calling client. In both cases, the server still needs a stable identity signal it can trust. Where organisations rely on shared secrets or broad service accounts, the result is usually excessive access that defeats the purpose of client-level authorisation. NHIMG’s OWASP Agentic Applications Top 10 analysis is especially useful here because it frames over-permissioned autonomous behaviour as a design flaw, not just an operational mistake.
For security teams, the practical rule is to authorise the client as a workload, not merely the human behind it, and to revoke standing access whenever the task is complete. That is the only reliable way to keep MCP from turning a single login into universal permission.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Addresses over-privileged agent/tool flows and runtime authorization risks in MCP. | |
| CSA MAESTRO | Maps to agent governance and control boundaries for autonomous tool use. | |
| NIST AI RMF | Supports risk-based governance for dynamic, context-aware authorization decisions. |
Enforce request-time policy checks for each tool call and scope agent access to explicit consent.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams choose between CLI and MCP for AI tool access?
- What is the difference between MCP and REST for enterprise security teams?
- What are MCP Authorization Extensions and how do they help organizations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
