Notifications
Clear all
Topic starter
20/08/2026 5:42 pm
TL;DR: MCP adoption is already spreading inside enterprises through unmanaged developer usage, scattered credentials, and no audit trails, according to Obot. The identity problem is not whether MCP will be used, but whether organisations centralize control before shadow IT turns tool access into an ungoverned non-human identity estate.
NHIMG editorial — based on content published by Obot: centralized MCP hosting and governance for AI-connected tools
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 servers create new identity governance requirements?
A: MCP servers expose non-human access to tools and data through agent-driven workflows, so basic login is not enough.
Q: What breaks when MCP usage is left unmanaged?
A: Visibility breaks first, then accountability, then revocation.
Practitioner guidance
- Inventory every MCP endpoint as an identity-bearing asset Build a register of MCP hosts, clients, credentials, and upstream systems.
- Centralise authentication and token exchange at a gateway Route MCP access through a single control point so raw credentials never reach end users.
- Classify integrations by data sensitivity before choosing hosting Keep regulated or high-impact systems under self-hosted control where data residency, segmentation, and latency matter.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step deployment guidance for self-hosted MCP servers in Docker and Kubernetes
- Specific trade-offs between self-hosted, remote, and serverless hosting models
- Operational examples of gateway-based proxying, audit logging, and token handling
- Practical guidance on when to migrate from remote hosting to self-hosting as usage matures
👉 Read Obot's guide to centralized MCP hosting and gateway control →
MCP hosting and shadow IT: what identity teams need to do?
Explore further
20/08/2026 6:26 pm
Centralised MCP management is now a non-human identity governance requirement. Once developers begin using MCP servers at scale, every endpoint becomes a governed access path into internal or third-party systems. The governance question is no longer whether AI clients can reach tools, but whether those tool connections are provisioned, scoped, logged, and revoked like any other NHI. Organisations that treat MCP as an experiment rather than an identity layer will miss the control point that matters most.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to OWASP Agentic AI Top 10.
- A second signal comes from the same research set: 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: Should organisations self-host or proxy MCP servers?
A: Use self-hosting for sensitive, regulated, or latency-critical integrations where you need control over data and credentials. Use proxying for lower-risk SaaS connections and early experimentation. Most enterprises will need a hybrid model, but only if a gateway preserves one policy and logging standard across both paths.
👉 Read our full editorial: Centralized MCP hosting is now an identity governance problem
