Problem
Enterprises talk a lot about models and little about tools. That’s a mistake.
An agent without tools can get a response wrong. An agent with tools can delete, send, purchase, transfer, publish, deploy, edit, or execute. Risk no longer lives only in verbal output and moves to the action surface.
When hundreds of MCP servers, internal APIs, skills, scripts, and connectors appear, the critical question isn’t “what model do we use.” It’s “what can the agent do and who knows it.”
Thesis
Every company that deploys agents needs a Tool Registry.
Not a decorative list of integrations. A living register of capabilities: which tool exists, who the owner is, what permissions it has, what data it touches, what actions it permits, what risk it carries, how it’s tested, and how it’s turned off.
Without a register, the organization has no agents. It has shadow automation.
Framework
A tool registry must store seven minimum fields:
- Owner: team responsible for the tool.
- Scope: what it can read, write, or execute.
- Risk: low, medium, high or critical according to reversibility and impact.
- Authorization: which role, user, or agent may invoke it.
- Evidence: logs, traces and expected outputs.
- Version: contract, parameter and permission changes.
- Kill switch: how to deactivate the tool without breaking everything.
Mini‑case: an operations agent has access to calendar, CRM, billing, and email. Each tool looks innocent in isolation. Combined, they allow sending an incorrect offer, updating deal stage, and firing a invoice. The risk isn’t in a single tool; it’s in the chain.
Measurable signal: percentage of tools invocable by agents with owner, scope, risk, and kill switch documented.
Position: the new security inventory isn’t just about applications. It’s about agentic capabilities.
Why it matters now
The AI Security Institute analyzed 177,436 agentic tools published between November 2024 and February 2026 by monitoring public MCP repositories. Its reading is relevant: the ecosystem grows fast, agents move from observing to acting, and action tools in loosely‑restricted environments gain weight.
The Model Context Protocol itself includes specifications and authorization and security guides, focusing on OAuth, secure token storage, scopes, and dangerous patterns such as commands with file‑system, network, or execution access.
The conclusion is simple: the tool layer is already a governance surface.
Anti‑example
“The agent only uses approved tools.”
That sentence means nothing if you can’t answer which version of the tool, what scopes it has, who approved it, what changes it underwent, what traces it leaves, and how it’s deactivated. Approval without inventory ages poorly.
Protocol (3 steps)
- Classify by action, not by name. “CRM tool” says nothing; “updates opportunity and sends email” does.
- Assign risk to chains. Two low‑risk tools can form a critical action together.
- Audit dormant tools. If a tool isn’t used, isn’t maintained, or has no owner, it should expire.
| Field | Question | Risk if missing |
|---|---|---|
| owner | who answers | nobody corrects |
| scope | what it can do | excessive permissions |
| version | what changed | invisible regression |
| trace | what it did | no audit |
| kill switch | how to turn off | prolonged incident |
Related
- MCP in enterprise: the standard that prevents agent chaos
- AWS MCP Server GA: when coding agents enter cloud with guardrails
- Microsoft Agent 365: the control plane that turns shadow AI into inventory
Sources consulted
- AISI: How are AI Agents used? Evidence from 177,000 AI agent tools
- Model Context Protocol: Authorization
- Model Context Protocol: Security best practices
Next step
Create an inventory of ten tools that your agents can already call. If you can’t classify owner, scope, risk, and kill switch in an afternoon, the problem isn’t lack of AI; it’s lack of a control plane.
Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.