Skip to content

CONCEPT Cited by 1 source

Registry as governance precondition

Definition

Registry as governance precondition is the architectural argument that an inventory primitive is upstream of any policy-layer enforcement: a registry doesn't do governance, but governance — security review, access policy, audit, change attribution — requires a registry. Decentralization forfeits the means to coordinate any of those.

"A registry does not make tools inherently secure; rather, it makes security work possible by ensuring tools exist not as transitory, ad hoc shims, but rather as inventoried artifacts that audits and policy can attach to." — Source: sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries

The asymmetry: centralization vs security

The post is careful to not equate centralization with security:

"It is worth revisiting public package managers here. These registries have not been able to eliminate a number of security problems, issues such as typosquatting, malicious packages, and dependency confusion, showing clearly that centralization alone is not a security solution. But they also show the converse: a registry is a precondition for security. Numerous community responses to breaches in these ecosystems demonstrate the power centralization provides. Centralization does not guarantee security, but decentralization forfeits the means to coordinate it."

The asymmetry is load-bearing:

  • Centralization → security is not an entailment. Public package registries (npm, PyPI, Maven) have demonstrated this for decades — they catalog, but typosquatting and malicious packages persist.
  • Decentralization → no coordination is an entailment. Without an inventory, "discovery is manual, incomplete, and stale," and security teams cannot review what they cannot discover.

The implication: an organisation that wants any meaningful security posture for its agent tools needs the registry first; governance investment is wasted (or impossible) without one.

What the registry authoritatively answers

For governance to be possible, the registry has to authoritatively answer at minimum:

  1. What tools exist in the organisation's production environments?
  2. Who owns each tool? (For attribution + support routing.)
  3. What's the review status of each tool? (Security approval, API contract validation, PII handling.)
  4. What's the version of each tool? (For change attribution and rollback.)
  5. Who can use each tool? (Read by the policy layer, not enforced by the registry.)

These are the inputs the policy layer needs to write any rule more sophisticated than "deny everything" or "allow everything."

The registry-vs-policy split

A clean separation of concerns falls out of this argument:

  • Registry = inventory + metadata. Write-mostly-once, read-heavy. Holds what's there and what's known about it.
  • Policy layer = enforcement. Reads from the registry; writes decisions per request. Holds what's allowed and who decided.

The registry can be re-implemented or swapped without touching the policy layer (and vice versa). The concepts/certification-as-metadata-not-enforcement property is a direct consequence of this split: certification status flows into the registry as metadata; the registry doesn't enforce certification, the policy layer does.

"The registry itself isn't a governance layer, but it is what makes governance possible. When every tool an agent can use is registered with ownership, version, and review status, the governance layer has something concrete to enforce against. Without that context, policy has to be reimplemented by every consuming team, and consistency becomes impossible."

Generalises beyond tool registries

The pattern recurs across infrastructure layers:

  • Service catalogs (Backstage) — IDP framework's premise: an organisation's services are ungovernable without an inventory; ownership / dependencies / on-call / runbooks all attach to entries in the catalog.
  • API catalogs (RFC 9727) — public HTTP APIs need a discovery primitive before agents can reliably consume them; "ask the human to paste the spec URL" is not a scalable substitute.
  • MCP registries (concepts/mcp-registry) — the protocol-scoped instance of this pattern at the MCP layer; canonicalised at Pinterest as "the source of truth for which MCP servers are approved and how to connect to them."

In every case the registry is infrastructure — the substrate that allows governance to be a policy decision rather than a discipline-and-vigilance project.

  • vs concepts/centralized-ai-governance: centralised AI governance is the enforcement pattern (one policy surface for security/audit, cost, observability); registry-as- precondition is the inventory primitive that pattern depends on. The two compose: centralised governance with no registry is unrunnable; a registry with no centralised governance is inert.
  • vs concepts/separation-of-duties-data-governance: separation-of-duties at the data layer separates the user who tags data from the user who writes policies against tags; registry-as-precondition is the substrate-layer sibling separating the inventory from the enforcement. Both are applications of the same separation-of-concerns argument.
  • vs service discovery at the runtime layer: service discovery answers "where is service X right now?" for request routing; the registry-as-precondition primitive answers "does service X exist and what's known about it?" for governance and forensics. Service discovery is request-path; the registry is policy-path + audit-path.

Seen in

Last updated · 542 distilled / 1,571 read