Obot’s MCP deployment guide highlights registry-based access control

At a glance

What this is: This is a practical guide to deploying Obot for MCP server access, with the key finding that server type, runtime choice, and registries determine how much tool exposure each user or team receives.

Why it matters: It matters because MCP is becoming an identity-controlled access layer for AI-driven tooling, and IAM teams need to govern who or what can reach external tools, with what credentials, and under which registry scope.

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.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's guide to deploying and managing MCP servers

Context

MCP server deployment is not just an application setup problem. It is an identity and access problem because each server exposes a tool surface that must be scoped, authenticated, and governed before AI workflows can use it safely. In practice, the question is whether the platform is operating as a controlled access layer or as a convenience wrapper around uncontrolled credentials.

This guide focuses on Obot’s deployment, server types, runtime options, and registry model. For teams already managing service accounts, secrets, and tool access, the useful lens is how MCP server boundaries map to existing IAM, PAM, and NHI governance models. The same governance gap appears whether the server is hosted locally, connected remotely, or shared across a team.

The article also makes clear that production use should move beyond quick evaluation patterns. That is typical of MCP adoption: simple demos are easy, but durable governance depends on how access is partitioned, how credentials are supplied, and how server visibility is restricted across users and groups.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

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: 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. Single-user servers fit individual credentials, multi-user servers suit shared access with central control, and remote servers require stronger gateway oversight because execution happens outside the local runtime boundary.

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.

Technical breakdown

MCP server types and access boundaries

Obot’s four server types, single-user, multi-user, remote, and composite, represent different trust and credential models. Single-user servers tie access to an individual credential set, while multi-user servers centralise access and therefore increase the need for strong lifecycle and audit controls. Remote servers proxy calls to external systems, which means the gateway becomes part of the enforcement path. Composite servers reduce tool exposure by presenting a curated subset, which is useful when teams need least-privilege access to a larger server estate.

Practical implication: classify each MCP server by trust model before onboarding it, then align credential ownership and review frequency to that model.

Runtime environments and hosting control

Obot supports Node.js, Python, and container-based runtimes, but the security characteristics are not equivalent. Container-based MCP servers package dependencies and can make runtime state more predictable, which helps reduce drift and hidden dependency risk. Docker socket access, however, creates a strong local control requirement because the gateway can manage containers directly. That means runtime convenience and runtime authority sit together, and the operator has to decide whether the deployment boundary is developer convenience or enterprise control.

Practical implication: treat containerised MCP hosting as an infrastructure trust decision, not just a packaging choice.

GitOps and registry-based MCP governance

GitOps for MCP server definitions introduces version control, drift detection, and auditable change history for tool exposure. Registries then apply the access policy layer by deciding which servers are visible to which users and groups. That combination is more important than the setup wizard because tool visibility is identity governance in practice. If the registry model is too broad, users inherit tool access they do not need. If it is too loose, the gateway becomes a discovery mechanism for privileged tools rather than a control point.

Practical implication: manage MCP definitions and registry membership as governed identity artefacts, not ad hoc admin settings.

NHI Mgmt Group analysis

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.

Server type selection is an NHI governance decision disguised as deployment convenience. A single-user server, a shared remote server, and a composite server each imply different credential ownership and access review patterns. The practical implication is that platform teams cannot standardise on one onboarding pattern and assume it fits all trust models. They need to align server type with the lifecycle of the underlying identity.

Composite access creates a useful named concept: tool-exposure minimisation. The value of a composite server is not just simplification, it is limiting the tool surface exposed to the identity using it. That matters because AI-driven access paths tend to expand once users can reach a broad registry or a full remote server catalog. Teams should treat curated toolsets as a governance boundary, not just a UX feature.

Production MCP should be evaluated as part of the wider NHI lifecycle, not as a standalone gateway problem. The guide points toward registry governance, runtime selection, and server onboarding, but the unresolved question is who owns provisioning, rotation, and offboarding for each server credential and API token. That lifecycle gap is where MCP adoption usually outpaces control design. Practitioners should fold MCP into existing NHI governance rather than creating a separate exception process.

The field is moving toward policy-mediated AI tool access, and that increases the burden on identity architecture. MCP gateways sit between agents and enterprise tools, so they inherit the accountability expectations normally associated with access brokers and privileged gateways. That means teams need logging, access scoping, and revocation paths that are measurable, not assumed. The architecture is workable only when identity controls are built into the gateway boundary from the start.

From our research:

• 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.
• For a lifecycle lens on why this matters, NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding should be governed across machine identities.

What this signals

Tool-exposure minimisation: MCP adoption will increasingly be judged by how narrowly teams can expose tools to users, groups, and downstream automations. The registry model is useful only if it becomes part of the access review process, not a static configuration list.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, the next governance failure will be credential reuse across MCP servers, remote endpoints, and development environments. Teams should expect the boundary between application configuration and identity governance to narrow quickly.

The practical path is to fold MCP into existing NHI lifecycle and access control workflows, then reference the OWASP Non-Human Identity Top 10 where server credentials, tokens, and registry membership create persistent access paths.

For practitioners

• 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.
• Treat MCP definitions as governed identity artefacts Store server entries, environment variables, and registry assignments in version control so drift, changes, and access expansion can be reviewed like any other access change.
• Review tool exposure after every registry change Reassess which tools become reachable whenever a server, group, or remote endpoint is added to a registry, because access scope changes often outpace approval workflows.

Key takeaways

• MCP server management is an identity governance problem because server type, credential model, and registry scope determine who can reach which tools.
• The weakest point in most deployments is not deployment speed, it is access scoping, since only 18% of MCP server deployments apply any form of tool permission scoping.
• Teams should govern MCP servers like other NHI assets, with lifecycle ownership, version-controlled definitions, and narrow registry membership.

Key terms

• MCP Server Registry: A registry is the policy layer that decides which MCP servers are visible to specific users or groups. In practice, it turns tool discovery into an access control problem and should be governed like any other identity mapping or entitlement source.
• AppSec MCP Server: A context-sharing interface that connects application security tools, IDEs, CI pipelines, and policy systems through the Model Context Protocol. In practice, it helps security functions exchange state and guidance in a form that can support automation and inline developer assistance.
• 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.

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.

👉 The full Obot guide covers the Docker flow, registry setup, and MCP server configuration steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.