Notifications
Clear all
Topic starter
12/06/2026 12:40 am
TL;DR: MCP makes AI agents operational by letting them call tools and APIs, but that raises a new authorization problem: how to grant only the right actions at runtime without hardcoded role logic, according to Cerbos. The central shift is from static permissions to policy-driven, context-aware access decisions that can scope agent behaviour safely.
NHIMG editorial — based on content published by Cerbos: dynamic authorization for MCP servers and AI agents
Questions worth separating out
Q: How should security teams govern AI agent tool access in MCP servers?
A: They should treat MCP tool access as a policy decision, not a code branch.
Q: When does role-based access control become too limited for MCP workloads?
A: RBAC becomes too limited when the same tool must behave differently based on ownership, amount, team, environment, or request state.
Q: What breaks when MCP servers expose all tools to every agent session?
A: Overexposure breaks least privilege and makes delegated action harder to contain.
Practitioner guidance
- Move tool authorization out of application code Use a separate policy decision service so MCP servers do not depend on embedded if and then logic for every role and tool combination.
- Model MCP permissions as attributes Define conditions on principal, resource, and request attributes so approvals, deletions, and similar actions can be constrained by context instead of role alone.
- Limit tool exposure per session Enable only the tools that a given principal can actually use for that request, rather than exposing the full server tool set to every connected agent.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- The full policy file example for tool-level allow and deny rules across user, manager, and admin roles
- The container deployment steps for running the Cerbos PDP alongside an MCP server
- The Node.js implementation details for dynamically enabling and disabling tools at session start
- The ABAC snippet that shows how to pass resource attributes into authorization decisions
👉 Read Cerbos's guide to dynamic authorization for MCP servers and AI agents →
MCP server authorization: are your tool controls keeping up?
Explore further
12/06/2026 10:06 am
Static role logic is too blunt for MCP tool governance. This article shows why hardcoded if and then checks do not survive context-rich authorization needs. Once tool access depends on role, resource attributes, and request state, the control problem becomes policy governance, not application branching. That is a familiar NHI pattern: when the actor can take action, permission design must match the action surface, not the login surface. Practitioners should treat MCP tool access as privileged identity control, not as a UI feature.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 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.
A question worth separating out:
Q: What should teams use instead of hardcoded if and then permissions for agents?
A: Teams should use declarative authorization policies that are evaluated at request time. That approach gives a single decision layer for multiple tools, lets security teams review permissions without redeploying code, and keeps agent behaviour aligned with the current access policy.
👉 Read our full editorial: Dynamic access control for MCP servers and AI agents
