MCP security risks expose a new authorization blind spot

At a glance

What this is: This is an analysis of MCP security risks and the article's central finding is that AI-powered servers can leak data through authorization failure even when authentication is intact.

Why it matters: It matters because IAM, NHI, and human access controls all break down when a privileged mediator makes context-sensitive decisions without consistent external authorization.

👉 Read Cerbos's analysis of MCP security risks and externalized authorization

Context

MCP security risks are not primarily an authentication problem. The article argues that a Model Context Protocol server can sit inside a trusted session, use powerful backend credentials, and still return another user's data if authorization is not enforced at every step.

For identity teams, that shifts the control question from who logged in to what the AI-enabled intermediary is allowed to do with the session it holds. The governance gap sits at the boundary between user identity, delegated access, and backend authority, which is exactly where traditional API assumptions become fragile.

Key questions

Q: How should security teams secure MCP servers that act on behalf of users?

A: Security teams should treat MCP servers as authorization boundaries, not trusted passthroughs. Every sensitive action should be checked by a central policy engine at the agent layer, the MCP layer, and the backend service layer. That approach preserves context, limits overreach, and produces an auditable decision trail for identity governance.

Q: Why do MCP security risks create problems for least privilege?

A: MCP security risks undermine least privilege because the intermediary can inherit broad user permissions or use powerful service credentials to access more data than the task requires. Once the server combines sessions, tools, and backend systems, the original scope of the request is easy to exceed unless policy is enforced per action.

Q: What do teams get wrong about role-based access control for AI systems?

A: Teams often assume roles can describe AI access accurately enough to govern it, but AI-driven requests are context-heavy and dynamically assembled. RBAC quickly becomes either too broad or too fragmented to manage, which is why teams need resource-specific policy decisions rather than larger role catalogues.

Q: How do you know if authorization is actually working in an MCP architecture?

A: Authorization is working when the same policy decision is applied consistently at every trust boundary and every decision is logged with the acting identity, resource, and context. If a downstream service can still see or return data without an explicit policy check, the model is not actually controlling access.

Technical breakdown

Why MCP servers break the identity chain

An MCP server often sits between a logged-in user and backend services, but it does not behave like a simple API proxy. It can either use its own service account or impersonate the user through delegated tokens, and both patterns create risk if authorization is not re-evaluated per request. The first pattern breaks end-to-end identity visibility because downstream services only see the privileged server account. The second preserves identity on paper but can still overextend the user's permissions in context. In both cases, the core mechanism is the same: a trusted intermediary becomes the decision point for access it should not be making alone.

Practical implication: treat the MCP layer as an authorization boundary, not a trusted pass-through.

Why RBAC and hard-coded checks fail for AI-driven access

Role-based access control works poorly when an AI system generates dynamic queries, combines data sources, and changes its behaviour based on context. Roles are too coarse to express relationship-based or session-specific decisions, so teams either over-grant access or drown in role sprawl. Hard-coded if/else authorization in the application is even weaker because policy becomes scattered across services and deployment cycles. That creates inconsistent enforcement, poor auditability, and slow policy change. The technical issue is not just complexity. It is that AI-driven access decisions are runtime decisions, while RBAC and embedded code assume stable, pre-modelled paths.

Practical implication: move authorization out of application logic and into a centralized decision layer.

How externalized authorization restores fine-grained control

Externalized authorization splits enforcement from decision-making. A Policy Enforcement Point asks a central Policy Decision Point whether a specific action on a specific resource is allowed for a specific identity in the current context. In MCP architectures, that check needs to happen at the agent, at the MCP server, and again at each backend service. This creates a chain of verification instead of a single trust jump. The model is effective because each component stays simple while policy remains consistent, logged, and reusable across services. In practical terms, it is the difference between hoping a privileged intermediary behaves correctly and forcing every hop to prove it has permission.

Practical implication: enforce per-resource decisions at each trust boundary, not just at the front door.

NHI Mgmt Group analysis

Authorization, not authentication, is the control plane that MCP security risks expose. The article shows a system can verify the user correctly and still leak data because the MCP layer is allowed to reinterpret or amplify that identity inside backend systems. That is an IAM governance problem, not a login problem. Fine-grained access controls lose meaning if the intermediary can collapse the boundary between requested action and permitted action. The practitioner conclusion is simple: the security model must govern delegated action, not just user entry.

