TL;DR: Regulated enterprises adopting MCP are running into five predictable failures: no registry, all-or-nothing tool access, broken auth, tool poisoning, and fragmented audit trails, according to Tetrate. The governance problem is architectural, not procedural, because enterprises need a single governed boundary for inventory, authorization, and traceability.
At a glance
What this is: This analysis argues that MCP adoption in regulated enterprises breaks down when tool access, authentication, and audit are split across many independent servers instead of enforced at one governed boundary.
Why it matters: IAM, PAM, and NHI teams need a controllable boundary for MCP because inventory, least privilege, credential handling, and audit evidence all fail when every server is governed separately.
Context
MCP has become the default way agents reach tools and data, but the governance model around it still assumes scattered servers, scattered credentials, and scattered logs. That creates an identity control problem as much as a protocol problem, because regulated enterprises need to know what is approved, who can invoke it, and how every call is evidenced.
The core issue is not the existence of MCP itself but the way deployments bypass MCP security guide principles when each team stands up its own server with its own auth model and audit trail. In practice, that turns a tool access layer into shadow infrastructure unless the boundary is centralised and enforced.
Key questions
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.
Q: Why do MCP deployments increase identity and access risk?
A: MCP increases risk because it connects untrusted model output to real systems that can act on it. That creates new paths for token exposure, overbroad authorization, rogue endpoints, and confused deputy behaviour. The issue is not AI novelty, but the expansion of machine-to-machine trust at runtime.
Q: How should security teams restrict MCP tools for production agents?
A: Security teams should place a policy enforcement layer between the agent and the MCP server, then assign each agent persona a minimal allow list. The safest default is deny by default, because any tool that is merely visible can become usable if governance is weak or routing is misconfigured.
Q: How can organisations make MCP audit evidence usable for compliance reviews?
A: They should route all MCP traffic through one governed observation point and capture tool name, parameters, and responses there. That creates a single evidentiary record instead of fragmented logs across servers and environments. Compliance teams can then reconstruct who did what, through which tool, and against which system.
Technical breakdown
Why MCP server sprawl breaks inventory and approval
MCP becomes hard to govern when every team can deploy its own server, pin its own version, and expose its own tool set. Without a central registry, there is no authoritative inventory of approved servers, no reliable ownership data, and no way to stop agents from discovering unofficial endpoints. In regulated environments, that is not just an operational inconvenience. It means the approval decision and the runtime enforcement decision are separated, so governance exists only on paper. A registry that sits on the request path changes the control from documentation to enforcement.
Practical implication: Treat the registry as the enforcement point, not a reference list, and block any server that is not on that path.
How tool-level least privilege changes the MCP access model
Most MCP servers expose far more capability than a given agent needs, so approving the server as a whole creates an all-or-nothing access problem. The more precise control is at the tool level, where the agent sees only the functions explicitly authorised for its use case. That matters because tool exposure is not just a usability issue. It determines whether an agent can read, write, mutate, or administer systems beyond its intended task. When the server boundary is too coarse, least privilege collapses into broad trust in the provider of the server rather than in the specific actions the agent should be allowed to take. See the AI Agent Tool and Plugin Security Guide.
Practical implication: Scope approval to individual tools and deny visibility to the rest of the server surface.
Why centralised MCP auth and audit are the real control boundary
MCP deployments fragment identity control when each server handles authentication differently and each environment produces its own logs. That creates incompatible token handling, inconsistent client identity assurance, and audit evidence that cannot be correlated without heavy manual work. A single proxy boundary changes the architecture by terminating auth once, holding downstream service credentials centrally, and recording every tool call in one observation surface. That is the practical answer to the gap between agent action and examiner evidence. The protocol itself may be distributed, but the governance boundary cannot be if traceability matters.
Practical implication: Terminate authentication at one proxy and centralise audit records before tool calls reach downstream servers.
Threat narrative
Attacker objective: The attacker or malicious server operator seeks unauthorized tool execution, credential reuse, and opaque agent activity across enterprise systems.
- Entry occurs when an agent connects to an MCP server that was installed informally and was never added to a governed registry.
- Credential exposure follows when that server authenticates with a long-lived personal token or other unmanaged secret.
- Escalation happens when the server exposes more tools than the agent needs, including write or administrative actions.
- Impact is the ability to trigger unaudited tool use, exfiltrate session context through poisoned metadata, or make examiner-grade traceability impossible.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Home Depot Year-Long Token Exposure: Home Depot exposes authentication tokens in public repository for over a year before remediation.
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
Single-boundary governance is now the real MCP control plane: Regulated enterprises cannot safely treat MCP as a loose federation of servers with separate auth and logging choices. The control that matters is the boundary where registry, authorization, and audit all meet. Once that boundary is missing, every downstream policy becomes advisory rather than enforceable. The practitioner implication is that MCP governance must be designed as architecture, not as a collection of team-level rules.
Tool-level privilege is the only meaningful least-privilege model for MCP: Approving a server and hoping the agent behaves is a server-level trust model, not identity governance. MCP profiles collapse the platform decision and the use-case decision into one enforceable primitive, which is exactly what regulated environments need when different agents require different tool subsets. The implication is that server approval without tool scoping is too coarse for production use.
Centralised identity handling is the only workable answer to MCP auth fragmentation: Regulated environments cannot absorb a patchwork of personal tokens, ad hoc OAuth variants, and local trust assumptions across every server and developer machine. The identity boundary has to move upward into a governed proxy that holds downstream credentials and normalises authentication. That does not just simplify operations; it redefines where trust is permitted to exist. Practitioners should treat downstream credential custody as a shared control, not a local convenience.
Tool-poisoning risk turns metadata into part of the attack surface: When tool descriptions are interpreted by the agent, the description itself becomes a delivery channel for malicious instructions. That means supply chain controls cannot stop at code integrity or package provenance. The content of the tool catalogue has to be curated and validated centrally. The practitioner implication is that server metadata must be governed with the same seriousness as executable code.
Audit without a single observation point is not audit evidence: If each MCP server logs differently, examiner-grade traceability becomes a correlation project instead of a control. The result is fragmented evidence that can be incomplete, inconsistent, or easy for probabilistic systems to dispute. A single observation point is the only practical way to preserve attribution for consequential agent actions. The implication is that distributed logging is insufficient when regulatory accountability is in scope.
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 governance now depends on whether the boundary is enforceable: regulated programmes should assume that local MCP servers, personal tokens, and separate logs will keep creating blind spots until the identity control plane is pulled into one managed boundary. The practical signal is that inventory, auth, and audit are no longer separable tasks.
Tool catalogues are becoming identity artefacts: once agents can act through tools, the catalogue itself becomes part of the access model, not a side document. Teams that still treat server lists as reference data will struggle to prove what an agent could actually reach, even if the protocol is otherwise standardised.
Governance gets sharper when approval, use case, and observability are bound together: the next stage for regulated MCP programmes is not more server adoption but tighter profiling, stronger boundary enforcement, and fewer places where credentials and decisions can drift apart.
For practitioners
- Establish a governed MCP registry Make the registry the only approved path to production servers, with versioning, ownership, and enforced request-path checks.
- Scope agents to specific tools Define MCP profiles that expose only the exact tools needed for each agent use case, not the full server surface.
- Terminate authentication at a proxy boundary Move downstream credential custody out of laptops and into a central boundary that normalises auth across servers.
- Centralise audit for every tool call Record tool name, parameters, and responses in one observation surface so reviewers can reconstruct consequential actions.
Key takeaways
- MCP adoption becomes a governance problem when server sprawl, permissive tool exposure, and fragmented identity controls outpace the protocol’s technical usefulness.
- The article frames the fix as a single enforceable boundary that combines registry, authorization, and audit instead of relying on separate team-level controls.
- For regulated enterprises, the practical test is whether agents can only reach approved tools through one managed path with traceable identity and evidence.
Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Tool and Plugin Security Guide · Ultimate Guide to NHIs · Top 10 NHI Issues
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, OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Unofficial MCP servers create third-party identity risk through uncontrolled deployment and trust. |
| NHI-04 — Insecure Authentication | The article centres on broken and inconsistent auth across MCP servers and proxies. | |
| NHI-05 — Overprivileged NHI | Servers often expose far more tools than each agent needs, creating excess privilege. | |
| Recommendation — Require approval and ownership evidence for every MCP server before agents can reach it. Move MCP authentication behind one governed boundary and eliminate unmanaged server-side auth patterns. Scope each agent to the minimum MCP tools required and hide every other exposed capability. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents gain excessive tool access and can act beyond intended scope when profiles are absent. |
| Recommendation — Bind agent identity to narrow tool profiles and prevent privilege expansion across servers. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article discusses credential exposure and tool poisoning leading to unauthorized data movement. |
| Recommendation — Map exposed MCP credentials and poisoned tool paths to credential access and exfiltration detections. | ||
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.
- Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
- MCP Profile: A profile is a named set of behaviours and properties that a Model Context Protocol client and server agree to use during a session. In enterprise settings, profiles let organisations require specific authentication, scope, or service behaviour without changing the base protocol.
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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org