Notifications
Clear all
Topic starter
11/06/2026 11:33 pm
TL;DR: MCP-based AI systems can leak cross-user data without any authentication breach when a privileged server misapplies session context or user permissions, according to Cerbos. The real failure is authorization design: existing RBAC and inline logic do not hold up when AI-driven components decide what to fetch and from where.
NHIMG editorial — based on content published by Cerbos: MCP security risks and the architecture of a modern data leak
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Remove authorization logic from application code Move decision-making out of if/else blocks in the MCP server and into a dedicated policy layer.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of the broken identity chain in MCP architectures and where delegated authority starts to fail
- A practical comparison of RBAC, hard-coded logic, and externalized authorization in AI application design
- Implementation detail for policy enforcement points and policy decision points across agents, MCP servers, and backend services
- Cerbos Hub workflow detail for policy versioning, review, and deployment in production environments
👉 Read Cerbos's analysis of MCP security risks and externalized authorization →
MCP security risks: are your authorization controls keeping up?
Explore further
12/06/2026 8:17 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security risks expose a new authorization blind spot
