MCP increases risk because it connects untrusted model output to real systems that can act on it. That creates new paths for token exposure, overbroad authorization, rogue endpoints, and confused deputy behaviour. The issue is not AI novelty, but the expansion of machine-to-machine trust at runtime.
Why This Matters for Security Teams
MCP changes the identity problem because it turns model output into authenticated action across tools, data sources, and administrative APIs. That means the real risk is not simply bad prompts, but the expansion of machine-to-machine trust at runtime. When access decisions are still built around human-centric IAM assumptions, MCP deployments can inherit overbroad service accounts, reusable secrets, and weak endpoint trust.
This is why practitioners should read MCP through the lens of non-human identity governance, not just application security. The Ultimate Guide to NHIs shows how excessive privilege and poor secret hygiene already dominate NHI risk, and the same patterns reappear when MCP servers are introduced as new trust brokers. OWASP’s OWASP Non-Human Identity Top 10 also reflects the core issue: identity controls fail when workloads can act autonomously and at machine speed.
In practice, many security teams discover MCP exposure only after a tool call has already accessed sensitive systems through credentials that were never meant to be reused that broadly.
How It Works in Practice
MCP deployments typically insert a protocol layer between the model and one or more tools, which is useful for orchestration but dangerous if identity is not rethought at the same time. A model can request a tool call, but the server, connector, or gateway still needs to decide whether that request should be honored right now, with this context, for this exact scope. That is why static RBAC alone is usually too blunt for autonomous workloads.
Current guidance suggests treating the MCP server and every connected tool as separate workload identities, each with its own authentication, authorization, and audit boundaries. In stronger implementations, identity is established with workload identity primitives such as SPIFFE-style cryptographic identity or short-lived OIDC tokens, while authorization is evaluated at request time through policy-as-code. This aligns closely with OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0, both of which emphasize least privilege, governance, and continuous control.
Operationally, the safer pattern is:
- Issue JIT credentials per task, not long-lived tokens that can be replayed later.
- Scope tool permissions narrowly, and bind them to task context rather than a broad role.
- Separate the identity of the MCP server from the identity of upstream users and downstream tools.
- Log tool intent, policy decision, and secret use together so investigations can reconstruct the chain of action.
Astrix Security’s research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how early most environments still are. These controls tend to break down when MCP endpoints are treated as generic integration services because the model can chain tools in ways the original access design never anticipated.
Common Variations and Edge Cases
Tighter MCP authorization often increases operational overhead, requiring organisations to balance runtime safety against developer speed and integration complexity. That tradeoff is real, especially in environments with many tools, fast-changing prompts, or brittle legacy systems. There is no universal standard for this yet, so best practice is evolving rather than settled.
One common edge case is a shared MCP gateway used by multiple agents or applications. If the gateway identity is broad, the blast radius becomes broad even when individual agents are well-scoped. Another is callback or webhook style integrations, where the original request context is lost and the downstream system cannot reliably tell whether a subsequent action is still authorized. In those cases, intent-based authorization becomes more important than static allowlists.
Teams also need to distinguish between short-lived credentials and merely rotated credentials. A rotated secret can still be dangerous if it remains valid across many tasks, while a JIT credential expires before it can be reused elsewhere. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce the same lesson: identity controls fail when secret lifetime, privilege scope, and runtime context are managed separately.
These patterns break down most clearly in multi-tenant MCP platforms where tenant isolation, tool federation, and shared secrets collide in the same control plane.
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 Non-Human Identity Top 10 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 | A-04 | Addresses tool abuse and runtime agent authorization risks in MCP deployments. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret exposure and overprivileged machine identities common in MCP. |
| NIST AI RMF | Supports governance for autonomous AI systems that trigger real system actions. |
Establish accountability, monitoring, and risk controls for agent-driven runtime decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
