Problema
Las empresas hablan mucho de modelos y poco de herramientas. Es un error.
Un agente sin herramientas puede equivocarse en una respuesta. Un agente con herramientas puede borrar, enviar, comprar, transferir, publicar, desplegar, editar o ejecutar. El riesgo deja de vivir solo en el output verbal y se mueve a la superficie de accion.
Cuando aparecen cientos de MCP servers, APIs internas, skills, scripts y conectores, la pregunta critica no es “que modelo usamos”. Es “que puede hacer el agente y quien lo sabe”.
Tesis
Toda empresa que despliegue agentes necesita un Tool Registry.
No una lista decorativa de integraciones. Un registro vivo de capacidades: que herramienta existe, quien es owner, que permisos tiene, que datos toca, que acciones permite, que riesgo tiene, como se prueba y como se apaga.
Sin registro, la organizacion no tiene agentes. Tiene shadow automation.
Framework
Un tool registry debe guardar siete campos minimos:
- Owner: equipo responsable de la herramienta.
- Scope: que puede leer, escribir o ejecutar.
- Riesgo: bajo, medio, alto o critico segun reversibilidad e impacto.
- Autorizacion: que rol, usuario o agente puede invocarla.
- Evidencia: logs, traces y outputs esperados.
- Version: cambios de contrato, parametros y permisos.
- Kill switch: como desactivar la herramienta sin romper todo.
Mini-caso: un agente de operaciones tiene acceso a calendario, CRM, facturacion y email. Cada tool parece inocente aislada. Combinadas, permiten enviar una oferta incorrecta, actualizar deal stage y disparar una factura. El riesgo no esta en una tool; esta en la cadena.
Senal medible: porcentaje de herramientas invocables por agentes con owner, scope, riesgo y kill switch documentados.
Postura: el nuevo inventario de seguridad no es solo de aplicaciones. Es de capacidades agenticas.
Por que importa ahora
El AI Security Institute analizo 177.436 herramientas agenticas publicadas entre noviembre de 2024 y febrero de 2026 monitorizando repositorios MCP publicos. Su lectura es relevante: el ecosistema crece rapido, los agentes pasan de observar a actuar, y las herramientas de accion en entornos poco restringidos ganan peso.
El propio Model Context Protocol incluye especificaciones y guias de autorizacion y seguridad, con foco en OAuth, almacenamiento seguro de tokens, scopes y patrones peligrosos como comandos con acceso a sistema de archivos, red o ejecucion.
La conclusion es simple: el tool layer ya es una superficie de gobierno.
Anti-ejemplo
“El agente solo usa herramientas aprobadas.”
Esa frase no significa nada si no puedes responder que version de la herramienta, que scopes tiene, quien aprobo, que cambios tuvo, que trazas deja y como se desactiva. La aprobacion sin inventario envejece mal.
Protocolo (3 pasos)
- Clasifica por accion, no por nombre. “CRM tool” no dice nada; “actualiza oportunidad y envia email” si.
- Pon riesgo a cadenas. Dos herramientas de bajo riesgo pueden formar una accion critica juntas.
- Audita herramientas dormidas. Si una tool no se usa, no se mantiene o no tiene owner, debe caducar.
| Campo | Pregunta | Riesgo si falta |
|---|---|---|
| owner | quien responde | nadie corrige |
| scope | que puede hacer | permisos excesivos |
| version | que cambio | regresion invisible |
| trace | que hizo | no hay auditoria |
| kill switch | como apagar | incidente prolongado |
Relacionado
- MCP en empresa: el estandar que evita el caos de agentes
- AWS MCP Server GA: cuando los agentes de coding entran en cloud con guardrails
- Microsoft Agent 365: el control plane que convierte shadow AI en inventario
Fuentes consultadas
- AISI: How are AI Agents used? Evidence from 177,000 AI agent tools
- Model Context Protocol: Authorization
- Model Context Protocol: Security best practices
Proximo paso
Haz inventario de diez herramientas que tus agentes ya pueden llamar. Si no puedes clasificar owner, scope, riesgo y kill switch en una tarde, el problema no es falta de IA; es falta de control plane.