When registries are not controlled, malicious or poisoned tool definitions can enter the workflow as if they were legitimate. The result is an execution path where the model trusts the tool source, but the organisation has no assurance that the source, function, or permissions align with policy.
What breaks when MCP tool registries are not controlled?
When registries are loose, the problem is not just bad metadata. The registry becomes a trust boundary that attackers can exploit to smuggle in a tool definition, redirect an agent to an unsafe endpoint, or make an unreviewed action look policy-compliant. That changes MCP from a governed integration layer into an execution channel with weak provenance and weak accountability.
How uncontrolled registries change the attack surface
An MCP registry is effectively a discovery and authorization reference point for tools. If anyone can publish, alter, or mirror entries without strong control, the agent may select a tool based on name, description, or expected capability rather than verified ownership and permissions. That is why registry control has to be treated as part of the tool trust model, not as a simple cataloging problem.
In practice, uncontrolled registries create three failures at once: source confusion, permission confusion, and lifecycle confusion. Source confusion means the model cannot reliably tell whether a tool came from the intended provider. Permission confusion means the tool can advertise capabilities that exceed what the organisation wanted to allow. Lifecycle confusion means stale or replaced entries can keep working after the intended owner has moved, changed, or been removed.
For agentic systems, this is especially important because the registry often sits upstream of the moment where the agent actually executes a tool call. Once the catalog is poisoned, downstream controls have less room to recover, because the wrong tool may already have been selected and trusted by design. The safer posture is to treat the registry as part of the control plane for tool provenance and tool eligibility, not as passive documentation.
What failures appear in the workflow
When registry governance is weak, the workflow can break in ways that are hard to spot in review. A malicious definition can attach a legitimate-looking name to an unsafe function, introduce a tool that exfiltrates data, or steer requests toward a service that the organisation never approved. This is one of the reasons tool poisoning matters in MCP and adjacent agentic patterns, because the agent often acts on the registry’s asserted identity of the tool rather than on a separate human validation step. MCP Security Guide
Weak registry control also undermines authorization boundaries. If the registry can expose a tool with broader scope than intended, the agent may inherit permissions that were never meant to be available for that task. That is the same practical failure pattern captured by OWASP Agentic AI Top 10, where tool misuse and identity or privilege abuse become material once an agent is allowed to trust a bad integration source.
Registry control also affects operations. If teams cannot inventory which registry entries are approved, deprecated, or shadowed, they cannot reason about blast radius after a compromise. That means incident response becomes slower, revocation becomes incomplete, and remediation turns into a search problem instead of a control problem.
Why registry control is a governance issue, not just a security setting
Registries need an explicit owner, change control, and verification path because they influence what an agent is allowed to discover and use. A registry that accepts unreviewed additions creates an approval gap between policy and execution. Even if the underlying tool is benign, the lack of control still breaks assurance because the organisation can no longer prove that the advertised capability, endpoint, and permission set match the approved design.
For that reason, registry governance should align with the same discipline used for other trust anchors: defined ownership, integrity checks, review of tool metadata, and removal of stale entries. The practical goal is not to freeze the registry forever, but to make every tool entry traceable to an accountable source and a deliberate approval decision. The MCP authorization model is a useful reference point here because it shows how protocol-level trust assumptions need to be explicit rather than implied. Model Context Protocol: Authorization specification
Risk and Threat Considerations
Uncontrolled registries create an attractive poisoning point because they sit before execution and can shape both tool selection and trust. A hostile entry can persist long enough to influence many agent runs, especially when teams assume that a named tool in the registry is inherently approved.
Failure mechanism: An attacker or careless publisher introduces or alters a registry entry so the agent discovers a malicious tool, a repackaged tool, or a tool with broader permissions than policy allows, then the agent executes it as if it were legitimate.
Impact: The result can be unauthorized actions, data exposure, credential or token misuse, policy bypass, and a much larger blast radius because the wrong tool was trusted at the point of selection rather than blocked at runtime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Registry poisoning can steer agents to unsafe or unapproved tools. |
| ASI03 — Identity & Privilege Abuse | Bad registry entries can cause agents to act with excessive or misbound authority. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Registry control is a supply-chain trust problem for agent tool delivery. | |
| Recommendation — Constrain tool selection to approved registries and validate tool provenance before execution. Bind agent actions to least privilege and verify each tool’s allowed scope. Treat registry publishing and updates as supply-chain inputs that require integrity checks. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Uncontrolled registries can expose agents to untrusted third-party tool sources. |
| NHI-05 — Overprivileged NHI | A poisoned registry can present tools with broader permissions than intended. | |
| Recommendation — Vet third-party tool sources and restrict registry onboarding to trusted providers. Review tool permissions against policy before allowing registry publication. | ||
Practitioner Guidance
What to verify: Verify that every registry entry has an accountable owner, an approval trail, and a defined scope that matches the tool’s actual function. If the registry cannot show who can publish, who can change, and who can retire entries, it is not controlled enough to trust.
What good looks like: Approved tools are discoverable, stale entries are removed quickly, tool metadata is versioned, and agent selection is constrained to entries that have been reviewed against policy. A healthy registry makes provenance visible before execution, not after an incident.
Common mistake: Treating the registry as a convenience layer while assuming runtime filters alone will save you. Once the registry itself is poisoned, the agent may already be pointed at the wrong tool path, so discovery control has to come before selection control.
Practitioner takeaway: Control the registry as if it were part of the execution plane, because in MCP the catalog is often where trust is first granted and where compromise can be scaled.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org