Role-based access control is too static for AI-mediated access paths. RBAC assumes access can be pre-modelled into durable roles, but MCP-driven workflows assemble actions dynamically at runtime. That creates role sprawl, over-provisioning, and a false sense of auditability. The article correctly shows why context-sensitive decisions around data ownership, tool use, and session intent cannot be represented cleanly by coarse roles. The practitioner conclusion is that AI access needs relationship-aware authorization, not larger role catalogues.

Externalized authorization is the right architecture because it restores a single source of truth. Separating policy decision from policy enforcement makes the control plane visible, auditable, and reusable across agent, MCP, and backend layers. That matters because the same policy must be applied consistently at each hop, or the weakest hop becomes the breach point. The practitioner conclusion is that AI systems need centralized policy evaluation with distributed enforcement, not embedded security logic hidden in application code.

MCP security risks are becoming a broader identity governance issue, not a niche AI problem. Once an AI intermediary can combine user context with privileged service access, the distinction between human IAM, NHI privilege, and application authorization starts to blur. That means identity teams must evaluate delegated access paths as part of the same governance programme that covers service accounts and sensitive human entitlements. The practitioner conclusion is that AI authorization should be managed as part of enterprise identity governance, not as a separate experiment.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves most environments unable to trace privileged machine access end to end.
• 52 NHI Breaches Analysis shows how weak lifecycle control turns privileged identities into repeatable attack paths.

What this signals

Identity blast radius: MCP systems expand the impact of a single delegated session because one privileged intermediary can touch multiple back-end systems before any human review occurs. That changes the programme focus from user login assurance to containment of downstream authority, especially where service accounts and API keys already carry excessive privilege.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, the trust problem now extends beyond humans and into machine-mediated workflows. Security teams should expect MCP-style patterns to surface the same governance weaknesses already seen in third-party NHI exposure.

The practical signal to watch is whether authorization decisions remain visible outside the application code. If policy cannot be reviewed, versioned, and audited independently of the agent workflow, the programme is effectively relying on hidden logic to govern access, which is a control design problem rather than an AI novelty.

For practitioners

• Implement centralized policy decisions for every MCP hop Require the agent, the MCP server, and downstream services to ask a central policy engine before each sensitive action. Keep enforcement lightweight, but never rely on the intermediary's own judgment for access to customer, financial, or internal records.
• Replace coarse roles with resource-specific policy rules Map access around resource ownership, request context, and session purpose instead of creating broad roles such as support bot or finance assistant. This reduces role sprawl and prevents AI systems from inheriting more access than the task requires.
• Remove authorization logic from application code Move decision-making out of if/else blocks in the MCP server and into a dedicated policy layer. Keep application services focused on execution, while policy versioning, reviews, and audit logs remain centrally managed.
• Log every delegated decision in a consistent format Capture who requested the action, which identity acted, what resource was touched, and which policy produced the decision. That record is the difference between a controllable AI access path and an unreviewable super-user pattern.

Key takeaways

• MCP security risks are fundamentally authorization failures, not authentication failures.
• Dynamic AI access paths expose the limits of RBAC, especially when a privileged intermediary can combine multiple data sources.
• Centralized policy decisions with distributed enforcement are the clearest path to auditable least privilege for AI systems.

Key terms

• Model Context Protocol server: A Model Context Protocol server is a component that exposes tools and data sources to an AI application. In practice, it becomes an identity-sensitive trust boundary because it can carry user context, backend credentials, or both, and its authorization behaviour determines whether delegated actions stay within scope.
• Confused deputy: A confused deputy is a trusted system that is tricked into using its authority in ways the original requester should not be able to control. In AI workflows, the risk appears when an intermediary with legitimate access performs actions outside the true intent or scope of the user session.
• Externalized authorization: Externalized authorization separates the decision about access from the component that enforces it. Instead of embedding policy in application code, services ask a central decision point whether a specific action is allowed, which improves consistency, auditability, and policy reuse across AI and non-AI systems.
• Policy enforcement point: A policy enforcement point is the component that stops a request, asks for an authorization decision, and applies the result. It does not define policy itself. In AI architectures, placing enforcement points at each trust boundary prevents a privileged intermediary from becoming an unchecked super-user.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: MCP security risks and the architecture of a modern data leak. Read the original.