Fighting Tool Sprawl: The Case for AI Tool Registries

Peter Richards · rss · 2026-04-20 Reader 🖥️

Agent Governance (Internal)Agent Security Agent Tool Management Platform Engineering

Enterprise AI agent adoption is producing a coordination failure identical to the one package managers solved for shared code: without a centralized, internal tool registry that provides discovery, versioning, certification metadata, and access-control foundations, organizations compound duplication, security exposure, and governance opacity with every new agent deployment.

practical · opinion essay — infrastructure advocacy piece arguing for enterprise-internal AI tool registries, structured as problem-diagnosis-prescription — Written in the register of enterprise platform-engineering thought leadership. Draws on McKinsey research, vendor announcements (Kong, Gravitee, AgilityFeat, Frontegg), and historical analogy to package managers. Advocacy, not reporting.

Structure

Part	Role
Problem statement	Frames the absence of centralized tool infrastructure as the root cause of duplication, security gaps, and operational opacity in enterprise agent deployments.
Package-manager analogy	Establishes historical precedent: the software industry already solved this class of problem with centralized registries, proving it is an infrastructure problem.
The visibility problem	Uses Gravitee survey data (14.4% full security approval, 88% incident rate) to quantify the governance gap when tools are invisible to security teams.
Governance requires shared context	Argues that allow-by-default postures create attack surfaces scaling with adoption, and that deny-by-default requires a coordination point — the registry.
What a production-grade tool catalog requires	Specifies the four functions: discovery, versioning, certification metadata, and access control. Positions registry as an IDP for the agent era.
Compounding cost of inaction	Closes with the argument that coordination problems compound at the application layer; structural intervention is needed now.

Key terms

tool registry Agent Tool Management
An enterprise-internal, centralized catalog of AI agent tools with discovery, versioning, certification metadata, and access-control foundations — explicitly not a public package manager.
tool sprawl Agent Tool Management
The uncoordinated, ad hoc proliferation of undocumented, ungoverned AI agent tools across teams — producing duplication, security blind spots, and operational opacity.
coordination failure Agent Tool Management
The predictable outcome of asking teams to solve an infrastructure problem at the application layer — not a failure of discipline but of missing shared infrastructure.
Internal Developer Portal (IDP) Platform Engineering
Existing platform-engineering infrastructure for service discovery and governance; the author positions the tool registry as the agent-era equivalent.
deny-by-default Agent Security
A security posture where agent tool access is blocked unless explicitly allowed — the inverse of the current permissive default that creates scaling attack surfaces.

Propositions

