TL;DR: AI agents are already connecting to production systems through Model Context Protocol, and Stacklok argues that without a registry, teams lose visibility into who invoked which server, what it accessed, and what credential reached downstream resources. The real issue is governance, not convenience: ungoverned MCP deployments turn tool access into an audit blind spot and breach path, with no stable control plane for identity, attestation, or blast-radius limits.
At a glance
What this is: This is a how-to guide arguing that local MCP deployments need registry governance because ungoverned tool access creates audit and breach exposure.
Why it matters: IAM, NHI, and platform teams need a clear approval and authorization layer for MCP because tool calls can carry credentials, access production systems, and bypass existing governance assumptions.
Context
MCP gives AI applications a standard way to reach external tools and data sources, but the access pattern is only as governable as the control plane behind it. When servers are pulled from repositories or package registries and credentials are stored locally, the identity layer becomes fragmented before security teams can apply approval, attestation, or lifecycle controls.
The core governance gap is not the protocol itself. It is the absence of a registry that can answer who is invoking which server, what that server can reach, and which downstream credential is being used on each request. In NHI terms, that is an uncontrolled delegation chain with no stable inventory, no reliable offboarding, and no bounded blast radius.
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: Why do MCP deployments create risk before production rollout?
A: Because the highest-risk controls are often still being designed when teams start experimenting. Pre-production servers tend to lack formal review, consistent authorization, and logging, so the organisation is already extending trust to model-driven access before it has established the rules that govern that access.
Q: What signs show that MCP access is being governed properly?
A: You should be able to see per-request logs, known server ownership, explicit approval records, and a clear mapping from user to downstream credential. If any of those are missing, the MCP environment is functioning as a convenience layer rather than a controlled identity boundary.
Q: Should security teams approve MCP servers from public package sources without attestation?
A: No. If a server reaches internal systems, provenance becomes a security requirement, not a preference. Teams should require attestation, signing, and change control before approval, because unverified code can embed hidden access paths and credential handling behaviour.
Technical breakdown
Why local MCP needs a registry control plane
MCP standardises how AI applications call external tools, but the protocol does not by itself define enterprise-grade governance. A registry becomes the authoritative layer for inventory, approval, and policy enforcement across servers, users, and downstream resources. Without it, teams end up with disconnected local configurations, shared access paths, and no durable record of which agent or user initiated a tool call. That breaks the basic identity assumptions behind access review, auditability, and scoped delegation. A registry is therefore less about convenience and more about restoring control over who can invoke what, from where, and with which credential.
Practical implication: treat the MCP registry as the enforcement point for identity, authorization, and audit before any server is exposed to users.
Why attestation and signing matter for MCP servers
An MCP server is executable code that can make outbound calls on behalf of users, so trust has to extend beyond the repository name or package source. Source attestation, image signing, vulnerability scanning, and change control reduce the chance that a server arrives with hidden behaviour or undocumented dependencies. The point is not to trust the code blindly but to make provenance and review part of the approval process. If a server can reach internal data or systems, then its origin and modification history become identity governance issues, not just software supply chain details.
Practical implication: require attestation and signed artifacts before an MCP server can enter the approved catalog.
How per-request identity and isolation bound the blast radius
Local credentials and broad runtime permissions turn a single MCP server into a high-value pivot point. Per-request identity tokens let each call inherit the user context instead of a shared service account, while container isolation and explicit filesystem and network permissions reduce what a server can touch if it is compromised. This is the difference between a tool that acts inside a narrow delegated scope and one that can roam across environment variables, local files, and downstream APIs. The governance objective is not perfect trust. It is containment that keeps a compromised server from becoming a platform-wide identity event.
Practical implication: scope each MCP server to the minimum network, file, and token access required for the intended task.
Threat narrative
Attacker objective: The objective is to use an ungoverned MCP server to reach downstream production resources while hiding the identity and scope of the access path.
- Entry begins when teams pull MCP servers from repositories or package registries without attestation, allowing unvetted code into the local environment.
- Credential exposure follows when local configuration files or runtime environment variables hold reusable secrets that the server can read or forward downstream.
- Escalation occurs when the server gains broader access than its intended function and can invoke internal tools, data systems, or production resources on behalf of users.
- Impact is reached when no audit trail can reconstruct which agent accessed which system, leaving production systems exposed without clear accountability.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
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
Local MCP without a registry is a governance failure, not a tooling choice. Once AI applications can invoke internal tools from mixed sources, the enterprise loses the basic ability to inventory, approve, and revoke access paths. That is an identity control problem first and a platform problem second. The practical conclusion is that MCP must be governed as an access layer, not adopted as an informal developer convenience.
MCP exposes a delegated-access problem that conventional IAM does not fully model. A user may authorise an AI application, but the server then fans out to downstream systems through credentials, filesystem access, and outbound network calls. That creates a governance chain where one approval can silently expand into multiple execution paths. Practitioners should read that as a warning that entitlement scope, not just authentication, is the control boundary that matters.
Source attestation and server approval are now part of identity governance for NHI workloads. If a server can be installed from a package registry and immediately interact with production data, then provenance becomes inseparable from authorisation. The registry is effectively the policy checkpoint where code trust, runtime scope, and user delegation converge. Security teams should treat that checkpoint as mandatory for any server that touches regulated or sensitive systems.
Per-request identity closes the gap between who asked and what executed. Shared service accounts hide the user context that security teams need for investigation and recertification. When each tool call carries an identity-bound token, accountability becomes attachable to the action rather than inferred after the fact. The result is not only better auditability but a cleaner basis for blast-radius reduction across AI-assisted workflows.
Local MCP creates an identity blast radius problem that grows with every uncatalogued server. Each unreviewed connection adds a new path for credentials, data, and execution to move further than intended. The article's six questions effectively describe the missing governance primitives: inventory, approval, context, containment, observability, and least privilege. Practitioners should use those primitives as the approval rubric for any local MCP rollout.
From our research library:
- The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
- Read next: Agentic AI Identity Guide
What this signals
Registry governance is the missing control plane for MCP. Security teams should treat every server as a delegated identity with its own lifecycle, approval state, and runtime scope. That means the approval process has to sit in front of the tool catalog, not after the first production connection.
Access review alone is not enough for MCP workflows. If a tool call can be executed by a local server with stored credentials, the meaningful control is issuance and approval time, not retrospective certification. The control model has to shift left into onboarding, attestation, and server-level containment.
Delegated tool access needs identity lineage, not just authentication. A user, an AI application, an MCP server, and a downstream resource can all sit in one execution chain, but security teams only retain control if each link is visible and bounded. That is why MCP governance belongs in the same conversation as NHI lifecycle management and least privilege.
For practitioners
- Define the MCP approval boundary Establish a registry-based approval workflow before any MCP server is allowed into production-facing workflows. Require every server to have an owner, a source, an access scope, and an explicit reviewer sign-off.
- Bind each tool call to user identity Replace shared credentials with per-request identity tokens so the downstream system can see the user context behind each action. This makes audit trails and entitlement review possible.
- Require provenance for every server Make source attestation, image signing, vulnerability scanning, and change control part of the onboarding gate for MCP servers. Any server that cannot prove origin should stay out of the approved catalog.
- Limit each server to its narrow runtime scope Constrain filesystem, network, and token access so a documentation server cannot inherit broad environment privileges. Assume a compromised server will try to move laterally unless runtime limits stop it.
Key takeaways
- Ungoverned MCP deployments create a delegated-access problem that existing IAM processes cannot see clearly enough to govern.
- The important control is not the protocol itself but the registry, attestation, and runtime scoping around each server.
- Security teams should approve MCP only when they can trace who invoked it, what it accessed, and which credential moved downstream.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article highlights credentials leaking into local config files and uncontrolled runtime access. |
| NHI-05 — Overprivileged NHI | The post warns that servers often get broader access than the task requires. | |
| NHI-03 — Vulnerable Third-Party NHI | Servers pulled from GitHub, npm, or Docker Hub may arrive with unvetted behaviour or dependencies. | |
| Recommendation — Scan MCP deployments for exposed credentials and remove local secret storage from server workflows. Enforce least-privilege scopes for each MCP server and block broad filesystem or API access. Require provenance checks and approval for any third-party MCP server before deployment. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers and downstream services authenticate machine-to-machine through delegated credentials. |
| Recommendation — Use IA-9 to bind server-to-service trust to approved, authenticated identities only. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat path described centers on credential exposure and movement into downstream resources. |
| Recommendation — Map ungoverned MCP server behaviour to credential access and lateral movement detection. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- 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.
- Per-request identity: An access model in which each tool call carries the initiating user’s identity and authorization context rather than a shared backend credential. For MCP, this is what preserves attribution and reduces the blast radius of server compromise.
- Source attestation: Evidence that code or an image came from a known source and has not been altered outside approved change control. For MCP servers, attestation helps security teams separate approved execution paths from unverified packages or repositories.
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 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org