Skip to content

PATTERN Cited by 1 source

Enterprise AI tool registry

Definition

An enterprise AI tool registry is an organisation-internal catalog of the tools an organisation's AI agents can call, with four functions — discovery + versioning + certification metadata + access control — structurally separated from the policy layer that reads from it to enforce request-time allow/deny decisions.

The pattern's contribution is not security per se but making security possible: the inventory the policy layer needs to enforce against, the metadata-surface adoption decisions need at decision time, and the version history forensics needs when behaviour changes.

"Think of it as an Internal Developer Portal (IDP) built for the agent era, solving the same coordination problem that IDPs solved for service teams, but one layer up." — Source: sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries

The four functions

The 2026-05-11 MongoDB post enumerates four functions in a deliberate hierarchy:

Function Core or Foundation? Owned by registry?
Discovery Core Yes — registry holds the catalog
Versioning Core Yes — registry holds version history
Certification metadata Foundation Surfaced — review work happens externally
Access control Foundation Read-from — policy layer enforces

"A mature enterprise tool registry has two core functions, discovery and versioning, and serves as the foundation for two others: certification metadata and access control."

1. Discovery

The registry must let any team building an agent find existing tools before writing new ones — this is how it inverts the friction-favorable direction from "reimplement" to "discover and adopt" (the same inversion that centralised package managers performed for shared code).

"With ownership metadata, version history, and usage metrics centralized, duplication is reduced not through mandate but through reduced friction. A well-designed catalog goes further than a flat list: tools should be grouped hierarchically by functional domain so that both humans and agents can find relevant capabilities quickly."

Two structural requirements:

  • Hierarchical grouping by functional domain. Flat lists don't scale beyond ~50 tools; the hierarchy is functional-domain-driven ("customer-data-access tools") not team-driven ("team-X registry").
  • Dual rendering surface. Same data model has to render in a web UI for humans (browsing) and via an API for agents (machine-readable pre-flight discovery). Pinterest's MCP registry is canonical on this dual surface property.

2. Versioning

"When agent behavior changes, why did it change? A tool registry that tracks versions gives enterprises the visibility to answer that question. Was it the model? A tool prompt update? An underlying API change? Without proper versioning, finding the answer goes from a simple diff comparison to a time-consuming, manual investigation."

Agent behaviour is a composite of model + tools + prompt; any of the three can change. Without per-tool version history, debugging a behaviour regression requires reconstructing the full input-state of every tool the agent used at the time of the regression — manually. With versioning, it's a diff. The registry is therefore not just a discovery substrate but a forensics substrate.

3. Certification metadata

The concepts/certification-as-metadata-not-enforcement property: review status (security approval, contract validation, PII-handling check) is held in the registry as metadata but the actual review work happens externally, through the security organisation's existing tooling.

"The registry's contribution is making the result of that review visible at the moment a team is deciding whether to adopt a tool, ensuring the review actually informs the decision it was meant to inform."

The metadata is consumed by humans at adoption time, by the policy layer at request time, and by audit / forensics post-incident.

4. Access control

The registry does not enforce access control. A separate policy layer reads the registry to know what tools exist and who owns them, and applies authorisation rules scoped to agent identity, team, environment, and action type.

"The registry's centralization lets access control be applied consistently, rather than forcing each team to come up with something bespoke."

The split keeps the registry simple (write-mostly-once, read-heavy) and lets the policy layer be re-implementable (Frontegg, Open Policy Agent, custom) without touching the registry.

Two pillars of value

"The case for it rests on two pillars: reducing coordination cost and enabling risk management, both for the humans building with agents and for the agents themselves."

  1. Reducing coordination cost. Discovery + reuse prevent duplication of engineering effort across teams. The investment converts redundant rebuild-cost into capacity for actual work.
  2. Enabling risk management. Inventory + metadata + version history make security review, policy enforcement, and forensic investigation tractable — they make the work possible, not automatic.

Anti-prescription: not a public registry

The pattern is explicitly organisation-internal:

"Every enterprise needs its own shared tool registry, one that reflects its specific regulatory environment, security posture, and operational conventions. To be clear, this is not an argument for a public package manager, something like npm, PyPI, or Maven. The infrastructure each enterprise needs is internal; scoped to its own teams, its own data, its own policies, its own domain. Trying to expand the scope beyond the confines of individual organizations would be premature standardization in a fast-moving, nascent space."

The argument: AI agent tools are organisation-specific in a way shared code generally is not — regulatory environment, internal data classifications, and per-team policy operate at the organisation boundary. A cross-organisation public AI tool registry would force premature standardization.

Composes with

  • vs MCP registry: MCP registry is a protocol-scoped instance of this pattern (catalog of approved MCP servers); the enterprise AI tool registry is the broader category that catalogs any tool an agent can call (REST APIs, internal RPC services, code-execution sandboxes, data accessors), MCP- compliant or not. Same four-function shape, different protocol scope.
  • vs public package manager (npm / PyPI / Maven): public package managers catalog shared library code at cross-organisation scope; this pattern is organisation-internal infrastructure for agent-callable tools. Same architectural argument (centralised infra inverts friction direction) but disjoint scope.
  • vs Backstage-style IDP: IDP catalogs services humans operate; AI tool registry catalogs tools agents call. Same four functions; consumers differ; cataloged entities differ. The patterns/idp-extended-to-ai-agent-tools framing makes this "one layer up" relationship explicit.
  • vs API catalog (RFC 9727): RFC 9727 is a public per-service catalog at /.well-known/api-catalog; this pattern is organisation-internal multi-tool inventory with policy metadata. They compose — a tool registered internally could publish a public API-catalog entry.

When to use

  • Multiple teams building agents with potential tool duplication.
  • Security organisation that needs an audit + review substrate for AI tool surfaces.
  • Adoption is past the prototype phase — i.e. the "shims that worked at small scale will not hold" threshold.
  • A policy layer (Frontegg, OPA, custom) is operational or planned that can read from the registry.

When NOT to use

  • Single team, one or two tools — the registry overhead exceeds its payoff.
  • All agent traffic already passes through a single managed proxy that owns inventory + policy as one component (a central proxy degenerate case where registry-vs-policy split has been collapsed).
  • No security organisation to feed metadata back — the certification-metadata function decays to noise without external review producing verdicts.

Open questions surfaced by the pattern

  • Bootstrapping problem — see concepts/deny-by-default-tool-policy: deny-by-default policy plus the registry implies something must authorise the first use of any new tool. The pattern doesn't prescribe the bootstrap mechanism (per-tool human approval, pre-classified tool tiers, sandbox-then-promote).
  • Registry-policy interface contract — what shape the policy layer reads from. The MongoDB post implies identity / team / environment / action are the policy-relevant axes, but the API contract is implementation-specific.
  • Agent-readable schema discovery — the dual-surface property requires the registry to expose tool schemas for runtime agent consumption, raising the question of how schema versioning interacts with running agents (mid-conversation tool-schema changes, etc.).

Seen in

Last updated · 542 distilled / 1,571 read