Agent registry as a governance control plane
AI Platform & MLOps

A Catalogue So You Know Which Agents Exist Before They Bill You

The agent registry — and the one question that tells you whether yours is telling the truth.

Core Concept

An agent registry is a control plane for models, agents and their tools: a single inventory recording which agents exist, which model version each one calls, what permissions and data it may touch, and who owns it.

It exists because an agent is not one deployment. It is a model endpoint plus a tool list plus a set of credentials — and each of those three can be changed independently, by a different team, without anyone editing a shared file. The registry is the row that holds all three together.

Key Components

The Inventory Row

One entry per agent: identity, model version, tool list, permitted data, owner. If it isn't a row, it isn't governed.

Three Moving Parts

Endpoint, tools, credentials. Three independent change surfaces — which is exactly why one place has to record their current combination.

The Join Key

Attach the IAM role and the spend limit to the registry entry, not to a scattered set of API keys. Policy binds to identity, not to secrets.

Query, Not Investigation

“What is running, on whose behalf, against which model?” becomes a lookup that returns in a second instead of a week of Slack archaeology.

How It Works

  1. An agent is enrolled: it gets a registry entry naming its model version, its tools, its data scope and its owner.
  2. Governance objects are bound to that entry — an IAM role for what it may reach, a spend limit for what it may cost.
  3. Invocations go through the control plane, so the entry is also the point where usage and access are observed.
  4. A model version bump, a new tool, or a rotated credential updates the row — the estate stays answerable as a query rather than an investigation.

Where You Meet It

  • Cloud agent platforms (AWS-style agent registries, Azure AI catalogues) selling exactly this control-plane story.
  • Cost attribution — answering “which agent produced this month's model bill” without grepping invoices.
  • Audit and compliance — showing an auditor which automated actors could touch customer data, and under whose ownership.
  • Model deprecation — finding every agent still pinned to a version that is about to be retired.

Falsification — Read This Twice

A registry is an inventory, and an inventory is only as true as its enrolment.

Anything invoking a model endpoint directly, with its own key, is invisible to the registry. The dashboard then reports a clean, fully governed estate — while the real spend and the real data access sit entirely outside the picture.

That failure is worse than having no registry at all, because a governance tool that is confidently incomplete ends the search. Nobody goes looking once the screen says green.

It is also a lock-in surface: the entry describes your agents in one vendor's vocabulary, and that vocabulary becomes your migration cost.

The test Point a script at the raw model endpoint using a personal credential. Then check whether the registry ever notices. If it never does, you know precisely what your coverage number is worth.

Checkpoint — answer before you move on

  1. An agent is described as three independently-changeable parts. Name them, and explain why that fact is the argument for a registry. Hint: think about who can change each part, and whether they'd tell each other.
  2. Why attach a spend limit and an IAM role to a registry entry rather than to the API keys themselves? Hint: what survives a key rotation, and what can you query afterwards?
  3. Your registry reports 100% of agents governed. Describe the concrete situation in which that number is true and useless — and the one test that would expose it. Hint: coverage is measured over the enrolled set, not over reality.