El antídoto correcto al agente con demasiada cuerda: poner un portero delante de las herramientas
La idea de fondo es simple y muy sana: si un agente puede llamar herramientas, no le dejes hacerlo sin control. El valor no está en “darle menos poder por miedo”, sino en separar intención, validación y ejecución para que el sistema siga siendo útil cuando algo sale mal.
📰 Qué ha pasado
El artículo cuenta que su autor dejó de confiar en agentes de IA con herramientas sueltas y decidió montar una capa intermedia, un “portero”, para controlar qué pueden hacer realmente. En vez de permitir tool calls directos y sin filtro, introduce un punto de control entre el agente y las acciones sensibles. El enfoque es práctico y va al problema central: un agente puede ser muy útil y, a la vez, muy peligroso si tiene demasiada libertad. La tesis es clara: no basta con que el modelo “quiera” hacer lo correcto; hay que impedir que pueda equivocarse de forma costosa.
🧭 El contexto: por qué ahora
Esto encaja con una realidad que cualquiera que haya montado automatizaciones serias conoce bien: el problema no es solo que el modelo alucine, sino que ejecute. En cuanto un agente puede tocar correo, tickets, cloud, repos o bases de datos, el riesgo deja de ser teórico y pasa a ser operativo. Durante mucho tiempo el discurso ha ido por delante de la arquitectura: se habla de agentes autónomos como si fueran asistentes, pero en producción se comportan como sistemas con permisos. Por eso están apareciendo patrones de guardrails, policy engines, validadores de intención y capas de aprobación. No es glamour; es ingeniería básica aplicada a un sistema probabilístico.
🎯 A quién le afecta y cómo
- Si montas agentes en producción: necesitas una capa de autorización y validación antes de cada acción sensible, no solo prompts mejores.
- Si das acceso a herramientas internas: revisa qué operaciones son realmente necesarias y cuáles deberían requerir confirmación humana.
- Si trabajas en seguridad: este patrón te obliga a modelar el agente como un actor con permisos limitados, logs y trazabilidad.
- Si lideras plataforma o SRE: te interesa porque reduce el radio de explosión de fallos automáticos y hace más auditable el comportamiento.
- Si haces producto con IA: te marca la diferencia entre una demo vistosa y un sistema defendible ante incidentes.
⚖️ Nuestra opinión
Criterio propio, sin nota de prensa: lo bueno, lo malo y lo que haríamos nosotros.
La propuesta es buena porque ataca el fallo estructural de muchos agentes: se les pide autonomía sin haber resuelto el control. Un “portero” delante de las herramientas no es una sofisticación innecesaria; es la forma correcta de introducir política, límites y observabilidad. Además, obliga a diseñar mejor la experiencia del agente: qué puede pedir, qué puede ejecutar y qué necesita escalar. Eso suele mejorar el sistema entero, no solo la seguridad.
La parte menos bonita es que este enfoque añade fricción, latencia y complejidad. Y sí, eso mata parte del relato de “agente mágico que lo hace todo solo”. Pero precisamente ahí está la madurez: si una automatización solo funciona cuando no la miras de cerca, no es un producto serio. El error habitual es confundir autonomía con ausencia de control; en realidad, cuanto más poder das, más disciplina necesitas en el perímetro.
Nosotros haríamos esto: poner una política explícita por tipo de herramienta, con acciones permitidas, umbrales de riesgo y aprobaciones para operaciones destructivas o irreversibles. Luego añadiríamos logs estructurados de intención, decisión y ejecución para poder auditar cada tool call. Y, sobre todo, empezaríamos por limitar el agente a un subconjunto pequeño de acciones de bajo impacto hasta demostrar que no necesita más.
✅ Qué hacer con esto
Acciones concretas si esto te toca de cerca.
- Inventariar todas las herramientas a las que puede llamar tu agente y clasificarlas por riesgo: lectura, escritura, borrado, gasto, acceso externo.
- Introducir una capa de autorización intermedia que valide cada acción antes de ejecutarla, aunque sea una implementación sencilla al principio.
- Registrar en logs estructurados la intención del agente, el payload de la tool call y el resultado final para poder auditar incidentes.
- Definir un modo de confirmación humana para operaciones irreversibles o con impacto económico/seguridad.
- Reducir permisos por defecto y probar el agente en un entorno de staging con datos simulados antes de abrirlo a producción.