An AI agent tool registry is the operating inventory of every tool an agent can use, what the tool can change, who owns it, what evidence is required, and when a human must approve the action. Without one, agent governance becomes vibes, screenshots and one very nervous founder asking why the CRM has 700 identical notes.
Why tool registries matter now
The first wave of business AI was mostly chat. The risk was bad advice, weak drafts and hallucinated confidence. Annoying, but contained.
The next wave is tool-using agents. These agents can read documents, send emails, update tickets, create invoices, change pages, query customer data, schedule workflows and call APIs. That is useful. It is also a permission problem wearing a productivity hat.
A founder does not need a 90-page AI governance policy before using agents. They need a control surface that answers basic questions quickly:
- Which tools does each agent have?
- What can each tool read?
- What can it write?
- What needs approval?
- Who owns the tool?
- What gets logged?
- How do we roll back a bad action?
- When was access last reviewed?
That control surface is the tool registry.
The principle is similar to search fundamentals: Google Search Central documentation for AI features still points site owners back to crawlable, helpful, well linked pages, and the Google SEO Starter Guide rewards basics that machines can inspect. Agent operations need the same plain control layer: visible permissions, source records and reviewable changes.
What belongs in an AI agent tool registry
A useful registry is not a pretty spreadsheet nobody opens. It is a working operational asset.
The registry also needs a decision history. When an agent receives a new tool, record why access was granted, who approved it, what test proved the tool was safe enough, and what event should remove that access. That small history prevents a common founder problem: nobody can tell whether a permission still serves the business or simply survived because it was easier not to touch it.
Each tool record should include:
- Tool name.
- Tool category, such as read-only, draft, write, publish, payment or admin.
- Connected system, such as CRM, CMS, email, Drive, GitHub, database or analytics.
- Agent profiles allowed to use it.
- Read scope.
- Write scope.
- Data sensitivity.
- Risk tier.
- Required approval gate.
- Required evidence before action.
- Log location.
- Rollback path.
- Named owner.
- Review cadence.
If that sounds bureaucratic, good. Autonomy without bureaucracy is just improvisation with API keys.
The five tool risk tiers
Use simple tiers. If your team needs a consultant to understand the model, the model will not survive a busy Tuesday.
Tier 0: Observe
The agent can inspect public or low-risk internal information. Examples include reading public pages, checking sitemap status or summarising non-sensitive documentation.
Control needed:
- Basic logging.
- No approval for routine reads.
- Clear exclusion for secrets and private customer data.
Tier 1: Draft
The agent can create drafts but cannot publish or send them. Examples include blog drafts, email drafts, support reply suggestions and issue summaries.
Control needed:
- Draft location.
- Human review before external use.
- Source notes when claims matter.
Tier 2: Internal write
The agent can update internal systems with reversible changes. Examples include adding task comments, updating labels, writing staging files or creating internal reports.
Control needed:
- Change log.
- Owner visibility.
- Rollback route.
- Scheduled access review.
Tier 3: External write
The agent can affect customer-visible surfaces. Examples include publishing posts, sending emails, updating website pages or changing product information.
Control needed:
- Human approval for first use and high-risk changes.
- Pre-action evidence pack.
- Live QA.
- Rollback plan.
- Incident trigger if QA fails.
Tier 4: Financial, security or destructive action
The agent can move money, delete production data, alter credentials, change security settings or perform irreversible actions.
Control needed:
- Default deny.
- Named human approval.
- Multi-party review for destructive operations.
- Immutable audit trail.
- Tested rollback or explicit no-rollback acknowledgement.
This is where founders should be boring. Boring keeps companies alive.
How a registry stops permission drift
Permission drift happens when agents gain access for a specific reason and never lose it. A tool is added during an emergency. A temporary workflow becomes permanent. A sandbox credential quietly becomes production. Nobody meant to create risk. They just failed to clean up.
A registry fights drift in three ways:
- It shows current access in one place.
- It ties every tool to an owner.
- It forces periodic review based on risk tier.
Suggested review cadence:
- Tier 0: quarterly.
- Tier 1: quarterly.
- Tier 2: monthly.
- Tier 3: monthly, plus after major incidents or workflow changes.
- Tier 4: before every use, with formal review monthly if enabled at all.
Access reviews are not glamorous. Neither are smoke alarms. Install both.
What evidence should an agent provide before using a tool
For low-risk reads, a trace is enough. For customer-visible changes, the agent should provide an evidence pack before the action.
A good evidence pack includes:
- Intended action.
- Source evidence used.
- Files or records to be changed.
- Risk tier.
- Approval rule.
- Expected result.
- Rollback path.
- QA checks after action.
This evidence pack should be readable by a non-technical operator. If only the engineer who built the agent understands the action, the agent is not governed. It is merely surrounded by code.
The minimum viable registry for founders
Do not start with software procurement. Start with a simple registry and a weekly review.
The minimum viable version has seven columns:
- Tool.
- System.
- Agent allowed.
- Read scope.
- Write scope.
- Risk tier.
- Owner.
Then add three operational columns:
- Approval rule.
- Log location.
- Rollback path.
That is enough to expose most dangerous gaps. If you cannot fill those fields, the agent should not have the tool yet.
How tool registries connect to AAO
Assistive Agent Optimisation is not about making agents busier. It is about making autonomous work measurable, recoverable and trusted.
The tool registry connects to the rest of AAO:
- Permission architecture defines what access is allowed.
- Access reviews check whether access still makes sense.
- Audit trails prove what happened.
- Human approval gates stop risky actions before they run.
- Observability shows whether tools are failing or drifting.
- Incident response defines what happens when the registry was wrong.
The registry is the map. The other controls are how you drive without ending up in a ditch.
Common mistakes
Mistake 1: Treating all tools as equal
A read-only sitemap fetch is not the same risk as a WordPress publish call. If they sit in the same permissions bucket, the bucket is broken.
Mistake 2: Naming the tool but not the scope
"Google Drive" is not a permission. Which folder? Read or write? Can it share files? Can it delete? Can it see client documents? Scope is the control.
Mistake 3: No named owner
Every tool needs a human owner. Not a department. Not "ops". A person. Ownership that cannot be named cannot be enforced.
Mistake 4: Approval gates without evidence
Asking a human to approve a vague action is not governance. It is liability transfer. The agent must show what it plans to do and why.
Mistake 5: No rollback path
If an action cannot be rolled back, the registry should say so clearly. That does not automatically ban the tool, but it changes the approval threshold.
FAQ
Is a tool registry only for large companies?
No. Small teams need it sooner because one agent can touch a large share of the business. A ten-row registry is better than a hundred Slack messages nobody can search under pressure.
Should founders let agents publish directly?
Only after the workflow has passed staging, duplicate checks, live QA and rollback tests. First publish per surface should have human approval. Routine low-risk publishes can later move to governed autonomy.
What is the difference between a tool registry and an access review?
The registry is the current map of tools, scopes and owners. The access review is the recurring check that asks whether the map is still correct.
Where should the registry live?
Put it where operators already work: a sheet, database, ticketing system or internal control file. The format matters less than ownership, review cadence and accuracy.
What should be blocked by default?
Credential changes, destructive deletes, payment actions, production database writes, security configuration changes and customer-visible bulk actions should be blocked unless a named human approves with evidence.
Conclusion
AI agent safety starts with knowing what agents can touch. A tool registry gives founders that map. It will not make agents perfect, but it will make their actions visible, reviewable and recoverable. That is the difference between useful autonomy and a very expensive magic trick.
If your agents already use tools, build the registry before you add another integration.