Fighting Tool Sprawl: The Case for AI Tool Registries – O’Reilly

As enterprise AI agent adoption scales, the absence of centralized, organization-level instrument infrastructure is producing compounding prices. When adoption is constructed round optimizing for deployment velocity, enterprises expose themselves to a mixture of dangers: duplicated engineering effort, safety publicity, and operational opacity.

Each enterprise wants its personal shared instrument registry, one which displays its particular regulatory atmosphere, safety posture, and operational conventions. To be clear, this isn’t an argument for a public bundle supervisor, one thing like npm, PyPI, or Maven. The infrastructure every enterprise wants is inside; scoped to its personal groups, its personal knowledge, its personal insurance policies, its personal area. Attempting to develop the scope past the confines of particular person organizations could be untimely standardization in a fast-moving, nascent house.

A shared enterprise instrument registry shouldn’t be an optimization or a nice-to-have. It’s foundational infrastructure as agent deployments scale past early experiments. The case for it rests on two pillars: decreasing coordination value and enabling danger administration, each for the people constructing with brokers and for the brokers themselves.

AI brokers depend upon instruments that retrieve knowledge, write data, set off workflows, and name exterior APIs. In line with McKinsey, in most massive organizations these instruments are constructed by particular person groups in an advert hoc trend: undocumented, ungoverned, and invisible to the remainder of the group. This sample is acquainted to most engineering leaders, and the fragmentation it creates compounds with each new agent deployment. Groups rebuild what already exists elsewhere, safety opinions miss instruments that have been by no means registered, and when one thing breaks, nobody has an entire image of what’s working or why.

A coordination failure at infrastructure scale

The software program trade solved an identical drawback a long time in the past with bundle managers. Centralized registries gave groups a solution to uncover, depend upon, and govern shared code. The educational was clear: stopping duplication and inconsistency is an infrastructure drawback, not a self-discipline drawback.

The agent period presents the identical drawback in a brand new area. When Kong launched its enterprise MCP Registry in February 2026, they explicitly known as out the issues of handbook MCP configuration, hardcoded and managed instrument isolation throughout groups, fragmented integrations, and restricted group visibility.

Fragmented instrument improvement shouldn’t be a consequence of poor engineering apply. Fairly, it’s the predictable end result of asking groups to resolve an infrastructure drawback on the software layer.

The visibility drawback

Gravitee’s ”The State of AI Agent Security 2026” survey quantifies what occurs when agent tooling is invisible to the individuals accountable for securing it. The survey discovered that solely 14.4% of groups with brokers past the planning part have full safety approval, and 88% of organizations had an agent-related safety incident this yr. Unhealthy practices like shared API keys are endemic, with solely 22% of organizations treating brokers as impartial identities. This governance hole transforms brokers from productiveness boosters into high-velocity liabilities able to executing unauthorized actions or leaking delicate knowledge earlier than a human may even intervene.

The story is evident: adoption is outpacing governance, and in a race for velocity outdated classes are having to be retaught. The vast majority of deployed brokers (and the MCP servers powering them!) are working with none safety sign-off. This isn’t primarily a resourcing failure, and it’s not one thing a registry alone solves. Safety groups can’t evaluation what they can not uncover, and with no registry, discovery is handbook, incomplete, and off. A registry doesn’t make instruments inherently safe; slightly, it makes safety work doable by making certain instruments exist not as transitory, advert hoc shims, however slightly as inventoried artifacts that audits and coverage can connect to.

It’s price revisiting public bundle managers right here. These registries haven’t been in a position to get rid of a variety of safety issues, points corresponding to typosquatting, malicious packages, and dependency confusion, exhibiting clearly that centralization alone shouldn’t be a safety answer. However in addition they present the converse: a registry is a precondition for safety. Quite a few neighborhood responses to breaches in these ecosystems show the facility centralization offers. Centralization doesn’t assure safety, however decentralization forfeits the means to coordinate it.

Governance requires shared context

The default posture in most agent deployments is permissive: instruments can be found except explicitly blocked. AgilityFeat’s analysis of enterprise AI guardrails identifies the structural danger this creates, since an structure not constructed on deny-by-default will increase danger and creates maintenance prices.

Enable-by-default, replicated throughout dozens of impartial agent deployments, produces an assault floor that scales with adoption. Inverting this requires a coordination level, a shared, organization-wide context. The registry itself isn’t a governance layer, however it’s what makes governance doable. When each instrument an agent can use is registered with possession, model, and evaluation standing, the governance layer has one thing concrete to implement in opposition to. With out that context, coverage must be reimplemented by each consuming staff, and consistency turns into unimaginable.

Frontegg’s framework for AI agent governance describes what that coverage layer seems like operationally: agent actions mapped to express, granular guardrails that outline the operational boundaries for what any agent can try or execute. These guardrails stay exterior the registry, however they depend upon it. A guardrail that references a instrument the safety staff has by no means heard of can’t be written within the first place.

What a production-grade instrument catalog requires

A mature enterprise instrument registry has two core capabilities, discovery and versioning, and serves as the muse for 2 others: certification metadata and entry management. Consider it as an Inside Developer Portal (IDP) constructed for the agent period, fixing the identical coordination drawback that IDPs solved for service groups however one layer up.

Discovery permits any staff constructing an agent to seek for present instruments earlier than writing new ones. With possession metadata, model historical past, and utilization metrics centralized, duplication is decreased not by mandate however by decreased friction. A well-designed catalog goes additional than a flat checklist: instruments must be grouped hierarchically by practical area in order that each people and brokers can discover related capabilities rapidly.

Versioning closes a niche that neither discovery nor entry controls deal with: When agent conduct adjustments, why did it change? A instrument registry that tracks variations offers enterprises the visibility to reply that query. Was it the mannequin? A instrument immediate replace? An underlying API change? With out correct versioning, discovering the reply goes from a easy diff comparability to a time-consuming, handbook investigation.

Certification standing (issues like safety approval, API contract validation, PII dealing with checks) is metadata that the registry surfaces, not a boundary that the registry itself enforces. The precise evaluation work occurs by the safety group’s present tooling. The registry’s contribution is making the results of that evaluation seen in the intervening time a staff is deciding whether or not to undertake a instrument, making certain the evaluation really informs the choice it was meant to tell.

Entry management works the identical means. A coverage layer enforces authorization scoped to agent id, staff, atmosphere, and motion sort, studying from the registry to know what instruments exist and who owns them. The registry’s centralization lets entry management be utilized persistently, slightly than forcing every staff to provide you with one thing bespoke.

None of that is achievable when every staff maintains its personal remoted tooling stack. Platform groups already perceive why IDPs exist. The worth of the paradigm within the agent context isn’t any totally different.

The compounding value of inaction

The price of inaction is direct, not merely operational and security-related. And not using a searchable, well-organized catalog of instruments, groups regularly reinvent the wheel, since it’s simpler to generate a instrument than to seek out one which already exists. Duplication means redundancy and technical debt. A registry, by making instruments discoverable and reusable, converts that redundant spend into capability for precise work.

For platform engineering groups, the trajectory is evident. Agent adoption is growing, instrument duplication is growing with it, and the shims that labored at small scale won’t maintain because the variety of brokers and instruments grows. The safety publicity documented within the Gravitee survey will widen, not slender, with out structural intervention.

The organizations that construct centralized instrument infrastructure now will have the ability to onboard new brokers rapidly, govern them persistently, and audit them when one thing goes mistaken. Those who defer will rediscover, the laborious means, what platform groups realized a decade in the past: coordination issues don’t resolve themselves on the software layer. They compound there.