Conectaste tu agente de IA a Slack, GitHub y Jira. La plataforma mostró un diálogo amable: "¿Permitir acceso a Slack?" Hiciste clic en sí. Te sentiste responsable. Te sentiste en control.
No lo estabas. El agente acaba de enviarle un DM a tu CEO con un borrador de reporte de bugs que iba para #engineering. La puerta de permisos nunca preguntó sobre destinatarios, canales, ni qué significa realmente "acceso a Slack" cuando una máquina tiene las llaves.
Tres plataformas, un patrón, cero profundidad
Hace dos semanas, la discusión giraba en torno a plataformas de agentes que carecían de autorización real — agentes con acceso root y nadie construyendo sudo. Esa conversación ya quedó obsoleta. Las tres principales plataformas ya enviaron su respuesta: flujos de aprobación de herramientas, esos prompts de "¿Estás seguro?" que aparecen antes de que un agente de IA (un programa que actúa en tu nombre, no solo chatea) haga algo con consecuencias. La brecha de autorización no se llenó. Se empapeló.
Google ADK agregó confirmaciones de acciones en Cloud Next (22–24 de abril). Managed Agents de Anthropic, lanzado el 8 de abril, incluyó políticas de permisos por herramienta desde el día uno. El Agents SDK de OpenAI publicó callbacks needs_approval en su actualización del 15 de abril. Tres empresas convergiendo en la misma idea — como tres arquitectos diseñando independientemente el mismo techo con goteras.
El patrón es idéntico en las tres: apruebas o niegas acceso a nivel de herramienta. "Permitir Slack" o "Denegar Slack." Binario. Encendido o apagado. Un guardia revisando credenciales en la entrada del edificio mientras cada puerta de departamento adentro queda abierta de par en par.
Donde realmente vive el peligro
El radio de explosión de una mala llamada a herramienta — el daño que realmente puede causar — vive en los parámetros: a qué canal de Slack va el mensaje, a qué rama de Git alguien hace force-push, qué query SQL se ejecuta contra tu base de datos de producción, qué proyecto de Jira el agente inunda con tickets autogenerados.
Para ser justos, Google ADK y OpenAI sí pasan los parámetros de la llamada a callbacks escritos por el desarrollador. Puedes escribir código como return amount > 1000 para bloquear operaciones costosas. Pero aquí está la distinción crítica: la plataforma te da un hook, no una red de seguridad. Tú escribes las reglas, en Python crudo, para cada herramienta, para cada parámetro, para cada caso límite. Sin motor de políticas declarativas. Sin allowlists integradas. Sin un toggle de "solo publicar en #engineering y #random" en un dashboard.
La implementación de Anthropic es aún más simple — sus políticas de permisos operan puramente sobre nombres de herramientas. El evento user.tool_confirmation acepta exactamente dos respuestas: "allow" o "deny". Sin campo para restricciones de argumentos. Sin lógica condicional. El agente puede usar Slack o no puede.
Como escribió el investigador de seguridad Simon Willison en septiembre de 2024: "Una vez que un agente LLM ha ingerido input no confiable, debe estar restringido de modo que sea imposible que ese input dispare cualquier acción con consecuencias." Las puertas a nivel de herramienta no logran eso. Restringen qué acciones existen, no qué hacen esas acciones.
Ya vimos esta película
El patrón es un copy-paste de los permisos móviles circa 2008. Android 1.0 otorgaba acceso total a la "cámara" — sin distinción entre una app de selfies y un escáner de documentos fotografiando silenciosamente tu escritorio. A Google le tomó siete años y Android 6.0 Marshmallow (2015) para implementar permisos con alcance en tiempo de ejecución — controles contextuales sobre cómo una app usa la cámara, no solo si puede.
Las plataformas de agentes están en la etapa de Android 1.0 hoy. El diálogo de permisos existe. Se siente como seguridad. No lo es.
Microsoft dijo en voz alta lo que todos piensan
El 22 de abril, el blog de desarrolladores de Microsoft publicó una admisión contundente: "Seguir instrucciones por sí solo no debería tratarse como una frontera de seguridad." Su propio red-team testing — realizado como parte del Agent Governance Toolkit que liberaron como open source a principios de mes — reveló una tasa de violación de políticas del 26.67% al usar guardarraíles basados solo en prompts. Una de cada cuatro llamadas peligrosas se cuela si confías en que el LLM se vigile a sí mismo.
AGT es lo más cercano a una solución real: una capa de middleware que se sienta entre tu agente y sus herramientas, aplicando reglas de políticas declarativas escritas en YAML, OPA o Cedar. Realmente inspecciona parámetros. Realmente filtra basándose en valores de argumentos. Pero es middleware que tú mismo atornillas — no es nativo de ninguna plataforma de agentes. Buena cinta adhesiva, pero cinta adhesiva al fin.
El precio de hacerlo bien
El filtrado a nivel de parámetros es genuinamente difícil. Requiere comprensión semántica — saber que #general es un canal público mientras que #compensacion-ejecutivos no lo es. Agrega latencia a cada llamada de herramienta en sistemas que ya pelean con los límites de la ventana de contexto (cuánto texto puede "ver" la IA a la vez). Y lo peor de todo, crea fatiga de aprobación: cuanto más granulares son las puertas, más rápido los usuarios se entrenan para hacer clic en "aprobar todo" sin leer — exactamente el comportamiento que convierte los permisos en teatro.
Lo que realmente deberías hacer
Hasta que las plataformas implementen filtrado consciente de parámetros como función nativa, tienes dos opciones honestas. Una: construir middleware que verifique los argumentos de las llamadas contra allowlists — canales seguros, ramas seguras, patrones de queries seguros. Dos: aceptar que hacer clic en "Permitir Slack" significa "permitir que el agente haga cualquier cosa que soporte la API de Slack," y planificar en consecuencia.
El diálogo de permisos de tu plataforma de agentes es un placebo. Controla qué puertas puede abrir el agente, pero no qué hace el agente dentro del cuarto. Tres plataformas lanzaron la misma cerradura en abril de 2026, y ninguna incluyó el cerrojo.
