Fine-grained MCP access control needs tool-level least privilege

At a glance

What this is: This is an analysis of why MCP access control must move from server-level permissions to tool-level governance, because server boundaries overgrant read, write, and destructive capabilities.

Why it matters: It matters because IAM, IGA, and PAM teams need a way to answer what users and agents can actually do inside MCP-connected systems, especially as OAuth-based access and autonomous tool use expand.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Obot's analysis of fine-grained MCP access control and tool-level least privilege

Context

MCP access control is the discipline of deciding which identities can invoke which tools, not just which server they can reach. The article argues that server-level access is too coarse because a single MCP server can bundle safe, sensitive, and destructive actions under one boundary, which breaks least privilege for both human users and AI agents.

That matters for enterprise identity programmes because the control problem is no longer just authentication into an MCP server. It is authorization at the tool, registry, and agent scope, with OAuth tokens, IdP groups, and runtime policy all shaping what the identity can actually do.

The same governance challenge appears across NHI and agentic AI environments: if the identity is over-scoped at the container or server boundary, downstream actions inherit that excess. In practice, that widens blast radius, weakens audit clarity, and makes it harder for IAM teams to explain entitlement decisions in a review or incident.

Key questions

Q: What breaks when MCP tool access is not default-deny?

A: Tool discovery and invocation become open-ended privilege expansion paths. Without default-deny controls, teams cannot reliably prove which tools an agent can reach, which scopes were granted, or whether those calls were logged in a way that supports audit and incident review.

Q: Why do MCP registries matter for identity governance?

A: Registries let security teams assign approved tool sets through identity-provider groups rather than hand-built per-server exceptions. That makes entitlement review, role changes, and access revocation manageable through existing IAM processes. Without registries, MCP permissions become fragmented and difficult to certify consistently.

Q: How can security teams reduce the blast radius of AI agents using MCP?

A: Security teams should give each agent a composite server containing only the tools needed for its task, then log every invocation and review any destructive capability separately. This prevents a narrow workflow from inheriting broad server reach and limits the damage if the agent’s token, prompt, or context is compromised.

Q: Who should own MCP access governance in an enterprise?

A: Ownership should sit with identity and security teams, not only application developers, because MCP connects user intent to privileged execution. The governing team needs authority over policy design, review cadence, and audit evidence. That keeps MCP aligned with enterprise authorization standards rather than ad hoc server behaviour.

Technical breakdown

Why server-level MCP permissions overgrant access

MCP servers often expose multiple tools through one authenticated entry point. If a user is granted access to the server, they inherit every tool behind it, including read, write, update, and delete actions. That collapses authorization into a single binary decision and ignores function-level risk. In identity terms, the server becomes a coarse entitlement container rather than a policy boundary. For AI agents, the problem is worse because tool invocation can happen at runtime without a human checking each call, so over-scoped access immediately expands the agent’s effective privilege set.

Practical implication: Practitioners should treat the server as a transport boundary and enforce authorisation at the tool layer, not the server layer.

How registries and IdP groups shape MCP authorization

A registry maps approved MCP servers and tool configurations to identity-provider groups, so assignment follows identity governance rather than ad hoc configuration. This is where enterprise control becomes manageable: business roles map to specific tool sets, and registry membership determines visibility. The mechanism is important because it lets security teams centralize policy while reducing manual per-server exceptions. It also creates a cleaner audit trail, since access can be traced back to group membership, claims, and the tools made available to that identity.

Practical implication: Security teams should anchor MCP authorization in IdP-managed registries and review those mappings as part of role and entitlement governance.

Why composite MCP servers reduce agent blast radius

A composite or virtual MCP server assembles only the tools a specific agent needs, instead of exposing an entire upstream registry. That matters because an agent performing a narrow task, such as report generation, does not need delete permissions or broad association management. By constraining the tool set, the organization limits what a compromised token, prompt injection event, or mistaken action can reach. This is not just a convenience pattern. It is a privilege-scope reduction pattern that aligns the agent’s runtime capability with its actual job function.

Practical implication: Build agent-specific composites for high-risk workflows so one agent cannot inherit the full reach of a shared MCP server.

Threat narrative

Attacker objective: The objective is to gain broad operational reach through an MCP identity that can modify or delete data beyond its intended role.

1. Entry occurs when a user or AI agent is granted server-level MCP access that includes more tools than the task requires.
2. Escalation follows when the identity can invoke write or destructive tools that should have been excluded from its runtime scope.
3. Impact is unauthorized record changes, deletions, data leakage, or broader privilege exposure through over-scoped OAuth tokens and tool access.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Server-level MCP access is an identity anti-pattern, not a safe starting point. Once a server bundles read, write, and destructive tools, the access boundary stops reflecting actual risk. Least privilege cannot be evaluated at the server layer because the entitlement now includes functions with radically different blast radii. The practical conclusion is that MCP governance must be expressed in tool terms, not platform terms.

