Notifications
Clear all
Topic starter
19/08/2026 3:56 pm
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.
NHIMG editorial — based on content published by Obot: Fine-Grained MCP Access Control: Beyond Server-Level Permissions
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.
Questions worth separating out
Q: What breaks when MCP tool access is not default-deny?
A: Tool discovery and invocation become open-ended privilege expansion paths.
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.
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.
Practitioner guidance
- Split server access from tool authorization Map every exposed MCP tool to a risk tier and remove destructive actions from broad server grants.
- 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.
- Build composite servers for agents Create agent-specific composites that include only the tools needed for a single workflow, such as reporting or enrichment.
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.
👉 Read Obot's analysis of fine-grained MCP access control and tool-level least privilege →
MCP tool-level least privilege: are your controls keeping up?
Explore further
19/08/2026 4:32 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Fine-grained MCP access control needs tool-level least privilege
