Dynamic access control for MCP servers and AI agents

At a glance

What this is: This is a guide to building policy-driven authorization for MCP servers so AI agents only see and use tools they are permitted to invoke.

Why it matters: It matters because practitioners now need dynamic access controls that work for delegated agent actions, not just human logins or static service permissions.

👉 Read Cerbos's guide to dynamic authorization for MCP servers and AI agents

Context

MCP server authorization is becoming a core identity problem because AI agents are no longer just retrieving information, they are acting through external tools. The hard part is not whether an agent can connect to a tool, but whether the authorization layer can decide who can do what at the moment of execution.

Hardcoded if and then logic does not scale when permissions depend on role, resource, and request context. For IAM, this pushes MCP into the same governance conversation as NHI, delegated access, and policy-based control, because tool access now needs to be scoped as tightly as any other privileged identity path.

Key questions

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. The safest pattern is to keep tool registration static and make enablement depend on a separate authorization service that evaluates roles, attributes, and request context before the tool can run.

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. At that point, attribute-based policy is needed because it can express conditional access without multiplying roles or hardcoding exceptions into the MCP server.

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. If every session sees every tool, the agent can inherit capabilities that exceed the user intent, which increases the chance of unauthorized approvals, deletions, or data access when policy is not checked before execution.

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.

Technical breakdown

Why static role checks fail in MCP authorization

MCP exposes tools as callable actions, which means the server needs an authorization decision for each tool and each request. A simple role check can say whether a user is a manager or admin, but it cannot easily express conditions such as ownership, amount thresholds, or resource-specific limits. That creates brittle code because policy changes require application changes and redeployment. In practice, the authorization problem is closer to PBAC or ABAC, where the decision uses roles plus attributes from the principal, resource, and request. The server remains the execution layer, but policy becomes the control plane.

Practical implication: move tool permission logic out of the MCP server and into a policy engine that can evaluate context at request time.

How decoupled authorization enables fine-grained tool access

A decoupled authorization service lets the MCP server define all available tools while the policy decision point returns allow or deny for each action. That pattern separates tool discovery from tool authorization, which matters when different users should see different tool subsets in the same session. It also supports delegation, because the agent is acting on behalf of a principal rather than as an unconstrained actor. Human-readable policies are easier to review than embedded conditionals, and the same policy model can govern multiple tools without duplicating logic. The key architectural point is that authorization becomes external, stateless, and reusable across requests.

Practical implication: design MCP servers so tool registration is static, but tool enablement is decided dynamically by policy.

Where ABAC fits in agent tool governance

ABAC extends role-based access by letting decisions depend on attributes such as amount, team, record owner, environment, or request context. In an MCP setting, that is the difference between allowing a manager to approve all expenses and allowing them to approve only expenses under a threshold or within their own team. This is the right model when the same tool must behave differently across requests without splitting the application into many role-specific branches. It also keeps the agent from inheriting broader authority than the human or workload it represents. Fine-grained access is not just tighter security, it is the only way to preserve delegation boundaries in dynamic tool use.

Practical implication: model sensitive MCP actions with attributes, not just roles, and enforce those conditions before the tool runs.

Threat narrative

Attacker objective: The attacker or misbehaving agent seeks to turn a conversational interface into a privileged execution path for actions the user or workload should not be able to perform.

1. Entry occurs when an MCP-connected agent is allowed to reach external tools and APIs through a standard interface that expands its action surface.
2. Escalation happens if tool authorization is embedded in application code or role checks, because the agent may inherit broader access than the specific request warrants.
3. Impact is the abuse of over-permitted tools, including unauthorized approvals, deletions, or data access that should have been blocked by context-aware policy.

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

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.

Decoupled authorization creates the right control boundary for delegated AI actions. The article's core design choice is to move decisioning out of the MCP server and into a dedicated policy layer. That separation matters because it lets one authorization model govern many tools without copying logic into every agent-facing service. In identity terms, the server publishes capability, while policy determines entitlement. The implication is that MCP programmes should be reviewed as access governance architectures, not just integration work.

PBAC and ABAC are becoming the default language for agent tool permissions. Once agents act on behalf of a user, a single role cannot express the real control intent. Amount thresholds, ownership, team scope, and request context all become part of the authorisation question. That makes attribute-driven policy the practical bridge between human delegation and machine execution. The implication is that teams should expect agent tool governance to converge with broader NHI entitlement models rather than remain a special case.

Agentic access is still identity governance, not a new exemption class. MCP does not remove the need for least privilege, it changes where least privilege has to be expressed. The right control plane is the one that can answer who, what, and under which conditions before the tool executes. That aligns with OWASP NHI and zero trust thinking, where access is continuously evaluated instead of assumed from a session start. Practitioners should govern agent tools with the same discipline they apply to service accounts and privileged workflows.

Context-aware authorization is the named concept this article sharpens. The real problem is not whether an agent can reach a tool, but whether the tool is enabled only when the principal, resource, and request context justify it. That framing is more durable than static roles because it preserves delegation boundaries as workflows change. For practitioners, the lesson is to build for conditional entitlement, not blanket capability.

From our research:

• 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.
• If you are mapping this to an operating model, review OWASP Agentic Applications Top 10 alongside your MCP authorization design.

What this signals

Context-aware entitlement will become the minimum viable control for agent tool use. With 92% of organisations agreeing that governing AI agents is critical, yet only 44% having implemented policies, the operational gap is already visible in programme design. Teams that still rely on static role checks will struggle to explain or defend agent behaviour when tool access changes by request, resource, or time.

Delegated agent access needs the same lifecycle discipline as other privileged identities. Tool enablement, auditability, and offboarding should be designed together, because an agent that can call actions is functionally part of the identity perimeter. For practitioners, that means aligning MCP governance with zero trust, NHI lifecycle review, and policy evidence that can be inspected after the fact.

For practitioners

• 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.
• Review delegated agent access as privileged access Treat AI agents that invoke tools on behalf of users as delegated identities and put the same approval, scoping, and audit expectations around them.

Key takeaways

• MCP turns AI agents into action-bearing identities, so authorization must move from static code to policy-driven control.
• ABAC and PBAC are the practical mechanisms for constraining delegated agent actions by role, resource, and request context.
• Practitioners should govern agent tool access as privileged identity access, with dynamic enablement, auditability, and lifecycle discipline.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to external tools and data sources in a standard way. In identity terms, it increases the importance of runtime authorization because the agent can move from reading context to taking actions against real systems.
• Policy-Based Access Control: An authorization model that uses policies to decide whether a principal can perform an action on a resource. It is useful when access must reflect context, attributes, and exceptions that cannot be represented safely with only fixed roles.
• Attribute-Based Access Control: An access model that evaluates attributes from the user, resource, environment, or request before allowing an action. It is especially effective for delegated and agentic workflows because it can express narrow, condition-based permissions.
• Delegated Identity: An identity that acts on behalf of another principal and should only inherit the permissions needed for that specific task. For AI agents, delegated identity requires explicit scoping because tool use can easily exceed the user intent if authorization is not enforced at runtime.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: dynamic authorization for MCP servers and AI agents. Read the original.