MCP servers at scale: what governance gaps are teams missing?

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

View Full Forum →  |  NHI Foundation Course →