MCP server authorization gaps are becoming an AI control problem

At a glance

What this is: Cerbos examines how MCP turns AI agents into tool-using identities and argues that fine-grained authorization is now the central control issue for MCP-connected systems.

Why it matters: IAM and security teams need a way to decide who, or what, an agent may do in context because MCP expands agent reach into sensitive systems without changing the underlying accountability problem.

Context

MCP creates a direct control plane between AI agents and enterprise systems, which means the security problem is no longer just whether an agent can connect. The real issue is whether each tool call is governed with the same precision that organisations expect for human and service-account access.

For identity programmes, that changes MCP from an integration pattern into an authorization boundary. When an agent can query data, create records, or trigger actions on behalf of different users, coarse role checks and code-embedded rules become too blunt to preserve least privilege.

The article treats that shift as a governance problem, not a developer convenience issue. The starting position for most organisations is still too static for the mix of context, delegation, and action-level decisions MCP introduces.

Key questions

Q: How should security teams enforce per-client authorization in MCP environments?

A: 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.

Q: Why do static roles create risk in MCP-connected AI workflows?

A: Static roles are too coarse when an agent may submit, approve, or delete data under different limits and contexts. If the policy cannot consider resource state, user relationship, and action type, the agent can exceed the authority that the organisation intended to grant.

Q: What breaks when MCP authorization is left to individual users?

A: You get fragmented trust, inconsistent policy, and no reliable enterprise audit trail. Individual consent creates access sprawl that is hard to distinguish from sanctioned access, and revocation becomes partial or delayed because no central authority owns the full path from identity to tool access.

Q: How should security teams govern AI agent audit logging in MCP workflows?

A: They should require logs that combine actor identity, tool usage, data classification, and action outcome in one record. That makes it possible to distinguish human initiation from agent execution and to support compliance review, incident investigation, and privilege decisions. If local stdio is in play, the logging design also needs endpoint visibility, not only network inspection.

Technical breakdown

MCP creates a new authorization boundary for agent tool use

Model Context Protocol standardises how AI agents and LLMs call external tools, databases, and APIs, which makes the agent the active decision-making subject at runtime. That matters because the control point moves from simple data retrieval to tool invocation, where each action can change state, expose records, or trigger downstream workflows. MCP itself does not solve authorisation. It defines the connection layer, but the security question is whether the server can decide, per action, what the principal may do in the current context.

Practical implication: Treat MCP tool exposure as an authorization problem first and an integration problem second.

Why static roles break down in MCP server security

The article’s core technical argument is that static RBAC alone does not capture MCP’s action diversity. An expense workflow, for example, may allow one role to submit, another to approve within limits, and a third to delete. Once those rules depend on amount, department, or session context, embedding them in server code becomes brittle. The authorisation layer has to externalise policy so the MCP server can evaluate live conditions without redeploying whenever business logic changes.

Practical implication: Move permission logic out of tool handlers and into a policy engine that can evaluate roles plus attributes at runtime.

Dynamic authorization enables tool-level enablement and auditability

Cerbos is presented as an external policy decision point that answers allow or deny at runtime, letting the MCP server enable only the tools that a principal may use. That pattern matters because it supports least privilege at the level of individual actions rather than at the level of the whole session. The article also stresses decision logs, which are critical because AI-driven tool use needs an auditable record of who, or which agent, invoked which action and under what policy outcome.

Practical implication: Log every tool decision and make the authorization result visible before the action executes.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP authorization is now an identity governance problem, not just an API control problem. Once an AI agent can invoke tools on behalf of a user, the organisation must govern the agent’s action scope the same way it governs any other non-human identity. Static code checks are too narrow because the real decision is contextual, not just structural. The practitioner implication is that MCP belongs in the same governance conversation as service accounts, delegated access, and privileged workflows.

Fine-grained authorization is the named control gap this article exposes. MCP-connected agents can operate across read and write paths, but coarse role checks cannot express per-tool, per-resource, and per-transaction limits well enough. That is the gap: not lack of authentication, but lack of contextual decisioning at the point of use. The implication is that teams need to separate tool exposure from tool permission.

Tool enablement must follow policy, not application logic. Hardcoding checks inside MCP servers creates policy drift because each new role, threshold, or exception requires code changes. Externalised policy restores governability because the tool surface can change without rewriting the application. The practitioner implication is that MCP server design should assume policy churn and make authorisation independently maintainable.

Decision logging becomes part of the control plane for AI agents. When agents act through MCP, organisations need to know what was allowed, what was denied, and why. That is not merely forensic detail; it is evidence that delegated access stayed within bounds. The implication is that authorization without durable decision logs is incomplete for enterprise use.

Contextual least privilege is the real operating model for MCP-connected agents. The article shows why the relevant unit is not the agent alone, but the agent plus the user context, action type, and resource state. That is where modern identity control is heading for NHI and agentic workflows alike. The practitioner implication is to design policies around bounded action context rather than static entitlement buckets.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Contextual least privilege is becoming the default design pattern for AI agents. MCP-connected agents do not fit the old assumption that a single role can describe all authorised behaviour. Access has to be evaluated against the current resource, action, and user context, or the agent will inherit more power than the programme can actually justify.

Decision logging is no longer a nice-to-have for NHI governance. Once agents can act through MCP, the organisation needs a durable record of each allow or deny decision to support audit, incident review, and accountability. Without that record, delegated access becomes difficult to prove, even when the policy itself is sound.

19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey. That gap shows why MCP security now has to be designed as a privilege-governance problem, not a tooling convenience problem.

For practitioners

• Externalize tool authorization policy Define MCP permissions outside server code so role, resource, and context changes do not require redeploying the tool host.
• Gate each tool by context Evaluate the requested action against user role, resource attributes, and limits such as amount, department, or operation type before exposing the tool.
• Separate read and write pathways Treat read-only access, approval actions, and destructive actions as distinct authorization decisions rather than one shared permission set.
• Log every authorization decision Record who or what requested the action, which policy applied, and whether the call was allowed or denied so you can prove control over agent activity.

Key takeaways

• MCP turns AI agents into active non-human identities that can change state across enterprise systems, so the main control issue is authorization at the point of use.
• Static roles and hardcoded checks do not scale when permissions depend on context, action type, and resource state.
• Externalised policy and decision logging are the controls that make MCP tool use governable in practice.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Contextual Access Control: Contextual access control changes access decisions based on factors such as device posture, application risk, location, or data sensitivity. In cloud security, it helps move access policy from static entitlements toward decisions that reflect the actual conditions of use.

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 building or maturing an IAM programme, it is worth exploring.