Notifications
Clear all
Topic starter
20/08/2026 5:24 pm
TL;DR: MCP makes it easy to connect AI clients to real tools, but Obot argues the hard part is management: OAuth handling, access control, discovery, audit logging, and ownership once servers spread across teams. That governance debt is already showing up as a scaling problem for IAM and security programmes.
NHIMG editorial — based on content published by Obot: Managing MCP servers at scale
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 MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP tools create a governance problem for IAM teams?
A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login.
Q: What breaks when MCP tool permissions are scoped too broadly?
A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.
Practitioner guidance
- Inventory shadow MCP servers Identify every MCP server already running in development, testing, and production, then map each one to an owner, data touchpoints, and the AI clients that can reach it.
- Centralise OAuth and token revocation Remove per-server token handling where possible and move to a controlled layer that manages callback URLs, refresh, and immediate revocation from one place.
- Enforce tool-level scoping by role Tie server access to existing identity groups so users only see and invoke the tools that match their function, with no broad default access.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- A practical MCP management maturity model that shows what changes from shadow adoption to enterprise scale.
- The Obot Gateway architecture for central OAuth handling, tool-level access control, content filtering, and audit logging.
- The Obot Catalog approach to discovery and reuse across 70+ enterprise integrations.
- Deployment and hosting considerations for cloud and on-premises Kubernetes environments.
👉 Read Obot's full guide to managing MCP servers at scale →
MCP servers at scale: what governance gaps are teams missing?
Explore further
20/08/2026 6:14 pm
MCP governance is becoming an NHI problem before most organisations recognise it as one. The moment an MCP server is used by an AI client, it becomes part of the non-human identity estate, complete with authentication, access scope, and revocation requirements. The governance challenge is not the protocol itself but the spread of machine-to-machine access that slips past traditional application ownership. Practitioners should treat MCP as an identity surface, not just an integration layer.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do organisations know whether MCP is becoming shadow infrastructure?
A: Look for servers that are used regularly but not visible in a central catalog, owned informally, or authenticated through per-team workarounds. If users must ask around to find tools or if revocation requires manual chasing, the platform has already moved beyond controlled deployment.
👉 Read our full editorial: MCP management needs governance, access control, and ownership
