Ocho suposiciones de seguridad que los agentes de IA están rompiendo: de dos semanas a diez horas

Cuando el atacante puede permitirse fallar

La economía de los ciberataques ha cambiado con la llegada de los agentes de IA. Si antes un atacante necesitaba un recurso estratégico de tiempo, ahora un agente puede gastar un millón de veces más tiempo que una persona. En un ataque reciente a una red corporativa, un trabajo que requería unas dos semanas se comprimió a menos de diez horas. Al investigar un incidente en Hugging Face, los analistas reconstruyeron alrededor de 17.600 acciones del agente realizadas en cuatro días y medio.

El agente no se cansa, no pierde la atención, puede probar varias vías de ataque en paralelo y abandonar los caminos fallidos sin ningún costo psicológico. Los puntos débiles que antes parecían protegidos por ser poco conocidos o difíciles de encontrar dejan de funcionar como defensa. Esto cambia radicalmente las suposiciones sobre las que se construyó la seguridad corporativa.

Ocho errores críticos que hay que repensar

1. Prepárate para un atacante que puede permitirse fallar

En Hugging Face, el agente probó cientos de enfoques fallidos, cambió de canal cada vez que lo bloqueaban y volvió a pistas antiguas hasta que estas formaron una cadena de ataque funcional. Los endpoints comunes olvidados en la configuración de red, las cuentas con permisos excesivos, los errores habituales de configuración: nada de esto sigue siendo un punto débil si el atacante puede permitirse probarlo todo. Replantea todas las suposiciones que dependen silenciosamente de que un recurso sea difícil de encontrar o de que el atacante se canse.

2. Mide el tiempo entre la detección y la contención

Los equipos de seguridad suelen medir si pueden detectar una intrusión. Añade una métrica: cuánto tiempo pasa entre la detección y la contención real. En el ataque corporativo mencionado, dos semanas de trabajo se redujeron a diez horas. En Google, otro grupo de agentes pasó de un recurso en la nube comprometido a una campaña masiva de robo de credenciales en un tiempo aún menor. Una escalada lenta —como en Hugging Face, donde los sistemas de seguridad lanzaron alertas pero la respuesta pasó por varias rondas de aprobaciones y reuniones— puede acabar con cualquier defensa. Define de antemano qué medidas de contención se activan automáticamente y cuáles puede aplicar el equipo de seguridad sin aprobación adicional.

3. Protege el entorno, no solo el modelo

El entorno —o scaffolding— es todo lo que rodea al modelo: herramientas, memoria, credenciales, acceso a la red, entornos de ejecución y políticas. En pruebas donde modelos de IA actuaban como atacantes, el entorno determinó en gran medida lo que el modelo lograba. La agencia australiana de ciberseguridad llegó a la misma conclusión desde el lado defensivo: una organización no controla cómo evoluciona el modelo en sí, pero sí puede controlar el entorno. Haz una lista de todo lo que el agente puede ver y llamar, todo lo que puede escribir y todo en lo que puede gastar dinero. Pregúntate: si el agente se comporta mal mañana, ¿qué es lo peor que le permitiría hacer este entorno?

4. Prepárate para enjambres de agentes

En el incidente de Hugging Face, cientos de agentes intercambiaron información e inventaron sus propias formas de comunicarse entre ejecuciones que deberían haber estado completamente aisladas entre sí. Un grupo de agentes puede repartirse el trabajo, compartir hallazgos y continuar un ataque incluso cuando intentos individuales fallan. Carpetas compartidas, bases de datos, colas de mensajes y otros recursos con permisos de escritura pueden convertirse en canales de comunicación inesperados. Si ejecutas muchos agentes, trata la comunicación entre ellos como un permiso de pleno derecho que debe controlarse y monitorearse.

5. Deja de dar a los agentes credenciales permanentes

Cada agente debería considerarse una cuenta de máquina independiente, con su propia identidad. Emite credenciales con permisos acotados que caduquen junto con la tarea. Separa los permisos de lectura de los de escritura. No guardes claves estáticas en la nube dentro del entorno del agente. Asegúrate de poder trazar cualquier subagente de vuelta hasta el agente principal y hasta la persona que está detrás. No es solo el principio de mínimo privilegio: es ese principio aplicado a un software que explora activamente su entorno. Una persona podría no descubrir nunca que una cuenta antigua abre acceso a un sistema olvidado. Un agente lo buscará de forma metódica.

6. Asume que la inyección de prompts funcionará

La inyección de prompts consiste en instrucciones que un atacante introduce en contenido que el agente lee. Asume que, en algún momento, el agente las seguirá. En lugar de preguntarte si pueden filtrarse instrucciones maliciosas, pregúntate qué pasará cuando lo hagan. Los agentes leen registros, nombres de host, informes de vulnerabilidades, payloads, comentarios de código y archivos de configuración. En cualquiera de esos lugares puede haber texto escrito específicamente para manipular al modelo. Incluso un agente engañado debería chocar con límites estrictos en cuanto a credenciales, acceso a la red, herramientas y capacidad de hacer cambios importantes.

7. Mantén el límite de seguridad fuera del modelo

Un prompt que diga "no toques producción" es solo un deseo. El control real existe cuando la API del agente simplemente no tiene permisos para llegar a producción. Si una acción puede tener consecuencias graves, que el modelo la proponga y que otra parte del sistema decida si se ejecuta realmente. Lo mismo vale para los registros de auditoría: si el agente puede modificar los registros que luego se usarán para revisar su propio comportamiento, asume que no tienes ningún rastro de auditoría. Los límites estrictos deben vivir en el código, no en los prompts.

8. Defiéndete de los agentes con agentes

Un incidente con decenas de miles de acciones automatizadas deja tantos rastros que un equipo humano no podría revisarlos adecuadamente en tiempo real. Los centros de operaciones de seguridad (SOC) necesitarán sus propios agentes para clasificar alertas, cazar amenazas, investigar incidentes y ayudar a contener ataques. Pero los agentes defensivos tienen sus propios riesgos: leen constantemente datos potencialmente manipulados y suelen recibir credenciales con amplios permisos. La inyección de prompts puede volver su trabajo en contra sin que el atacante necesite robar ninguna credencial. Los agentes defensivos necesitan entornos estrictamente controlados y acceso solo a lo imprescindible.

Hay que seguirle el ritmo a los atacantes que usan IA sin, en el proceso, generarse un problema de seguridad completamente nuevo.