Notifications
Clear all
Topic starter
20/08/2026 5:55 pm
TL;DR: Enterprise MCP adoption expands useful access to tools and data, but Obot argues that without enterprise-grade access control, organisations recreate SaaS sprawl, compliance gaps, and unsafe overreach across teams. The core issue is not protocol support alone, but whether OAuth 2.1, scoped authorization, and proxy enforcement can govern tool access before AI workflows scale.
NHIMG editorial — based on content published by Obot: enterprise access control for MCP servers and gateway-based enforcement
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern access to MCP registry-discovered servers?
A: Security teams should treat registry-discovered servers as governed non-human access, not as simple developer convenience.
Q: What breaks when MCP servers do not enforce tool scoping?
A: When MCP servers do not enforce tool scoping, models can reach tools and data across users, tenants, or environments that were never meant to be shared.
Q: How do teams know whether MCP controls are actually working?
A: Teams know MCP controls are working when every tool invocation can be traced to a verified identity, a policy decision, and a recorded approval state where required.
Practitioner guidance
- Centralise MCP access through an enterprise gateway Publish approved MCP servers through a single control plane that integrates with your existing identity provider and blocks unmanaged local servers from becoming shadow access paths.
- Separate server access from tool access Map groups and claims to specific MCP servers first, then apply finer-grained controls for read, write, and administrative tools inside each server.
- Enforce runtime token validation at the proxy Validate token signature, audience, expiry, and scope on every call before a resource server can be reached, and retain logs for audit and incident review.
What's in the full article
Obot's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on integrating MCP access with identity providers such as Okta, Entra, Google, and GitHub.
- Proxy enforcement details for validating token audience, scope, and expiry before resource access.
- Implementation patterns for mapping groups to specific MCP servers and tools.
- Operational examples of how the gateway supports discovery, logging, and compliance across teams.
👉 Read Obot's analysis of enterprise MCP access control →
MCP server access control: are your identity controls ready?
Explore further
20/08/2026 6:35 pm
MCP server access is now an identity governance problem, not a connectivity problem. The article makes clear that once MCP exposes enterprise systems, the real control question is who can reach which tools, under which claims, and through which identity provider. That shifts MCP from developer convenience into IAM and NHI governance territory, where central policy and auditability matter more than deployment speed. Practitioners should treat MCP as a governed access plane, not a simple integration layer.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably see where non-human access is actually living.
A question worth separating out:
Q: Who is accountable when an exposed MCP server is used to reach internal systems?
A: Accountability sits with the team that owns the delegated access path, the network exposure, and the identity controls around the server. In practice, that means security, platform, and application owners must all understand whether the MCP trust boundary is intentionally public or accidentally exposed.
👉 Read our full editorial: Enterprise access control for MCP servers: what practitioners need
