The enterprise MCP registry: governing which tools an agent may ever call
Package registries took fifteen years and several supply chain crises to develop governance. Enterprise agent tool catalogues are being assembled now, at speed, with a wiki page for approvals.
Who approved the tools your agents can call?
Usually nobody, individually. An agent's capability is the union of the tools it can reach, and enterprises are assembling tool catalogues with no record of who approved each server or which consequences each tool can cause. The catalogue grows by addition and is never reviewed as a whole.
- Tool registries are built for discovery: name, description, schema. Approval is a wiki page, so an agent runtime cannot enforce it.
- The package registry precedent tells you what happens next: typosquatting, dependency confusion, maintainer compromise, and eventually mandatory provenance.
- A signed registry entry carrying approver, consequence class, schema hash and expiry makes approval enforceable rather than advisory.
Part of Machine and signing identity
The base rate from an adjacent ecosystem
Package registries are the closest historical analogue and their trajectory is well documented. Open publishing, rapid adoption, then a predictable sequence of abuse patterns: typosquatting, dependency confusion, maintainer account compromise, and malicious updates to previously benign packages.
The governance response came later and arrived in a recognisable order: namespace reservation, two-factor requirements for publishers, provenance attestation, and eventually organisational allowlists.
Enterprise tool catalogues for agents are at the first stage of that sequence. Assuming they will skip the middle is not a forecast anyone should make.
What a tool registry entry contains today
Name, description, transport details, and a schema describing the tools the server exposes. That is sufficient for discovery, which is what the format was designed for.
What it does not contain is anything an agent runtime could use to enforce a governance decision:
| Question | Answerable from the registry? |
|---|---|
| Who approved this server for enterprise use? | No |
| What consequence class is it cleared for? | No |
| Has the schema changed since approval? | No |
| When does the approval expire? | No |
| Which agents may call it, in which contexts? | No |
Why the wiki page fails
Approvals recorded outside the registry cannot be enforced by anything that reads the registry. An agent platform that wants to permit only approved tools must reimplement the approval list as an allowlist in configuration, which then drifts from the wiki.
That drift is not hypothetical. It is exactly what happened with package allowlists before provenance attestation existed, and it is why the eventual answer was to put the assertion in the artefact rather than beside it.
The signed registry entry
{
"type": "manav-stmt/1",
"action": "tool_server_approval",
"server": "[name, endpoint, operator]",
"schema_hash": "[hash of the tool definitions as approved]",
"consequence_class": "[read_only | internal_write | external | financial]",
"permitted_contexts": "[agent classes, environments]",
"review": "[security review reference]",
"notAfter": "[expiry]",
"approver": "[credential assertion, role]"
}The schema hash is what makes this enforceable over time. A tool server whose definitions change after approval — new tools added, parameters widened — no longer matches its approval, and the runtime can detect that without anyone reviewing a changelog.
Consequence classes, which do the governance work
A single approved or not-approved flag is too coarse. The useful construct ties a server's clearance to the class of action its tools can take.
- Read-only internal. Documentation search, internal knowledge retrieval. Low review burden, broad availability.
- Internal write. Ticket creation, record updates. Moderate review, restricted to agent classes that need it.
- External communication. Email, messaging, anything visible outside the organisation. Higher review, narrow contexts.
- Financial or infrastructure. Payments, provisioning, production changes. Highest review, explicit per-agent grant.
An agent runtime can then enforce a policy such as customer-facing agents may only call servers cleared for read-only internal, which is currently expressible only as a hand-maintained list.
Migrating from the wiki
- Export the current approval list. It will be incomplete relative to what agents actually call — compare against runtime telemetry.
- Assign a consequence class to each server based on its tool definitions, not its description.
- Have the approver of record sign each entry. Where there is no approver of record, that server needs a review, not a signature.
- Set expiry by class: shorter for higher consequence.
- Configure the runtime to check the signature and the schema hash before invocation.
Step one produces the finding that makes the case. The gap between the approval list and the servers agents actually reach is typically large, and it exists in every organisation that has moved quickly here — which is all of them.
What a registry entry should record
| Field | Why |
|---|---|
| Who approved this server | A named person, not a ticket |
| Schema hash at approval | So drift is detectable |
| Consequence class per tool | Read, write, irreversible |
| Which agents may reach it | Not every agent needs every tool |
| Review date | So the catalogue is assessed, not just appended to |
Objections and honest limits
“We review tools before adding them.” Individually, which is right and insufficient. The question nobody asks is what the union permits, and that is the agent's real capability.
“Consequence classification is subjective.” Reversibility is not. Ask whether the effect can be undone from inside the system; that single question sorts most catalogues adequately.
Governing a tool registry
- Record who approved each server, by name. Not a ticket reference.
- Pin the schema hash at approval. And fail closed on drift.
- Classify each tool by reversibility. One question, answered per tool.
- Review the union, not the additions. What can this agent do, in total?
Terms used here
- Tool registry
- The catalogue of tools and servers an agent may call — in effect, its capability definition.
- Schema drift
- A tool's declared interface changing after approval, which inherits the original trust unless detected.
- Consequence class
- Whether a tool reads, writes, or causes effects that cannot be undone from inside the system.
Frequently asked questions
Is this not premature for an early ecosystem? The package registry precedent suggests the opposite: governance added after widespread adoption is far more expensive than governance added during it.
What if a tool server legitimately adds tools? The schema hash changes, the approval no longer matches, and a re-approval is required. That is the intended behaviour — added tools are added capability.
Does this require changes to the protocol? No. The approval artefact sits alongside the registry entry and is checked by the runtime before invocation.
Who should approve? Security review for the consequence class, and a business owner for the need. Both should be named in the entry.
Why review the union rather than each addition? Because the union is the agent's actual capability, and nobody approved it. Each addition was assessed alone.
Is consequence classification subjective? Reversibility is not. Ask whether the effect can be undone from inside the system; that sorts most catalogues.
What should happen on schema drift? Fail closed. A changed tool definition should require a new approval rather than inheriting the old one.
Where this fits in Manav
Manav anchors machine and agent authority to a named human through a signed delegation with scope, depth and enforced revocation — so an action at hop four still resolves to a person.
Sources and further reading
- Model Context Protocol specification
- npm — security best practices for package publishing
- Reported incidents involving agent tool misuse and scope-blind approvals.
- FTC — business guidance on marketplaces and consumer protection
- OWASP — Non-Human Identities Top 10