Notifications
Clear all
Topic starter
20/08/2026 5:39 pm
TL;DR: Docker, remote servers, and registry-based access control shape MCP server management, according to Obot’s deployment guide, with the vendor noting that production use favours Kubernetes and fine-grained team scoping. For IAM practitioners, the important issue is not setup convenience but how tool exposure, credentials, and policy boundaries are governed across shared AI access paths.
NHIMG editorial — based on content published by Obot: a guide to deploying and managing MCP servers with Docker and registries
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: What breaks when MCP servers are added without registry scoping?
A: Tool exposure expands faster than governance can track it.
Q: How do organisations decide between single-user, multi-user, and remote MCP servers?
A: Choose the server type that matches the identity and credential model you can actually govern.
Practitioner guidance
- Define a server-by-server trust model Classify each MCP server as single-user, multi-user, remote, or composite before onboarding it, then assign an owner for credentials, review cadence, and offboarding.
- Scope registry membership tightly Remove blanket exposure through the default everyone group where possible and map users and groups to the smallest server set needed for their role.
- Separate developer evaluation from production control Use Docker-based quick starts only for evaluation, then move production MCP workloads to containerised or otherwise governed runtimes with explicit dependency control.
What's in the full article
Obot's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Docker deployment commands and local setup sequence for the gateway.
- Hands-on instructions for connecting a DuckDuckGo MCP server and testing live queries.
- Manual configuration examples for adding a remote GitHub MCP server with authentication headers.
- YAML examples for defining MCP server entries in a GitOps workflow.
👉 Read Obot's guide to deploying and managing MCP servers →
MCP registries and server types: what changes for IAM teams?
Explore further
20/08/2026 6:23 pm
MCP registries are becoming the identity control point for AI tool access. The article shows that tool visibility, not just tool execution, determines whether MCP is governable in enterprise use. Registries map users and groups to server sets, which makes them function like a policy boundary for non-human access. That is exactly where IAM teams should anchor ownership, review, and segregation of duties.
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.
- A separate NHI benchmark shows that 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: Why do MCP deployments need IAM governance instead of just platform setup?
A: Because the real risk is not installation, it is uncontrolled tool reach. MCP servers expose capabilities, and IAM governance determines who can reach those capabilities, under what identity, and with what revocation path. That is why server catalog design, registry membership, and credential ownership all matter together.
👉 Read our full editorial: Obot's MCP deployment guide highlights registry-based access control
