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.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “Fine-Grained MCP Access Control: Beyond Server-Level Permissions”.
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.
Q: Why do coarse MCP permissions increase operational risk?
A: They increase risk because the permission model no longer matches the action surface.
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.
Practitioner guidance
- 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.
Bottom line: Server-level MCP access is too coarse to enforce least privilege when one server exposes read, write and delete tools together.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:32 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Fine-grained MCP access control needs tool-level least privilege