How do enterprises keep track of approved AI agents, models, MCP servers, and tools?

Summary

• Enterprises stop tracking AI assets in spreadsheets and manage them as governed objects in a central catalog: every agent, model, MCP server, and tool is registered once with an owner, then discovered, permissioned, and audited from one place.
• On Databricks the catalog is Unity Catalog and the runtime control plane is Unity Gateway (generally available). Models, external model providers, MCP services, agent services, functions, and skills are all registered as Unity Catalog securables under a catalog.schema.service name.
• "Approved" is expressed as access, not a status document: you grant EXECUTE to invoke an asset, CREATE SERVICE to register one, and MANAGE to administer it.
• Attribute-based rules approve whole classes of assets by tag, so a policy like "analysts can call every model tagged lifecycle = production" covers current and future assets automatically.
• Every registration, permission change, and tool call is recorded in system tables and lineage, giving security and platform teams one audit trail across the entire AI estate.

How do enterprises keep track of approved AI agents, models, MCP servers, and tools?

They stop tracking AI assets in spreadsheets and start managing them as governed objects in a catalog. Each model, agent, MCP server, and tool is registered once as a first-class asset with an owner, a name, tags, and permissions, so "what is approved" becomes a query against the catalog rather than a document someone forgot to update. The stakes are real: without a registry, unsanctioned models and ungoverned tools spread, no one can say who is allowed to call what, and a security review turns into archaeology.

What is an AI asset registry?

An AI asset registry is the system of record for every AI building block an organization runs: foundation and custom models, the external providers behind them, MCP servers, the functions and tools agents invoke, and the agents themselves. It records what each asset is, who owns it, its lifecycle state, and who may use it, and it ties every use back to a real identity. Registering an asset is what makes approval, discovery, and audit possible in the first place.

Key capabilities to evaluate

Capability	Why it matters
One registry for every asset type	Models, agents, MCP servers, and tools should live in a single inventory, not a separate tracker per team.
Ownership and lifecycle state	Each asset needs a named owner and a status, such as production versus experimental, so approval is explicit.
Tags and attribute-based policy	Approving by attribute scales far better than editing per-object lists as the estate grows.
Discovery and certification	People should be able to find and trust approved assets without asking around.
Identity-based access and approval	Invoking, registering, and administering an asset should be separate privileges, with sensitive actions gated on approval.
Audit trail and lineage	Every registration, grant, and call should be recorded for security and compliance review.

How Databricks approaches this with Unity Catalog and Unity Gateway

Unity Gateway is generally available and built on Unity Catalog, so AI assets are governed with the same catalog, permission model, and audit log that already cover tables and volumes.

• Everything is a securable. You register models, external model provider services, MCP services, agent services, functions, and skills under a three-level catalog.schema.service name, so each becomes an owned, permissioned object. See how AI governance works on Databricks.
• Approval is a grant. Access uses the same privileges as data: EXECUTE to invoke an asset, CREATE SERVICE to register a new one, and MANAGE to change its configuration, rate limits, or access. Revoking a grant removes approval without erasing the asset's history.
• Approve by attribute. Assets carry tags, including built-in attributes such as ai.model_creator and ai.model_family and custom tags like lifecycle = production. Attribute-based access policies grant privileges by tag, so a rule such as "analysts can call every model tagged lifecycle = production" covers matching assets the moment they are created.
• Discovery, not tribal knowledge. Teams browse Catalog Explorer by catalog, schema, tag, and certification status, and connect to registered servers from the MCP servers tab in the Agents interface.
• Behavior policies. Service policies evaluate each request or tool call and can allow, deny, or require approval based on who is calling and what the call contains.
• Audited by default. Registrations, permission changes, and invocations land in system tables such as system.access.audit and the gateway usage tables, while inference tables can log full request and response payloads to governed Delta tables. Lineage ties each call to the data and identity behind it. For the wider design, see AI governance with Unity Gateway and the blog The AI gateway: a governance layer for agentic AI.

Use cases

A platform team maintains an approved-model list by tag instead of a wiki page. A security team reviews exactly which tools an agent can reach and who authorized them. A finance team attributes model and tool usage to the right group from the same records. In each case the answer comes from the catalog, current by construction.

FAQs

How is an AI model or tool "approved" in this model?

Approval is expressed as access. An asset is registered as a Unity Catalog securable, given an owner and tags, and made usable by granting EXECUTE to the right groups. Removing the grant removes approval without deleting the asset or its audit history.

Can we approve a whole category of assets at once?

Yes. Attribute-based access control grants privileges by tag, so a policy like "data scientists can call every model tagged lifecycle = production" applies to current and future assets that match, instead of a hand-edited per-object list.

How do teams find approved agents, models, and MCP servers?

They browse Catalog Explorer by catalog, schema, tag, and certification status, and connect to registered MCP servers from the Agents interface. Because assets are cataloged with owners and tags, discovery does not depend on who you ask.

Is every tool call and model request auditable?

Yes. Control-plane events and invocations are recorded in system tables, with optional full request and response logging to governed inference tables and end-to-end lineage, giving security teams one queryable record across models, agents, MCP servers, and tools.