Fine-grained MCP authorization is where identity governance meets runtime control. Registry assignment, IdP group membership, and scoped OAuth tokens are only useful if they resolve to the specific actions an identity can invoke. That makes tool classification, claim mapping, and policy enforcement the real control surface. IAM teams should treat MCP permissions as an entitlement graph, not a single access grant.

Composite servers are the right abstraction for agent-specific privilege containment. The article makes clear that a weekly reporting agent should not inherit the same tool set as the human or team that owns it. That is a classic NHI pattern: the executor is narrower than the account context around it. The result is smaller blast radius, clearer audit scope, and less chance that a compromised token turns into data destruction.

Registry sprawl creates governance debt unless ownership is explicit. If platform teams define the registries and business teams request changes, the organisation at least preserves accountability. Without that split, tool availability becomes an unmanaged entitlement issue that bypasses normal access review. The implication for practitioners is that MCP governance should sit inside existing identity review and approval workflows, not beside them.

Tool-level warnings and naming hygiene are governance controls, not interface polish. Renaming ambiguous tools and flagging destructive actions improves both human decision-making and audit interpretation. That matters because modern identity programmes fail when people cannot tell whether a given action is informational or destructive. The named concept here is tool-level least privilege: the specific practice of constraining every MCP identity to only the functions it truly needs.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the same research.
• For practical lifecycle guidance, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding discipline.

What this signals

Tool-level least privilege will become the default expectation for MCP governance as organisations move from pilot deployments to production identity controls. Server-level access may still be acceptable for experimentation, but it will not survive scrutiny once teams need to explain who can delete data, who can write records, and which agent can act without review.

With only 5.7% of organisations having full visibility into their service accounts, the governance challenge is already familiar: identity teams struggle when the unit of control is too coarse. MCP extends that problem into runtime tool use, so the next maturity step is to treat tool exposure, registry assignment, and audit logging as a single control plane.

Practitioners should also watch for the same patterns that have shaped secrets and OAuth governance: scope creep, lifecycle drift, and over-broad reuse of credentials. The discipline that works is the same across human, NHI, and agentic workflows. The implementation details differ, but the accountability model does not.

For practitioners

• Split server access from tool authorization Map every exposed MCP tool to a risk tier and remove destructive actions from broad server grants. If a user needs only read operations, make write and delete tools invisible rather than merely discouraged. This keeps the access boundary aligned to actual use.
• Tie registries to IdP group membership Use identity-provider groups as the control point for registry assignment so role changes flow through existing JML and recertification processes. That gives you a single entitlement source of truth and avoids one-off manual grants that drift over time.
• Build composite servers for agents Create agent-specific composites that include only the tools needed for a single workflow, such as reporting or enrichment. Do not let an autonomous or semi-autonomous agent inherit the full tool catalogue of its parent server.
• Log tool invocation, not just login events Capture the tool name, parameters, timestamps, and the identity context behind each invocation. Login logs alone cannot explain whether a registry grant led to read-only activity or a destructive action.
• Review destructive tools as privileged access Treat delete, bulk update, and association-management tools as privileged functions that require explicit approval and periodic review. If a tool can change business records at scale, it belongs in the same governance lane as other high-risk access.

Key takeaways

• MCP server-level access is too coarse because it exposes mixed-risk tools under one entitlement.
• The governance problem is not just authentication, but tool-level authorisation, registry ownership, and auditability.
• Composite servers and IdP-linked registries give practitioners a practical way to shrink agent blast radius and align access with actual task scope.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool-level least privilege: A permission model that grants access to individual tools rather than broad platform-wide capabilities. In MCP environments, this reduces blast radius by ensuring a server or agent can only invoke the specific actions needed for its task, not everything the platform can reach.
• AppSec MCP Server: A context-sharing interface that connects application security tools, IDEs, CI pipelines, and policy systems through the Model Context Protocol. In practice, it helps security functions exchange state and guidance in a form that can support automation and inline developer assistance.
• IdP-mapped authorization: IdP-mapped authorization ties MCP tool exposure to identity-provider groups, claims, and role assignments. It reduces manual configuration drift by making access decisions part of the existing identity lifecycle rather than a separate integration layer.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• A concrete registry design pattern for mapping IdP groups to MCP tool bundles.
• Step-by-step examples of tool-level filtering for read, write, and destructive actions.
• Guidance on composite server construction for autonomous agents and shared workflows.
• Operational notes on OAuth 2.1, token handling, and audit logging in enterprise MCP deployments.

👉 Obot's full post covers registry design, composite server patterns, and enterprise OAuth scope decisions.

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.