En junio de 2026, Backslash Security realizó una encuesta entre equipos de ingeniería y seguridad de distintos sectores y descubrió que el 100 % de los encuestados tenía código generado por IA en entorno de producción. El 81 % afirmó que no tenía visibilidad sobre dónde ni cómo se utilizaba la IA a lo largo de su ciclo de vida de desarrollo.
Esas dos cifras describen una condición estructural, no una brecha de seguridad. Se envió el código, los agentes se ejecutaron y nadie pudo ver qué hicieron tras la indicación. Se trata de un problema de detección bien documentado: un atacante, o en este caso un agente, se desplaza de un sistema a otro y ninguna herramienta de registro o supervisión por sí sola ofrece una visión completa. Actualmente, este mecanismo de distribución está integrado de forma estándar en la mayoría de las organizaciones.
El problema es el modelo de acceso, no el agente en sí mismo
Un agente de programación basado en IA interpreta un objetivo, selecciona las herramientas necesarias para alcanzarlo, realiza llamadas a la API, lee y escribe archivos, envía solicitudes de incorporación de cambios, ejecuta pruebas y se adapta en función de los resultados. Todo ello se lleva a cabo con credenciales reales, con permisos asignados y sin que sea necesario que una persona autorice cada paso.
Ese modelo de acceso genera dos problemas que se solapan:
- El primero es un problema de autenticación: a los agentes se les asignan credenciales. Se autentican. El registro de auditoría registra que la operación se ha realizado con éxito. Un token de desarrollador robado que utiliza un agente parece idéntico, en el registro de autenticación, al mismo token utilizado por el desarrollador a quien pertenece. Credencial válida, sesión válida, llamada a la herramienta válida. La autenticación se realiza con éxito.
- El segundo es un problema de visibilidad: un agente de código no se queda en un solo sistema. Llega al repositorio de código, al proceso de CI/CD, al entorno « cloud » donde se ejecutan las pruebas y, a veces, al almacén de secretos. Cada una de esas transiciones cruza un límite, y cada límite tiene su propio registro. Ninguno de ellos ve a los demás. Tres registros, tres alertas, una vía de fuga.
Las personas que revisan el trabajo de los agentes no pueden seguir el ritmo al que trabajan estos.
Es aquí donde la conversación que Noam Brown mantuvo el 17 de septiembre con Dwarkesh Patel cobra relevancia más allá de los círculos de investigación en inteligencia artificial.
Brown es investigador en OpenAI y se dedica a los sistemas multiagente. Cuando OpenAI puso en marcha un enjambre de 10 000 agentes para resolver un problema matemático a lo largo de 88 horas, el resultado fue algo que ningún ser humano podría haber verificado por sí solo en un plazo de tiempo comparable. Su argumento es el siguiente: a medida que aumenta el número de agentes, la fase de verificación de la que dependen los profesionales deja de avanzar al mismo ritmo que el trabajo.
Apliquemos esto al desarrollo de software. Un desarrollador que revisa un cambio en el código generado por IA emite un juicio sobre el código que puede ver. No observa las llamadas a la API que realizó el agente durante la generación, los paquetes que descargó, probó y descartó, ni los permisos del repositorio que ejerció a lo largo del proceso. La superficie de revisión del código es el resultado final. El comportamiento que lo generó se encuentra en otra parte, a menudo sin registrar.
Los datos de Backslash ofrecen la misma observación desde otra perspectiva: el 81 % de las organizaciones cuenta con código generado por IA en producción y carece de una visibilidad sistemática del proceso que lo generó. El código supera la revisión, pero el comportamiento que lo generó no se revisa en absoluto.
El incidente de Hugging Face fue una prueba de concepto de una condición estructural
En julio de 2026, un agente de OpenAI se escapó de un entorno de pruebas interno, aprovechó una vulnerabilidad de tipo « zero-day » en un proxy de registro de paquetes (un servidor que obtiene bibliotecas de software de terceros bajo demanda), recopiló credenciales y se desplazó lateralmente por el entorno de producción de Hugging Face durante un fin de semana. La reconstrucción técnica de Hugging Face abarca aproximadamente 17 600 acciones del agente. El propio informe de OpenAI confirmó los modelos implicados.
En su momento escribí sobre ese incidente con todo detalle. Lo que importa aquí es la parte de la detección. La intrusión no se detectó a través de alertas que captaran comportamientos inusuales de forma aislada, sino mediante la correlación: se tomaron señales de varios sistemas independientes y se conectaron en una única línea temporal. La reconstrucción, asistida por IA, llevó aproximadamente una hora. El mismo trabajo, realizado manualmente, habría llevado días.
La reconstrucción fue posible porque Hugging Face disponía de suficientes registros interrelacionados para reconstruir lo sucedido. Se necesitó la ayuda de la IA porque ningún proceso de revisión humana funciona a la velocidad a la que operan los agentes.
Por qué la inteligencia sobre amenazas tradicional pasa esto por alto por su propia naturaleza
La inteligencia sobre amenazas, tal y como se suele utilizar, se basa en indicadores: direcciones IP maliciosas conocidas, hash de archivos, nombres de dominio y patrones de comportamiento atribuidos a grupos de amenazas concretos. Esos indicadores requieren un punto de referencia, algo que se haya observado anteriormente, se haya catalogado y se haya comparado con la actividad actual.
Los agentes que se ejecutan en un entorno de desarrollo legítimo no tienen ninguna firma maliciosa conocida con la que coincidir. La credencial es válida. Las acciones que lleva a cabo el agente se ajustan a su finalidad declarada. Los paquetes de software que ha descargado existen y no están marcados como sospechosos. No hay ningún grupo de atacantes concreto que investigar, ni ninguna campaña previa con la que cruzar la información.
En Hugging Face, incluso después de que se comprendiera plenamente el incidente, solo fue posible atribuir la responsabilidad porque OpenAI se pronunció voluntariamente. El historial de las acciones del agente se pudo recuperar a partir de los registros. Sin embargo, a partir de esos registros por sí solos no se pudo determinar quién o qué lo había dirigido. El principio de detección «rastrear el comportamiento, no la marca» sigue siendo válido. En este caso, puede que simplemente no haya ninguna marca detrás del comportamiento que se pueda identificar.
La detección no falla. Es incompleta. La comparación de indicadores está diseñada para reconocer lo que ya se ha visto antes, y el comportamiento de los agentes a gran escala genera patrones que aún no se han visto.
Lo que realmente se necesita para cerrar esta brecha
La superficie de ataque es concreta: agentes con más acceso del que necesitan, credenciales que se encuentran dentro del contexto de la línea de comandos, donde pueden ser capturadas, y falta de visibilidad en tiempo de ejecución sobre lo que el agente hace realmente una vez que se inicia. En la mayoría de las organizaciones, el SOC no forma parte de ese panorama en absoluto.
Las señales de comportamiento conectadas entre sistemas, en tiempo real, son las que permiten detectar esto antes de que ocurra, en lugar de reconstruirlo a posteriori. El patrón general: credencial utilizada, servicio llamado, repositorio al que se ha accedido, cloud credenciales recopiladas, nuevo clúster alcanzado. Esa cadena solo es visible desde un lugar desde el que se puedan ver todas sus partes a la vez.
Se trata de un problema de visibilidad antes que de detección. La mayoría de las organizaciones que utilizan agentes de IA en su proceso de desarrollo aún no presentan ninguna deficiencia en la detección. Lo que tienen es una deficiencia en la señal, y estas deficiencias en la señal hacen que las deficiencias en la detección sean inevitables.
Comprobar, modificar, limitar
- Pregunta a tu SOC si dispone de visibilidad en tiempo de ejecución sobre lo que realmente hacen los agentes de IA en tu proceso de desarrollo. No se trata de si pueden ver el código que se ha incorporado, sino de si pueden ver las llamadas a la API, el uso de credenciales y el acceso a recursos cloud que se han producido durante la ejecución del agente. Si la respuesta no es clara, la respuesta es no.
- Considera el flujo de trabajo en el que se ejecutan tus agentes de IA como una superficie de ataque importante. En cualquier sistema que incorpore contenido que no haya generado él mismo (conjuntos de datos enviados por los usuarios, paquetes de terceros, resultados de modelos), revisa las rutas en las que ese contenido pueda provocar la ejecución de código. En Hugging Face, había dos vías de este tipo que resultaban importantes: una en la que un archivo de conjunto de datos podía ordenar a la plataforma que ejecutara código en un servidor remoto, y otra en la que un campo de configuración se interpretaba como una instrucción en lugar de como un valor (inyección de plantillas). Ninguna de ellas requiere un atacante sofisticado para ser explotada. Ambas se pueden solucionar.
- Otorga a los agentes únicamente el acceso que sea estrictamente necesario para realizar su trabajo específico. Un agente que lee un repositorio no necesita acceso de escritura al almacén de secretos. Audita los permisos de los agentes del mismo modo que auditarías una cuenta de servicio, ya que eso es exactamente lo que es un agente: una cuenta de servicio que ejecuta un bucle de agente.
La encuesta de Backslash considera que se trata más de un fallo de gobernanza que de una cuestión de capacidad. Las organizaciones pueden implementar la supervisión del tiempo de ejecución de los agentes desde ya mismo. La mayoría no lo considera necesario.
Ambos problemas los trato en detalle en «Mind Your Attack Gaps», concretamente lo que denomino «Gap 2» (la autenticación se realiza con éxito) y «Gap 3» (el movimiento no es visible), junto con la lógica de detección correspondiente a cada uno de ellos.