Enterprise AI agents are starting to hit a familiar infrastructure wall: every team can move fast, but no one can see the whole tool surface anymore.
MongoDB’s argument is direct. As companies push agents beyond pilots, the tools those agents use — data retrieval functions, record-writing actions, workflow triggers, API calls, MCP servers, and internal connectors — are often built team by team. They may work locally. They may ship quickly. But they are frequently undocumented, unregistered, and invisible outside the group that created them.
That creates more than duplication. It creates a governance problem. Security teams cannot review tools they do not know exist. Platform teams cannot reduce overlap if they cannot discover what has already been built. Incident responders cannot reason cleanly about agent behavior if the organization lacks a live map of what agents can call, who owns those tools, and what permissions they carry.
MongoDB’s proposed answer is not a public package manager for agent tools. It is an internal enterprise registry: scoped to one organization, its data, its policies, its regulatory constraints, and its operational habits.
The problem is not sloppy teams. It is missing infrastructure.#
Tool sprawl is easy to misread as an engineering discipline failure. MongoDB frames it differently: teams are being asked to solve an infrastructure problem at the application layer.
The pattern is old. Before package managers became standard, organizations duplicated code, copied libraries manually, and lacked a dependable way to discover and govern shared components. Registries did not make software supply chains safe by themselves. They did, however, create a coordination point. Teams could find shared code. Owners could publish updates. Security teams could inspect dependencies. Policies had a place to attach.
Agent tools now have a similar shape. One team builds a connector for customer data. Another builds a near-identical connector for support workflows. A third hardcodes credentials into an MCP server because it needs a demo to work by Friday. Each local choice is understandable. Together they produce a tool surface no central team can reliably inspect.
MongoDB points to Kong’s enterprise MCP Registry launch in February 2026 as one sign that the market is converging on this issue. Kong described problems around manual MCP configuration, hardcoded setup, isolated tool management across teams, fragmented integrations, and poor organization-wide visibility. Those are not edge cases. They are what happens when agent infrastructure grows through side channels.
The lesson is blunt: if agent tools are built as one-off shims, governance becomes archaeology.
A registry does not secure agent tools. It makes security possible.#
The strongest part of MongoDB’s case is the distinction between centralization and security.
A registry is not a magic safety layer. Public package ecosystems prove that. npm, PyPI, Maven, and similar systems still deal with typosquatting, malicious packages, dependency confusion, maintainer compromise, and abandoned components. Centralization can even concentrate risk when the registry itself becomes trusted infrastructure.
But the opposite is worse. Without a registry, the organization forfeits the basic mechanics of coordinated defense.
MongoDB cites the State of AI Agent Security 2026 survey, which found that only 14.4% of teams with agents beyond the planning phase had full security approval, while 88% of organizations reported an agent-related security incident during the year. The source also notes weak identity practice: only 22% of organizations treated agents as independent identities, with shared API keys remaining common.
Those numbers should not be treated as universal law without checking the survey methodology. But they match the operational risk pattern: agent adoption is moving faster than approval, inventory, identity, and review processes.
That matters because agents are not passive software dependencies. Their tools can retrieve data, write records, trigger workflows, and call external services. A poorly reviewed library may introduce a vulnerability. A poorly governed agent tool may execute a business action.
A registry gives security teams something concrete to work with:
- which tools exist
- who owns each tool
- what the tool is allowed to do
- which agents can call it
- what version is deployed
- whether review or approval has happened
- what credentials, scopes, or identities are involved
That inventory does not prove safety. It turns an invisible risk surface into an auditable one.
Governance needs shared context, not scattered policy copies.#
Most agent deployments tend to start permissive. A tool is available unless someone explicitly blocks it. That is convenient during experimentation. It becomes dangerous when repeated across many teams and many agents.
MongoDB’s source material references AgilityFeat’s analysis of enterprise AI guardrails, especially the risk of architectures that are not deny-by-default. The practical issue is simple: allow-by-default scales the attack surface with adoption. Every new tool, connector, and workflow action becomes another place where policy may be missing, inconsistent, or stale.
The registry is not the policy engine. That distinction matters.
A registry should not be confused with authorization, runtime enforcement, identity management, logging, or human approval flows. Those controls live elsewhere. But they need reliable metadata. If a governance layer is going to enforce granular guardrails, it needs to know what tools exist and how they are classified.
For example, a company may want rules like these:
- customer-data read tools require approval before production use
- write-capable tools need stronger identity boundaries than read-only tools
- payment, deletion, refund, and account-change actions require human confirmation
- tools touching regulated data must be owned by an accountable team
- deprecated tools cannot be called by newly deployed agents
Those rules are weak if every team defines its own tool catalog in its own repo. They become enforceable only when the organization has a shared reference point.
This is where internal registries are more plausible than public standardization. The tool surface of a bank, a hospital, a SaaS vendor, and a logistics company will not share the same policy shape. Their regulatory duties, data boundaries, operational workflows, and acceptable failure modes differ. MongoDB is right to reject the idea that the near-term answer is a broad public package-manager model for agent tools. The internal registry is the useful unit.
What an enterprise registry should actually contain#
A useful agent tool registry is not just a directory with names and descriptions. If it is too thin, it becomes shelfware. If it is too heavy, teams route around it.
At minimum, the registry has to answer operational questions:
- What does this tool do?
- Who owns it?
- Which systems does it touch?
- What data classes can it access?
- Can it read, write, delete, trigger, or escalate?
- Which agents or teams are approved to use it?
- What review status does it have?
- What version is current?
- How is it authenticated?
- Where are logs and failure signals visible?
The hard part is not storing that metadata. The hard part is keeping it true. Tool registries fail when registration is manual, optional, and detached from deployment. If teams can ship an MCP server or agent connector without updating the registry, the registry becomes a stale compliance artifact.
The better pattern is to make registration part of the path to production. Tool publication, review state, identity binding, and runtime access should connect to the same control plane. Not every organization needs the same implementation. But the registry has to sit close enough to deployment that it reflects reality.
What not to overclaim#
MongoDB’s piece is a vendor blog, and the framing naturally aligns with enterprise infrastructure buying cycles. That does not make the argument wrong. It does mean the claim should be kept precise.
An AI tool registry will not solve prompt injection. It will not guarantee least privilege. It will not prevent a trusted tool from being abused by a compromised agent. It will not replace runtime monitoring, identity design, approval workflows, secure coding, red teaming, or incident response.
Its value is narrower and still important: it creates shared context. Without that, higher-level governance is mostly aspiration.
The useful comparison is not “registry versus no risk.” It is “known tool surface versus unknown tool surface.” Enterprises can govern the first. They can only guess at the second.
What teams should check now#
If agents are already moving past experiments, the first question is not whether the organization has a polished registry product. It is whether anyone can produce a credible inventory.
Start with a blunt audit:
- list every agent in production or near-production
- list every tool, connector, MCP server, function, and API action those agents can call
- identify tool owners and approval status
- separate read-only tools from write-capable or workflow-triggering tools
- find shared API keys and replace them with agent-specific identities where possible
- mark tools that touch sensitive, regulated, or customer data
- define which tools are allowed by default and which require explicit approval
If that list is hard to produce, that is the finding. The organization already has tool sprawl. The registry discussion is then no longer theoretical. It is the missing map.