MCP server authorization gaps are becoming an AI control problem

At a glance

What this is: This is an independent analysis of why MCP-connected AI agents create a fine-grained authorisation problem, with the key finding that static, code-embedded checks do not scale for tool-using identities.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent tool access, delegated permissions, and auditability in the same control model, not as separate disciplines.

By the numbers:

• Gartner analysts predict that by 2026, more than 80% of independent software vendors will have embedded GenAI capabilities in their enterprise applications, up from less than 5% today.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Cerbos's guide to securing MCP servers with fine-grained authorisation

Context

MCP, or Model Context Protocol, is the standard that lets AI agents call tools, query databases, and trigger actions through a common interface. The governance gap is that the identity performing the action is often not a human operator, yet the authorisation model is still treated as if it were a normal app-to-app request.

That breaks existing IAM assumptions in two ways. First, the agent can take multiple actions across systems in one session. Second, those actions may be derived from a user context that needs to be attenuated, not copied, which makes least privilege and auditability central to MCP security.

The article is typical of the current market moment: the protocol is moving faster than the authorisation model around it. That is exactly where NHI governance starts to matter, because tool access is now the policy boundary, not the model output.

Key questions

Q: How should security teams implement fine-grained authorisation for MCP servers?

A: Start by separating authentication from authorisation and treating every tool call as a policy decision. Externalise the rules into a policy engine, pass user or agent attributes at runtime, and evaluate each action against resource context before enabling the tool. This avoids hardcoded checks, reduces drift, and keeps MCP access aligned with current governance intent.

Q: Why do MCP-connected AI agents complicate least privilege?

A: Because the agent may act on behalf of a person but still have access to multiple tools, data sources, and systems within one session. Least privilege is harder when the actor can switch between read, write, and administrative actions dynamically. The control challenge is to attenuate the delegated permissions so the agent can only do what the use case requires.

Q: What breaks when MCP server permissions are hardcoded in application code?

A: Policy changes become redeployments, which increases delay, error risk, and authorisation drift. Hardcoded checks also encourage inconsistent enforcement across tools, especially when conditions depend on context such as amount limits, team membership, or resource type. The result is brittle governance that cannot keep pace with changing access requirements.

Q: How do you know if MCP tool access is actually under control?

A: Look for per-request decision logs, consistent allow and deny outcomes, and a clear match between the tools exposed to the agent and the permissions defined in policy. If the server advertises capabilities that the identity cannot use, or if approvals are not logged with policy context, control is incomplete.

Technical breakdown

MCP tool invocation creates a new authorisation boundary

MCP standardises how an AI agent reaches external systems, but the protocol itself does not decide whether a tool call should be allowed. That decision sits at the authorisation boundary, where the principal, the tool, and the context must be evaluated together. In practice, this means a session can include read, write, and administrative tool calls across different systems, each with different risk. The control problem is not whether the agent can reason about the task. It is whether the server can enforce policy at the moment of each tool invocation.

Practical implication: Treat every MCP tool as an access-controlled resource, not a convenience function, and enforce policy before execution.

Why hardcoded role checks fail in MCP servers

Hardcoded if/else logic works only when permissions are simple and stable. MCP servers quickly become more complex because a single agent may carry a user identity, a service identity, or both, and the permitted action may depend on attributes such as department, amount, or target resource. RBAC alone usually cannot express these conditions cleanly, while ABAC and policy-based access control can. When rules live inside application code, every policy change becomes a redeploy, which creates drift between governance intent and runtime behaviour.

Practical implication: Externalise MCP authorisation into policy so permission changes do not require application code changes.

Dynamic tool enablement is the practical control pattern

A scalable MCP pattern is to evaluate the identity once, query the policy engine for allowed actions, and enable only the authorised tools for that session. That shifts control from static tool lists to runtime decisioning. It also improves auditability, because every allow or deny decision can be logged with the principal, resource, and policy basis. In identity terms, this is the difference between exposing the whole tool surface and presenting only the authorised slice of it.

Practical implication: Use per-session policy evaluation and decision logging so agents only see the tools they are allowed to use.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 exposes the authorisation gap between an AI agent and the systems it can reach. The protocol turns models from text producers into tool callers, which makes access control the real security boundary. If the server cannot distinguish between read-only, limited-write, and administrative actions at runtime, the agent inherits too much authority. The practitioner conclusion is simple: the control plane has to govern tool execution, not just authentication at session start.

