Topic starter
10/06/2026 11:41 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “MCP authorization: Securing Model Context Protocol servers with fine-grained access control”.
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.
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.
Q: What breaks when MCP authorization is left to individual users?
A: You get fragmented trust, inconsistent policy, and no reliable enterprise audit trail.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 5:59 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server authorization gaps are becoming an AI control problem
This post was modified 5 days ago by NHI Mgmt Group