TL;DR: MCP turns AI agents and LLMs into tool-using identities that can reach databases, APIs, and internal systems, which makes fine-grained authorisation a governance issue rather than a coding convenience, according to Cerbos. Static role checks and hardcoded rules do not scale when agents act on behalf of different users with different limits, so the control problem is now who can do what, when, and under which context.
NHIMG editorial — based on content published by Cerbos: securing MCP servers with fine-grained authorisation for AI agents
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step policy examples for managers, admins, and context-based tool restrictions.
- Implementation guidance for integrating Cerbos decisions into an MCP server runtime.
- Decision logging details for audit and compliance reporting across agent sessions.
- Practical examples of attenuating user permissions before exposing tools to an AI agent.
👉 Read Cerbos's guide to securing MCP servers with fine-grained authorisation →
MCP server security and fine-grained authorization for AI agents?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server authorization gaps are becoming an AI control problem