Static role logic is too brittle for tool-using identities. MCP access decisions often depend on attributes such as requester context, target record, transaction value, or team membership, not just a role name. Hardcoding those checks into server code makes policy changes slow and error-prone, which is how authorisation drift enters production. The practitioner conclusion is that MCP permissions need external policy evaluation, not embedded business logic.

Fine-grained MCP authorisation is now an NHI governance requirement, not an optional safeguard. Once an agent can act on behalf of a user, the question becomes whether that identity is carrying an attenuated permission set or an over-broad one. That connects human IAM, delegated access, and non-human execution into one governance problem. The practitioner conclusion is to govern the agent as a non-human executor with explicit scope, not as a passive interface.

Tool visibility must be treated as a control, not just a UX feature. If the MCP server advertises every available tool before policy filtering, the agent and user can see capabilities they should never be able to invoke. That creates confusion at best and unsafe prompting at worst. The practitioner conclusion is to make tool exposure itself policy-driven so the visible surface matches the allowed surface.

Runtime authorisation drift: MCP creates a live gap between what the system can do and what the current identity should be allowed to do. That gap widens when permissions are coded in the server, because governance changes lag implementation. The practitioner conclusion is to monitor the difference between declared policy and actual tool enablement as a first-class identity control.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• For a broader agent-governance view, see OWASP Agentic Applications Top 10 for the runtime control failures that often accompany tool misuse.

What this signals

MCP is turning authorisation into the primary control plane for AI-assisted operations. As more agents gain access to real systems, the deciding factor is not model quality but whether policy can constrain tool execution in real time. Teams should expect authorisation requests, decision logging, and tool filtering to become routine parts of AI platform design.

Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation. That figure from our AI agents research shows how quickly visibility breaks down once tool-using identities proliferate. The practical response is to align MCP governance with OWASP Agentic Applications Top 10 and the NIST AI Risk Management Framework so runtime policy, logging, and accountability move together.

Runtime authorisation drift will become a recurring governance concept for organisations that adopt MCP before they modernise identity controls. The issue is not simply tool sprawl. It is the mismatch between what the agent can reach and what the programme can still explain, review, and certify.

For practitioners

• Externalise MCP policies from application code Move tool permissions into a dedicated policy layer so role, attribute, and context changes can be updated without redeploying the server. Keep the MCP service focused on request handling and delegate allow or deny decisions to the policy engine.
• Map each MCP tool to a discrete resource action Define read, write, approve, and delete as separate actions rather than bundling them into broad tool access. This lets you apply different rules for different identities, especially where a human user’s permissions should be attenuated for the agent session.
• Log every authorisation decision with policy context Capture the principal, resource, action, rule outcome, and timestamp for each MCP check so security, audit, and compliance teams can reconstruct what the agent was allowed to do. Make those logs searchable across sessions and tool types.
• Enable tools only after policy evaluation Do not present the full tool list by default. Evaluate the identity first, return only the allowed tools for that session, and re-check before any high-risk action such as write or delete operations.

Key takeaways

• MCP turns AI agents into real tool users, so authorisation becomes the security boundary that matters most.
• Hardcoded permissions and static role checks do not scale once agents act across systems with context-dependent limits.
• External policy evaluation, per-action logging, and filtered tool exposure are the controls that make MCP governable.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to external tools, services, and data sources in a standard way. In security terms, MCP shifts the problem from text generation to action authorisation because the agent can now request real operations inside enterprise systems.
• Fine-Grained Authorisation: A permission model that decides access at the level of individual actions, resources, and context rather than broad roles alone. For MCP, it is what stops an agent from using a tool simply because it can see it or because the human user has some related permission.
• Policy-Based Access Control: An access model in which decisions are made by external rules that consider roles, attributes, and environmental context. It is useful for MCP because permissions can change without rewriting server code, which keeps governance separate from application logic.
• Decision Logging: The practice of recording each allow or deny outcome together with the principal, resource, action, and policy basis. For AI agents, decision logging is essential because it creates an audit trail showing what the identity tried to do and why the system permitted or blocked it.

Deepen your knowledge

MCP server authorisation and fine-grained policy design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for agent tool access, it is worth exploring.

This post draws on content published by Cerbos: securing MCP servers with fine-grained authorisation for AI agents. Read the original.