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.
At a glance
What this is: Obot’s guide explains MCP deployment and shows that registry-based access control is the governing lever for separating users, groups, and tool exposure across server types.
Why it matters: IAM teams should treat MCP registries as an access governance layer, because server sprawl, shared credentials, and mixed deployment patterns can quickly blur who can use which tools.
Context
MCP deployment becomes an identity governance problem as soon as multiple users, tools, and runtime patterns share the same gateway. In this guide, Obot moves from installation to operational control by showing how server type, runtime choice, and registry membership determine tool exposure.
The practical issue is not whether an MCP server can be connected, but whether its credentials, policies, and user scope remain separable once it is added to a shared platform. That makes registries, server classification, and deployment model part of the IAM conversation, not just the platform setup conversation.
For teams building AI-enabled access pathways, the distinction between local, remote, multi-user, and composite servers matters because each changes where trust boundaries sit and who can inherit them. The article is typical of production guidance that starts with convenience and quickly becomes a governance discussion.
Key questions
Q: What breaks when MCP servers are added without registry scoping?
A: Tool exposure expands faster than governance can track it. Without registry scoping, users can discover and connect to servers they do not need, which undermines least privilege and weakens accountability for tool use. In practice, the gateway becomes a visibility layer instead of an access control layer.
Q: When should teams prioritise Kubernetes over Docker for MCP hosting?
A: Teams should prioritise Kubernetes when MCP servers move beyond evaluation and begin serving shared or production workloads. Kubernetes gives a stronger base for repeatability, isolation, and operational control, while Docker is better suited to local testing and developer use cases.
Q: What do security teams get wrong about MCP and tool governance?
A: They often review each integration in isolation and miss the combined permission path. Two legitimate tools can create a new capability that neither one should have alone. Governance has to assess the full chain of action, because risk emerges from composition as much as from individual access rights.
Q: How should IAM teams govern remote MCP servers?
A: Remote MCP servers should be treated as externally hosted access paths that need explicit scoping, credential handling, and server-level visibility rules. If the gateway only proxies requests, the governance model must still define who can see the server, who can connect to it, and what identity context is passed through.
Technical breakdown
How MCP server types change the trust boundary
Obot describes four server types: single-user, multi-user, remote, and composite. The technical distinction is where authentication state lives and how tool calls are mediated. Single-user servers bind one instance to one user credential set, while multi-user servers centralise credentials or rely on OAuth. Remote servers shift execution outside the gateway and composite servers aggregate toolsets into a narrower interface. In identity terms, each model changes whether the gateway brokers access, proxies an external identity, or simply exposes a pre-existing service boundary.
Practical implication: Map each MCP server type to a distinct access model before adding it to a shared environment.
Registry-based access control for MCP exposure
Registries in Obot act as the administrative mapping between users, groups, and the servers those groups can see. That makes the registry the policy layer that determines discovery, not just execution. The important technical point is that visibility and usability are being governed together: if a server is not present in a registry, it is effectively outside that user's operational surface. This is a familiar identity control pattern applied to tool catalogs rather than applications.
Practical implication: Treat registry membership as a governed entitlement and review it with the same discipline as application access.
Why Docker and Kubernetes imply different governance models
The guide positions Docker as appropriate for individual developers and quick evaluation, while Kubernetes is recommended for production. That difference matters because the deployment substrate affects isolation, repeatability, and policy enforcement. Docker-based local hosting often concentrates credentials and runtime state on a single machine, whereas Kubernetes more naturally supports structured operations, configuration drift management, and scale. The technical choice is therefore also a governance choice about how repeatable and inspectable the MCP environment will be.
Practical implication: Use the runtime model to decide how much operational control you need before exposing MCP tooling beyond a pilot.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Registry-scoped MCP access is the real governance control here: Obot's guide makes clear that the registry, not the chat interface, determines which users can discover and use which servers. That turns tool exposure into an entitlement problem, which is exactly where IAM teams need to focus. The practical implication is that AI access paths should be governed as scoped services, not as informal extensions of developer convenience.
Server type is a policy boundary, not just a deployment label: Single-user, multi-user, remote, and composite MCP servers each imply different trust assumptions about credential ownership and request routing. Those differences matter because the same tool can be materially safer or riskier depending on whether credentials are user-bound, centrally held, or proxied through a gateway. Practitioners should align server type with the least expansive identity model that still supports the use case.
Composite servers represent a useful narrowing pattern for tool exposure: The guide's description of composite servers points to a familiar governance need, exposing only a curated subset of tools rather than a full upstream surface. That is important in AI-enabled environments because every additional tool expands the effective blast radius of a connected identity. The practitioner takeaway is to prefer bounded toolsets where the business process does not require broad tool reach.
MCP deployment is beginning to look like NHI lifecycle management: The article centres on credentials, server registration, team scoping, and runtime placement, all of which are lifecycle questions in disguise. The named concept here is MCP access boundary drift: the gap that appears when servers, credentials, and registry membership change independently. IAM teams should treat that drift as a standing governance risk, not as an implementation detail.
Production guidance is converging on policy-backed orchestration rather than ad hoc tool hookup: Obot's move from local Docker deployment to registry-managed server access reflects where the category is heading. The market signal is that MCP environments are being treated less like isolated integrations and more like governed access fabrics. Teams should expect more pressure to formalise tool onboarding, entitlement review, and runtime segregation as adoption grows.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
MCP access boundary drift: The main governance risk in this pattern is that server registration, credential ownership, and team visibility can change independently. When that happens, the gateway still looks orderly while the actual access surface quietly expands.
Registry-scoped access is the right mental model for MCP environments because discovery is itself an entitlement. Once teams can see and connect to shared servers, the question becomes who is authorised to inherit which tool paths, not simply who can log in.
MCP deployment also creates a new offboarding burden, because removing a user from a team is not enough if server entries, shared credentials, or remote endpoints remain reachable. IAM programmes need a lifecycle view that covers server onboarding, registry assignment, and server removal together.
For practitioners
- Define server-type boundaries Classify each MCP server as single-user, multi-user, remote, or composite before onboarding it into a shared environment. Use that classification to decide whether credentials are user-bound, centrally managed, or proxied through a gateway.
- Govern registry membership Review registry assignments as entitlements, not convenience lists. Remove broad default groups where teams need tighter scoping and keep user-to-server mappings aligned with least access.
- Separate production from evaluation runtime Use Docker for local testing and Kubernetes for production hosting when the server will serve multiple users or teams. The runtime should match the needed level of isolation, drift control, and operational repeatability.
- Limit composite server surfaces Expose only the subset of tools required for the workflow, and avoid publishing the full upstream server surface when a narrower virtual server will do the job.
- Document credential handling per server For each server, record where the credential lives, who can supply it, and whether it is sensitive, shared, or user-specific. That documentation is the basis for access review and offboarding.
Key takeaways
- MCP server management becomes an identity governance issue once server type, registry membership, and shared credentials define who can reach which tools.
- The article shows that access control in MCP is not only about login, but about discovery, visibility, and team-scoped server exposure.
- IAM teams should govern MCP registries, server types, and runtime placement as part of one access model rather than treating them as separate setup steps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Remote and registry-managed MCP servers create third-party access paths that must be governed. |
| NHI-05 — Overprivileged NHI | Registry scoping determines whether MCP tool access is narrowly bounded or overbroad. | |
| NHI-10 — Human Use of NHI | Users enter credentials to reach MCP-backed tools, making human interaction with NHI controls central. | |
| Recommendation — Apply third-party NHI controls to remote MCP servers before exposing them to shared users. Review MCP registry assignments for excess tool exposure and reduce server visibility to least privilege. Separate user-entered credentials from shared server credentials and document who can supply each one. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP registries are an entitlement control that governs who can discover and use tools. |
| Recommendation — Map MCP registries to PR.AA-05 and recertify server access as an entitlement. | ||
| NIST Zero Trust (SP 800-207) | least privilege — Least Privilege | The guide's scoped server exposure aligns with zero-trust minimisation of access paths. |
| Recommendation — Apply least-privilege principles when assigning users and groups to MCP servers. | ||
Key terms
- Mcp Registry: An MCP Registry is a catalog that lists available Model Context Protocol servers, tools, and resources for AI agents to discover and use. It typically stores metadata such as endpoints, capabilities, ownership, and trust information, helping organizations govern which tools agents can access and how those connections are managed.
- Composite MCP server: A composite MCP server is a single Model Context Protocol endpoint that exposes multiple tools, resources, or data sources through one interface. It aggregates capabilities from several back-end systems and presents them to an AI agent as a unified tool layer, while still requiring careful control of authentication, authorization, logging, and data boundaries.
- Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.
- Server-Type Scoping: Server-type scoping is the practice of assigning different governance rules to single-user, multi-user, remote, and composite MCP servers. It matters because each type changes where credentials live, who can use them, and how much of the tool surface is exposed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org