Un agente de IA dormido es una automatización que ya no se ejecuta, pero conserva credenciales, disparadores y permisos activos.
El riesgo no es una rebelión de la máquina: es que la llave siga viva y cualquiera con el disparador pueda usarla. En una pyme eso puede ser un webhook que sigue aceptando pedidos, un token con escritura en el CRM o un correo que nadie revisa.
Qué es un agente dormido y por qué importa
Un agente recibe un evento, decide una acción y la ejecuta con herramientas: leer correos, consultar una base de datos, crear facturas, mover leads o enviar mensajes. En una pyme suele vivir en n8n, Zapier, Make, un cron o un asistente interno conectado por API.
“Dormido” no significa “retirado”. Significa que no hay ejecuciones recientes, pero la definición, la conexión y los secretos siguen ahí. El caso típico: alguien armó un flujo para copiar pedidos del correo al ERP, cambió el proceso y nadie volvió a tocarlo. El flujo quedó apagado; la cuenta de Google, la clave de la API y la URL del webhook quedaron activas.
Conviene separar tres estados:
- Activo con dueño: se ejecuta, tiene responsable y permisos revisados.
- Dormido con dueño: no se usa, pero alguien puede explicar por qué sigue vivo.
- Huérfano: nadie sabe quién lo creó, para qué sirve ni qué puede tocar. Este es el que hay que retirar.
El problema no es la etiqueta de “agente”. Un flujo que solo mueve datos entre dos sistemas corre el mismo riesgo si usa una credencial con permisos de escritura. El inventario debe incluir también automatizaciones sin IA: el acceso es el mismo.
El dato: 76% sin ejecutar y webhooks sin firma
El 2026 Autonomous Agents Threat Report de Arrakis Security, publicado el 22 de octubre de 2026, analizó telemetría de producción de miles de agentes durante 12 semanas. En su muestra, 76% no se ejecutó en 60 días, 44% no lo hizo en 180 días y 24% de los dormidos podía activarse mediante un webhook sin firma. El informe también reporta que 82% tenía al menos una exposición, según la definición del proveedor. Son datos de una muestra propia, no un censo de toda la industria.
El dato de los webhooks es el más incómodo. Un webhook sin firma es una URL que acepta pedidos sin comprobar quién los envía. Si esa URL se filtró en un ticket, un chat o una captura de pantalla, no hace falta entrar a la plataforma: basta con llamarla. Y si el agente tiene permiso para escribir en el CRM o enviar correos, el problema deja de ser teórico.
Más allá del titular, la pregunta útil es concreta: ¿cuántos de mis flujos siguen habilitados aunque nadie los use?
El 26 de octubre de 2026, SK Telecom publicó su primer AI Governance Report y anunció que asigna número de empleado y supervisor humano a sus agentes internos, incluido el retiro de los que no aportan. No hay que copiar el modelo: la idea que vale es simple. Un agente sin dueño no debería seguir operando.
Inventario en una hora: qué revisar agente por agente
Antes de revocar nada, necesitas una lista defendible ante un cliente, un auditor o tu propio equipo. Una plantilla mínima puede ser un CSV como este:
agente,responsable,plataforma,ultima_ejecucion,disparador,identidad,permisos,datos,estado
Si trabajas con n8n y exportas los flujos como JSON, puedes obtener un resumen rápido:
# n8n: nombre, estado y última modificación de cada flujo exportado
jq -r 'if type=="array" then .[] else .workflows[] end | [.id,.name,.active,.updatedAt] | @tsv' flujos.json
El comando asume un arreglo o un objeto con la clave workflows; si tu export tiene otra forma, ajusta la ruta. Para Zapier, Make o un desarrollo propio, exporta la lista y lleva los mismos campos.
Después, en unos 60 minutos:
- Marca la última ejecución. Si no hay registro, escribe “sin telemetría”. Eso ya es un hallazgo: no puedes gobernar lo que no puedes ver.
- Identifica el disparador. ¿Cron, webhook, formulario, correo, mensaje de chat? Anota si exige autenticación o firma.
- Busca al responsable. No sirve “el equipo”. Necesitas un nombre y un correo.
- Sigue la credencial. Qué cuenta usa, dónde está guardada y quién más la conoce.
- Revisa la salida. ¿A quién le llega el resultado? Si nadie lo consume, el retiro es fácil.
- Clasifica: mantener, pausar o retirar. Si no hay ejecuciones en 60 días, no lo borres todavía: márcalo para revisión. A los 180 días, exige una justificación para que siga vivo.
Credenciales, disparadores y permisos heredados
Hay tres preguntas que resuelven la mayoría de los casos:
- ¿Con qué identidad actúa? Lo ideal es una cuenta de servicio dedicada, no la cuenta personal de un empleado.
- ¿Qué puede hacer? No mires solo el nombre del permiso; revisa si puede leer, escribir, borrar o invitar usuarios.
- ¿Quién puede despertarlo? Un webhook público, un formulario abierto o un correo a una dirección conocida son puertas de entrada.
Los permisos heredados son los que más se pasan por alto. Un agente creado para “solo consultar” puede seguir usando una cuenta de administrador porque era la que estaba a mano. Otro puede estar actuando con el token OAuth de alguien que ya salió de la empresa; mientras la autorización no se revoque en el proveedor de identidad, el acceso puede seguir vivo.
También revisa las credenciales que sobreviven al flujo: claves de API, tokens de actualización, contraseñas de aplicación para correo y secretos de webhook. Borrar el flujo en la plataforma puede no revocar la conexión OAuth a nivel de cuenta. Son dos capas distintas y hay que cerrar las dos. La IETF describe el mecanismo estándar para invalidar un token en el RFC 7009; si tu proveedor no lo implementa, tendrás que revocar la concesión desde su panel.
Cómo retirar un agente sin romper el proceso
Retirar no es borrar. El orden importa:
- Nombra un responsable y una fecha de retiro. La fecha puede ser una ventana de gracia de 7 a 14 días; lo importante es que exista.
- Mapea a los consumidores. ¿Quién lee el correo, la hoja o el mensaje que produce? Si el agente falla, ¿quién lo nota y qué hace mientras tanto?
- Pausa el disparador, no borres el flujo. Así compruebas el impacto sin perder la configuración.
- Revoca en el origen. Desactiva la conexión en la plataforma, elimina la concesión OAuth en el proveedor de identidad, deshabilita la clave en el servicio que la emitió y cierra el webhook.
- Rota lo compartido con cuidado. Si el agente usaba una clave que también usan otros sistemas, no la revoques sin saber a quién más afecta.
- Deja una ventana de gracia. Monitorea errores y confirma que el proceso manual o el reemplazo funciona.
- Borra, archiva y documenta. Guarda la configuración, los últimos logs y la decisión. Si alguien pregunta por qué se retiró, debe haber una respuesta.
Un error común es revocar la credencial pero dejar el webhook activo, o borrar el flujo y olvidar la autorización OAuth. El flujo desaparece de la pantalla; el acceso sigue en la cuenta. Otro error es retirar un agente crítico sin reemplazo probado: la operación se desordena y alguien lo reactiva sin control.
Antes de cerrar, verifica el retiro con una prueba real: intenta invocar el webhook y confirma que falla; revisa que no haya llamadas nuevas en los logs; comprueba que la concesión OAuth ya no aparece. Si algo sigue respondiendo, el agente no está retirado, solo está escondido.
Preguntas frecuentes
¿Un agente que no se ejecuta puede seguir siendo un riesgo?
Sí. La falta de ejecuciones no elimina la credencial, el webhook ni los permisos. Mientras esos elementos sigan activos, el agente puede ser despertado por un evento o por un tercero que tenga el disparador.
¿Cómo sé si mis agentes están dormidos?
Revisa la fecha de la última ejecución en la plataforma de automatización y en los logs del sistema que consulta. Si no hay telemetría, usa la fecha de la última modificación y pregunta al responsable. La ausencia de datos también es un resultado de la auditoría.
¿Es mejor pausar o borrar un agente que no se usa?
Primero pausa el disparador y observa si algo se rompe. Después revoca las credenciales y elimina el webhook. Borra el flujo al final, cuando tengas claro que no hay dependencias y que el acceso ya quedó cerrado en el origen.
¿Qué permisos debería tener un agente?
Los mínimos para su tarea, con una identidad dedicada y preferiblemente de solo lectura cuando no necesite escribir. Evita las cuentas personales y las credenciales de administrador. Si el agente necesita más permisos, que sea una decisión documentada y revisable.
¿Cada cuánto conviene revisar los accesos de los agentes?
Al menos una vez al trimestre y cada vez que alguien sale del equipo o cambia de rol. Los agentes críticos merecen una revisión mensual. La revisión debe incluir disparadores, credenciales y responsables, no solo la lista de flujos activos.
El primer flujo que deberías revisar hoy
Abre la plataforma de automatización y filtra los flujos sin ejecución en 60 días. Asigna un responsable a cada uno y anota la fecha de la próxima revisión. Si no puedes nombrar al dueño, ese agente ya tiene candidato a retiro: desactiva el disparador hoy y revoca la credencial antes de que alguien la use.
