Because access scope, user attribution, and per-request authorization are different from the mechanics of running a tool. A runtime can centralise policy enforcement, but if identity is not propagated correctly, the environment falls back to shared credentials and weak auditability. That defeats least privilege even when the runtime is otherwise hardened.
Why MCP runtimes need separate identity and policy controls
MCP runtimes sit at the boundary between an AI client, a tool, and the resource being accessed. That boundary only works safely when identity says who is acting, policy says what that actor may do, and the runtime preserves that distinction on every request. If either layer is collapsed into a shared runtime credential, you lose attribution, least privilege, and meaningful per-request enforcement.
How identity and policy split the runtime’s job
An MCP runtime is not just a transport or execution wrapper. It has to carry the caller’s identity context, decide whether the call is allowed, and then invoke the tool without broadening access beyond the specific request. That separation is what prevents the runtime from becoming a single, overpowered intermediary that can do everything on behalf of everyone.
Identity controls answer the question, “Which user, agent, or workload is this request really coming from?” Policy controls answer, “What may this particular identity do in this specific context?” When those functions are separate, the runtime can enforce delegated authority without turning every tool invocation into a blanket trust decision. The MCP authorization specification reflects that design by treating the server as an OAuth resource server rather than letting tokens float freely through the stack.
This is also why identity propagation matters more than simple runtime hardening. A hardened server can still be operationally weak if it receives the same shared credential for every caller, because the logs will show system activity rather than user-specific actions. That creates a policy gap: enforcement may exist, but it is detached from the real subject making the request.
What breaks when MCP runtimes mix shared credentials with policy enforcement
When the runtime reuses a shared secret or passes a token through without binding it to the caller and audience, several failures appear at once. Access scope becomes broader than intended, tool calls become harder to attribute, and downstream systems can no longer distinguish between legitimate delegated use and generic runtime access. MCP Security Guide covers this exact failure pattern in practical terms, including token passthrough, local server credentials, and gateway controls.
That mix also creates a confused-deputy problem. The runtime may be trusted to enforce policy, but if it can present its own credentials to tools, the tool sees the runtime’s authority rather than the original caller’s limited intent. Over time, that makes least privilege drift into ambient privilege, especially when multiple agents or users share the same MCP deployment.
Tooling and agent layers make the problem sharper, not softer. Agentic systems often need tool access, delegation, and ephemeral credentials, which means the control design has to preserve caller identity while still allowing the runtime to broker access safely. AI Agent Identity Security: The 2026 Deployment Guide and OWASP Agentic AI Top 10 both reinforce that identity and privilege abuse are distinct from the mere act of running an agent.
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 | MCP runtimes must prevent delegated tool access from collapsing into shared privilege. |
| Recommendation — Bind each tool action to the originating identity and enforce least privilege at request time. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Non-Organizational Users) | MCP runtimes broker service-to-service and agent-to-tool authentication flows. |
| AC-6 — Least Privilege | The question is about preventing runtime access from exceeding the caller’s authority. | |
| Recommendation — Use IA-9 to authenticate non-organizational callers and preserve distinct identities per request. Limit the runtime and each tool invocation to the minimum permissions needed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token passthrough and shared credentials can break caller authentication at the API boundary. |
| API5 — Broken Function Level Authorization | Policy controls must decide which functions each caller may invoke through the runtime. | |
| Recommendation — Require audience-bound, per-caller authentication instead of reusable shared tokens. Authorize each function call independently before the runtime invokes the tool. | ||
Practitioner Guidance
What to verify: Confirm that every MCP request carries a caller-specific identity context, that authorization is evaluated per request, and that the runtime is not using a single shared credential to reach multiple tools or tenants. If the answer to any of those is no, you do not yet have a real separation of identity and policy.
What good looks like: The runtime enforces policy at the request boundary, tools receive only the minimum delegated scope needed for the call, and audit logs can tie each tool action back to the originating user or agent. That is the operational difference between controlled delegation and masked shared access.
Common mistake: Treating the MCP server as “secure enough” because it is authenticated once at startup. Startup authentication does not solve per-request authorization, audience binding, or attribution, and it usually hides excessive privilege until the first incident review.
Practitioner takeaway: If the runtime can act without preserving caller identity, it has become an authority concentrator, not just an execution layer. Separate identity from policy so the runtime can broker access without absorbing the full privilege of every tool it touches.
Related resources from NHI Mgmt Group
- What happens when AI agents use MCP without identity and policy controls?
- What is the difference between code scanning and runtime identity monitoring?
- How should organizations prioritize security in their MCP implementations?
- Why do MCP tools need server-side policy checks instead of token-only controls?