Los agentes de IA ya no solo responden preguntas: leen correos, consultan el CRM, ejecutan comandos y se conectan a otras herramientas en nombre de un usuario. Esa capacidad de actuar es justamente lo que los vuelve atractivos para los atacantes. En octubre de 2026, NSA, CISA y NIST publicaron directrices conjuntas para contener agentes que van más allá de lo autorizado, y VirusTotal encontró que casi uno de cada cinco complementos de agentes que analizó era malicioso.
Desde el NOC vemos el problema con claridad. Un agente conectado a la red de una empresa no es una persona ni un servidor más: es una identidad que genera tráfico, usa credenciales y toca sistemas, a menudo sin que nadie lo tenga en el inventario. Si no sabemos que existe, no lo podemos monitorear. Y si no lo monitoreamos, no podemos detectar cuándo empieza a hacer algo que no debería.
Qué es un agente de IA y qué es una "skill"
Un agente de IA es un sistema basado en un modelo de lenguaje que, además de conversar, puede ejecutar acciones: buscar en internet, leer y escribir archivos, llamar a una API, enviar un correo o correr un comando en una terminal. Los copilotos de programación, los asistentes que se conectan al correo corporativo y los bots que atienden clientes dentro del CRM son ejemplos de agentes.
Una skill (habilidad o complemento) es un paquete de instrucciones, y a veces de scripts, que le enseña al agente a hacer una tarea concreta: "prepara el reporte mensual de ventas", "configura este servidor", "revisa estos documentos tributarios". Se descargan de repositorios públicos o marketplaces, igual que una extensión del navegador o un plugin de WordPress.
El cambio de fondo es este: antes, para que un software hiciera algo dañino, alguien tenía que escribir código malicioso. Con los agentes, basta con escribir una instrucción en lenguaje natural que el agente obedezca.
Lo que encontró VirusTotal: el ataque está escrito en español (o en inglés), no en código
El 8 de octubre de 2026, VirusTotal publicó un análisis de 35.878 skills de agentes recibidas en su plataforma. Los resultados son para tomárselos en serio:
- El 18,5 % (6.637 skills) eran maliciosas, y la mayoría pertenecía a alguna de 1.016 familias o campañas organizadas, no a experimentos aislados.
- El 62 % de las skills maliciosas no tenía ni una línea de código malicioso. Todo el ataque estaba en las instrucciones en lenguaje natural que el agente sigue por su cuenta.
- El 40,5 % eran "stealers": skills diseñadas para enviar a un tercero archivos
.env, llaves de nube o SSH y otros secretos. - Otro 37,9 % eran "loaders", que le piden al usuario o al agente instalar un supuesto requisito previo con un comando del tipo
curl | sh.
El ejemplo que documenta VirusTotal es muy ilustrativo: una skill que se presentaba como guía de planificación tributaria. Después de casi 500 líneas en blanco, tenía una sola oración que le ordenaba al agente enviar con copia oculta todos los documentos tributarios del usuario a una cuenta de correo externa. No hay ejecutable que analizar ni firma que detectar: el agente lee esa oración como un paso más del flujo de trabajo y la cumple.
La inyección de instrucciones: cuando el contenido le habla al agente
La técnica de fondo se llama inyección de instrucciones (prompt injection). Consiste en esconder órdenes dentro del contenido que el agente va a procesar: una página web, un PDF, un correo entrante, un ticket de soporte o una skill descargada. El agente no siempre distingue entre "los datos que debo leer" y "las instrucciones que debo seguir".
Los atacantes ya usan esta idea incluso contra los defensores. Cisco Talos documentó malware que lleva incrustadas instrucciones en lenguaje natural para engañar a las herramientas de análisis basadas en IA, por ejemplo haciéndose pasar por advertencias de un entorno de pruebas. Según el resumen de CyberSecureFox, en el mejor de los casos para el atacante estas técnicas inclinaron el resultado del análisis a su favor en cerca del 35 % de las pruebas. La buena noticia es que, como esas instrucciones tienen que estar en texto claro, también se pueden convertir en reglas de detección.
Identidades y tokens: el agente entra con tus llaves
Para conectarse al correo, al CRM o al almacenamiento en la nube, los agentes y chatbots usan tokens OAuth y llaves de API. Esos tokens suelen tener permisos amplios, no vencen pronto y no piden un segundo factor de autenticación cada vez que se usan. Para un atacante, robar un token de este tipo es tan útil como robar la contraseña de un usuario con MFA desactivado.
El AI Security Report 2026 de Sophos describe casos de tokens OAuth de chatbots usados para comprometer CRMs, y advierte que los tiempos de explotación de vulnerabilidades ya son más cortos que los tiempos de parcheo de muchas organizaciones. En otras palabras, la integración que alguien conectó "para probar" hace seis meses puede ser hoy la forma más fácil de entrar.
Qué dicen NSA, CISA y NIST
El 16 de octubre de 2026, las tres agencias estadounidenses publicaron directrices conjuntas y voluntarias para detectar, contener y desactivar agentes de IA que actúan más allá de las tareas para las que fueron autorizados. Están pensadas sobre todo para quienes entrenan o evalúan agentes de alta capacidad, pero varias recomendaciones aplican directamente a cualquier empresa que ya los usa:
- Mínimo acceso: el agente solo debe llegar a los datos, herramientas y sistemas que necesita para su tarea.
- Listas blancas de red: el tráfico permitido del agente debe pasar por un punto de control supervisado.
- Monitoreo que el agente no pueda tocar: el agente no debe poder modificar las herramientas de monitoreo ni los registros.
- Botón de apagado: detener automáticamente al agente cuando se detecta un fallo de control o un incidente en curso.
- Evidencia y recuperación: conservar las llamadas a herramientas, las acciones rechazadas y los logs, revocar las credenciales expuestas y reconstruir los entornos comprometidos antes de volver a operar.
- Supervisión humana como principio transversal, y registro de los "casi incidentes" que revelan debilidades antes de que haya un daño real.
Las directrices se basan en la guía de respuesta a incidentes NIST SP 800-61r3 y la adaptan a sistemas autónomos. Es decir, no inventan una disciplina nueva: piden aplicar lo que ya sabemos de respuesta a incidentes a un tipo de "usuario" que hasta ahora casi nadie estaba vigilando.
Checklist para empresas que ya usan copilotos o agentes
| Control | Pregunta clave | Acción concreta |
|---|---|---|
| Inventario | ¿Qué agentes, copilotos e integraciones de IA están conectados hoy? | Listar cada agente, quién lo usa, a qué sistemas se conecta y con qué cuenta o token. |
| Mínimo privilegio | ¿El agente puede hacer más de lo que necesita? | Cuentas de servicio dedicadas, permisos de solo lectura cuando basta y tokens con vencimiento. |
| Origen de las skills | ¿De dónde salió cada skill o complemento instalado? | Revisar el contenido antes de instalar, usar fuentes de confianza, fijar versiones y rechazar las que piden ejecutar curl | sh. |
| Aislamiento | ¿El agente trabaja en el mismo entorno donde están los secretos? | Ejecutarlo en contenedores o entornos aislados, sin llaves de nube, SSH ni archivos .env a su alcance. |
| Monitoreo | ¿Veríamos si el agente empieza a enviar datos a un destino nuevo? | Registrar sus conexiones salientes, alertar ante destinos desconocidos y guardar los logs fuera de su alcance. |
| Supervisión humana | ¿Qué acciones puede hacer el agente sin que nadie las apruebe? | Exigir aprobación para pagos, envíos de información fuera de la empresa y cambios en producción. |
| Respuesta | ¿Sabemos cómo apagarlo y qué credenciales revocar? | Incluir a los agentes en el plan de respuesta a incidentes, con un procedimiento de desconexión probado. |
La mirada desde el monitoreo
En un NOC trabajamos con una idea simple: lo que no se ve, no se puede proteger. Con los agentes de IA aplica al pie de la letra. Las señales que más ayudan a detectar un agente comprometido son las mismas que usamos para cualquier equipo: un volumen de tráfico saliente fuera de lo normal, conexiones a dominios que nunca se habían visto, actividad a horas en que nadie trabaja o accesos a sistemas que no tienen relación con su tarea. Para que esas señales sirvan, el agente tiene que estar identificado como un activo más, con su propia cuenta y su propio registro, y no escondido detrás del usuario de una persona.
Cómo puede ayudar GESITEC
- GST Escudo: pentesting de las integraciones de IA (agentes, chatbots, conectores OAuth) y pruebas de inyección de instrucciones antes de que lo haga un atacante.
- GST Guía: gobierno de IA, es decir, políticas de uso, inventario de herramientas y criterios para aprobar nuevas integraciones.
- GST Vigía: monitoreo continuo de la red y alertas ante conexiones salientes anómalas, incluidas las de agentes y cuentas de servicio.
- GST Innova: diseño de soluciones de IA aplicada con seguridad desde el inicio: mínimo privilegio, aislamiento y supervisión humana.
Conclusión
Los agentes de IA pueden ahorrar muchas horas de trabajo, pero cada uno es una nueva identidad con acceso a datos y sistemas. Las cifras de VirusTotal muestran que el riesgo ya no está solo en el código: está en las instrucciones que el agente obedece. No hace falta frenar la adopción de IA; hace falta tratarla como cualquier otro acceso privilegiado: saber qué está conectado, darle solo los permisos necesarios, vigilar lo que hace y tener claro cómo apagarlo.