stateddevelopedFragmented AI agent tool development is the predictable outcome of missing shared infrastructure, not poor engineering discipline.
extends ←Why AI agents need a Context Lake · p3 — Generalizes the 'fragmentation is the predictable result of missing shared infrastructure' diagnosis from tool registries specifically to organizational knowledge/documentation more broadly (AGENTS.md doesn't scale for the same structural reason tool sprawl happens).
statedcorroboratedA centralized tool registry is a precondition for security — it does not guarantee security, but decentralization forfeits the means to coordinate it.
extendsMCP Is Making API Sprawl Worse · p5 — Develops the registry suggestion into a full thesis: a centralized tool registry is the precondition for coordinating agent-tool security at all.
supportsMCP Is Making API Sprawl Worse · p5 — A centralized registry as a precondition for security concretizes the idea that pushing assets into service registries is the means to enforce governance at scale.
supports ←AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale · p9 — Loom's use of a review-gated AWS Agent Registry for discovery is a concrete instance of the claim that a centralized registry is a precondition for securing agent/tool sprawl.
statedestablishedEnterprise agent deployments currently operate with a permissive, allow-by-default posture that produces an attack surface scaling linearly with adoption.
supports ←Breaking: Autonomous Agents are a Shitshow · p1 — Independent empirical corroboration: the 91% tool-chaining vulnerability rate matches the allow-by-default enterprise posture with its 88% incident rate.
supports ←How to Manage Privilege Drift in Multi-Agent Systems · p2 — Gives a concrete, quantified mechanism (permissions multiplying across agents, shared resources, and a shared communication channel) for why enterprise agent deployments' attack surface scales linearly with adoption.
stateddevelopedThe AI agent tool coordination problem is structurally identical to the problem package managers solved for shared code libraries.
supportsIncident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · p6 — Both frame agent-tool ecosystems as structurally identical to package managers, inheriting the same supply-chain attack surface.
extends ←Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov · p10 — Both treat the AI-agent tool/context coordination problem as structurally identical to what package managers already solved for code libraries; this document extends that same analogy from tool registries specifically to the broader class of agent-context artifacts (skills, instructions, hooks), with APM as a concrete implementation.
statedcorroboratedA production-grade tool registry requires four capabilities: discovery, versioning, certification metadata, and access-control foundations.
supports ←Presentation: From Copy-Paste to Composition: Building Agents Like Real Software · p12 — Independently arrives at the same conclusion — that a production-grade agent tool registry must include versioning as a first-class capability, not an optional extra — from a security/eval-reproducibility angle rather than a sprawl-management angle.
statedIt is currently easier for a team to generate a new tool than to find an existing one — a friction asymmetry that a registry can invert.
statedcorroboratedThe enterprise tool registry must be internal and organization-scoped; cross-organization standardization would be premature in a nascent space.
extends ←Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents · p5 — Richards argued an enterprise tool registry must stay internal/organization-scoped because 'cross-organization standardization would be premature in a fast-moving, nascent space.' ARD's immediate, broad cross-vendor launch (Microsoft, GitHub, Hugging Face, Cisco, Databricks, and more, with two implementations already shipping) is the concrete cross-organizational standard Richards judged premature — extending the internal-registry thesis to the industry-wide case sooner than that piece anticipated.
supports ←The Interfaces Are Arriving · p7 — Both pieces converge on the same near-term control despite the public MCP Registry existing: cross-organization registry standardization is premature, so an internal, organization-scoped subregistry or allowlist is the practical response.

Arguments

strength: medium

strength: high

strength: medium

Narratives

The package-manager redemption arc: decades ago, software was fragmented and duplicated; package managers solved this; the agent era is re-creating the same problem; the registry is the same solution, one layer up.
→ Provides historical legitimacy and inevitability framing — positions the registry not as a novel proposal but as a known pattern being applied to a new domain.
The governance crisis: adoption is outpacing governance, old lessons are being retaught, and the window for structural intervention is closing before costs become unmanageable.
→ Creates urgency and frames inaction as the risky choice, inverting the usual framing where building new infrastructure is the risk.

Questions addressed

✅ Why do enterprise AI agent deployments produce duplicated, ungoverned tooling?
It is a coordination failure caused by missing shared infrastructure, not poor discipline.
✅ What is the structural relationship between tool registries and security governance?
A registry is a necessary precondition — it makes tools discoverable so security review can attach — but not sufficient on its own.
✅ What does a production-grade enterprise tool registry require?
Discovery, versioning, certification metadata, and access-control foundations.
✅ Why should tool registries be enterprise-internal rather than cross-organizational?
Cross-org standardization would be premature in a nascent, fast-moving space.
✅ What historical precedent supports the case for centralized tool infrastructure?
Package managers (npm, PyPI, Maven) solved the identical coordination problem for shared code.

Gaps

unstated assumptionThe package-manager analogy elides a critical disanalogy: library dependencies are static, versioned, and deterministic, while agent tool invocations are runtime-dynamic, context-sensitive, and may produce different effects depending on prompt, model, and state. Versioning a tool's code does not version its behavior.
omissionNo engagement with the possibility that tool registries themselves become high-value attack targets — a lesson that public package managers have taught repeatedly (typosquatting, registry compromises). The article acknowledges this for public registries but does not examine the risk for internal ones.
unstated assumptionThe article assumes that tool duplication is primarily a discovery problem, but in many organizations duplication persists even when shared components are discoverable — teams duplicate because integrating shared infrastructure carries coordination costs, API coupling, and dependency risks that local solutions avoid.
omissionNo discussion of the organizational incentive structures that produce tool sprawl: teams are rewarded for shipping agents quickly, not for contributing to shared infrastructure. A registry does not change these incentives.

Closes gaps elsewhere

MCP Is Making API Sprawl Worse · g2 — Provides the missing empirical grounding: Gravitee survey data (88% incident rate, 14.4% full security approval) and documented duplicate-tool dynamics show agent-tool sprawl materializing in enterprises.
Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · g1 — Names the governance/vetting model the incident shows is absent: a centralized registry with discovery, versioning, certification metadata, and access-control foundations.
Incident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · g4 — Provides the missing comparison to package-manager ecosystems, framing the agent-tool coordination and supply-chain problem as structurally identical to what npm/PyPI-style registries solve.