TL;DR: Server-level MCP permissions overexpose read, write, and delete tools to users and agents that do not need them, according to Obot, so least privilege only works when authorisation is applied at the tool level rather than the server boundary. That shift turns registry design, OAuth scope management, and auditability into the practical control points for MCP governance.
At a glance
What this is: This is an analysis of why MCP access control fails at the server boundary and why tool-level authorisation is the real least-privilege control point.
Why it matters: It matters because IAM and NHI teams need to govern what a user or agent can actually do inside an MCP server, not just whether they can connect to it.
Context
Model Context Protocol access control becomes weak when teams treat the server as the unit of permission instead of the tool. A single MCP server can expose read, write and delete functions, so coarse access often gives users and agents more capability than their role requires.
The governance problem is not MCP connectivity itself. It is that identity and authorisation controls have to decide which specific functions a human user or AI agent may invoke, and that decision changes the practical design of registries, scopes, auditing and runtime policy.
For enterprise IAM and NHI programmes, this shifts MCP from a simple integration concern to a governed access model. Once agents can act on behalf of people, server-level approval no longer answers the question that matters most: what can this identity actually do?
Key questions
Q: Where do MCP client identity controls fail in practice?
A: They fail when servers trust fetched metadata without constraining egress, validating redirect URIs, or treating localhost callbacks as high risk. In that case, the identity model becomes easier to operate but not necessarily safer.
Q: Why do coarse MCP permissions increase operational risk?
A: They increase risk because the permission model no longer matches the action surface. A read-only workflow can still carry write or delete capability, so a compromised token or over-scoped agent can do more harm than the business process intended. That mismatch turns a routine integration into a broader governance and blast-radius problem.
Q: What are the signs that MCP authorisation is too coarse?
A: Warning signs include broad bearer tokens reaching internal services, the same scope covering many tools, approvals that never consider request context, and audit logs that show only login events instead of per-action decisions. If an authenticated agent can change behaviour without a fresh policy check, authorisation is too coarse.
Q: Who should own MCP registry decisions across engineering and security?
A: Ownership should sit with the platform or identity governance function, with security setting policy and engineering supplying operational metadata. If ownership stays informal, no one can manage registration, retirement, or approval drift consistently. The important test is whether the registry has named accountability and an enforceable lifecycle, not just a list of tools.
Technical breakdown
Why server-level MCP permissions break least privilege
Server-level permissioning collapses distinct actions into one access decision. In MCP, a server may expose read, update, delete and administrative tools behind a single connection point, which means a user who only needs visibility can inherit destructive capability as a side effect of server access. That is a classic least-privilege failure: the control boundary is too coarse for the action surface. Tool-level authorisation restores granularity by separating the identity that connects from the functions it may invoke.
Practical implication: Design access around individual MCP tools, not the server container that hosts them.
How registries and OAuth scopes become the control plane
Registries are the organising unit because they bind identity-provider groups to approved MCP servers and their permitted tool configurations. OAuth-based authentication then has to express scope at a finer level than the legacy API-key model, so tokens and claims map to specific functions rather than broad platform reach. This is where auditability improves too: if the registry defines the configured view, you can trace which identity was entitled to which tools and why.
Practical implication: Use registry design and granular OAuth scopes to make tool entitlements explicit and reviewable.
Why agent-scoped composites reduce blast radius
An agent rarely needs every tool a human owner can access, especially when the agent is scheduled or event-driven and no person reviews each call in real time. Composite or virtual MCP servers let teams assemble a purpose-built tool set for that task, limiting both the agent's scope and the damage from a compromised token. This matters because an agent with excessive tools turns a routine workflow into an unnecessary exposure channel for data modification, deletion and leakage.
Practical implication: Give each agent only the tools required for its task and nothing else.
Threat narrative
Attacker objective: The objective is to turn broad MCP access into unnecessary data modification or deletion power, increasing the blast radius of a compromised or over-scoped identity.
- Entry occurs when a user or agent receives broad server-level MCP access that exposes more tools than the task requires.
- Privilege escalation happens when the same connection grants write and delete capability even though the intended use case is read-only or narrowly scoped.
- Impact follows when an agent or compromised identity uses those overexposed tools to modify, delete or leak data beyond its legitimate role.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Tool-level authorisation is now the real least-privilege boundary for MCP. Server-level access was acceptable when integrations were simpler, but MCP exposes mixed-risk toolsets behind one endpoint. That means identity teams have to govern the function, not just the connection, if they want least privilege to mean anything in practice. The practitioner conclusion is straightforward: access policy must follow tool semantics.
Registry design is becoming an identity governance problem, not just an integration pattern. When a registry defines which tools a group or agent can see, it becomes part of the authorisation model and the audit trail. That changes ownership from application teams alone to IAM, IGA and platform security working from one entitlement source. The practitioner conclusion is to treat registries as governed access objects.
Composite MCP servers are a blast-radius control, not a convenience feature. Purpose-built tool bundles prevent agents from inheriting human-level entitlements they do not need. This matters most for scheduled or event-driven agents, because no human approval step will correct over-scoping before execution. The practitioner conclusion is to scope agents to task-specific composites, not full user registries.
MCP token management and tool governance now intersect at the same control point. OAuth scopes, token handling and tool exposure are no longer separable design choices when agents can act on behalf of users. A token that authenticates too broadly effectively becomes a hidden privilege carrier across tools. The practitioner conclusion is to align scope, registry membership and audit logging as one control chain.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Tool-level governance is the control shift MCP programmes now need. Server-level access answers connectivity, but it does not answer entitlement. Identity teams should expect MCP governance to move toward configured views, per-tool scopes and audit trails that can explain not just who connected, but which function they invoked and why.
Registry sprawl will become the practical IAM bottleneck if it is not normalised early. Once multiple business units start publishing their own MCP servers, entitlement drift follows unless registry ownership, scope templates and review cadence are centralised. The programme risk is not technical complexity alone; it is inconsistent authorisation semantics across the environment.
Blast radius is the metric to watch as agentic MCP use expands. When an agent can call only the tools tied to its task, compromise stays contained; when it inherits full server access, compromise becomes a data modification problem immediately. That distinction should guide policy design, scope review and logging priorities.
For practitioners
- Define tool-level entitlements Map each MCP tool to a specific role or claim and remove destructive tools from any default server view that does not explicitly need them.
- Refactor registries around business roles Group MCP servers into configured views for analysts, admins and agents so registry membership reflects job function rather than whole-server access.
- Scope autonomous agents to composites Build composite MCP servers for agent tasks so scheduled or event-driven agents can call only the tools required for that workflow.
- Audit tool calls and scope drift Record every tool invocation, then compare live usage against assigned scopes to identify tools that remain enabled but unused or inappropriate.
Key takeaways
- Server-level MCP access is too coarse to enforce least privilege when one server exposes read, write and delete tools together.
- The governance problem is the entitlement model, not the protocol itself, because tool-level scopes and registries decide real capability.
- Agent-scoped composite servers and audit logs reduce blast radius by aligning each identity with the tools it actually needs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Server-level MCP access overexposes tool capability beyond role need. |
| NHI-04 — Insecure Authentication | MCP access depends on OAuth and token handling across registries and agents. | |
| NHI-07 — Long-Lived Secrets | The article contrasts modern OAuth controls with older token practices and agent exposure. | |
| Recommendation — Restrict MCP tool exposure to the minimum role required and remove unnecessary write or delete functions. Bind MCP authentication to scoped tokens and reject broad credentials that exceed the configured tool set. Prefer short-lived OAuth tokens and eliminate persistent credentials from MCP integrations. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents can inherit broader tool rights than their task requires. |
| Recommendation — Constrain agent tool sets so runtime privilege cannot exceed the task-specific entitlement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about entitlement granularity and access decisions. |
| Recommendation — Apply PR.AA-05 to validate MCP entitlements at the tool level, not just the server level. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the core control principle being reinterpreted for MCP tool access. |
| Recommendation — Enforce AC-6 by limiting each identity to only the MCP tools required for its assigned task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Over-scoped tokens and tool exposure increase the blast radius after compromise. |
| Recommendation — Map broad MCP access to TA0006 and TA0008 so hunting focuses on token abuse and downstream movement. | ||
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 Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
- Composite MCP server: A composite MCP server is a single Model Context Protocol endpoint that exposes multiple tools, resources, or data sources through one interface. It aggregates capabilities from several back-end systems and presents them to an AI agent as a unified tool layer, while still requiring careful control of authentication, authorization, logging, and data boundaries.
- Registry-based access: A permission model where MCP server access is assigned through a registry mapped to IdP groups rather than hardcoded into each server. It makes least privilege, review, and offboarding easier to apply consistently across many tools and deployments.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org