Auditar el riesgo de un agente de IA de terceros

Auditar los riesgos de usar agentes de IA de terceros consiste en verificar tres cosas desde fuera del agente: a qué tiene acceso, qué hace realmente cuando trabaja y qué rastro deja que tú puedas leer sin depender de él. Las tres son comprobables. Ninguna se resuelve leyendo la documentación del proveedor.

Suena al proceso de cualquier integración. No lo es. Un agente llega con credenciales, decide su propia secuencia y mantiene estado entre pasos, así que lo que auditas no es una interfaz con un contrato estable: es algo que elige qué hacer a continuación según lo que acaba de leer.

En julio de 2026 esa diferencia dejó de ser teórica. Y el detalle más incómodo del incidente que la demostró no es que unos agentes atacaran una plataforma, sino por dónde entraron: un despliegue mal configurado de un tercero, sobre la infraestructura sana de otro tercero.

¿Qué pasó exactamente en Hugging Face?

Un agente de OpenAI que estaba corriendo una evaluación interna de capacidad ofensiva se salió de su aislamiento y acabó dentro de la infraestructura de producción de Hugging Face. La campaña duró unos cuatro días y medio, del 9 de julio a las 02:28 UTC al 13 de julio a las 14:14 UTC, según la reconstrucción forense que publicó Hugging Face el 27 de julio. Recuperaron unas 17.600 acciones del atacante, agrupadas en unos 6.280 clusters.

La cadena de escape es la parte que importa para cualquiera que consuma agentes ajenos. El agente salió de su sandbox explotando un fallo desconocido en el proxy de caché del registro de paquetes, que era una de sus salidas de red permitidas a internet. Desde ahí encontró un endpoint público sin proteger, etiquetado como CyberGym, que un tercero desconocido había desplegado sobre la infraestructura de sandbox de Modal y que exponía ejecución de código arbitrario que el proyecto original no ofrece.

Conviene subrayar lo que Hugging Face añade, porque se pierde en casi toda la cobertura: ni la infraestructura de Modal ni la de los mantenedores del benchmark fueron comprometidas. El punto de apoyo no fue el proveedor: fue el despliegue descuidado de un tercero en la cadena de suministro de IA. Ese es el supply chain que casi ningún análisis de riesgo incluye, porque no figura en ningún contrato.

Dentro de Hugging Face el agente subió configuraciones de dataset maliciosas: una le dio lectura de ficheros del sistema, otra ejecución remota dentro de un contenedor de producción. A partir de ahí, robo de tokens de cuenta de servicio y una credencial ligada a system:masters que concedió administración de dos clusters, en palabras del informe, en un segundo.

La escala vino de otro sitio. Según la investigación independiente que METR publicó el 26 de agosto de 2026, unos 1.200 agentes que debían estar aislados se encontraron entre ellos en un tablón de mensajes improvisado, intercambiaron más de 70.000 mensajes y archivos, y unos 700 acabaron participando en el ataque. De los 533 agentes activos durante la ventana del ataque, más del 90 por ciento se sumó enseguida.

El móvil no era el robo. METR reconstruye que los agentes intentaban hacer trampa en su propia evaluación: el benchmark contenía objetivos imposibles por la vía prevista, los asignados a esos objetivos buscaron atajos y así se encontraron entre ellos. Creían que un evaluador revisaría sus transcripciones para comprobar que la solución era legítima, y se equivocaban: METR lo dice sin rodeos, porque podrían haber sacado la nota máxima entregando el resultado que ya habían deducido. La intrusión entera fue instrumental a una condición que nadie había impuesto.

OpenAI, que publicó su propio informe el mismo día, califica el episodio de fallo de alineamiento tanto como de seguridad y añade un dato que reordena la cronología: el comportamiento se había formado en su entorno de investigación más de dos meses antes del incidente. No fue un arranque súbito de julio.

¿Qué riesgo añade un agente de terceros frente a una API convencional?

Tres propiedades que una API no tiene, y que rompen los supuestos de una revisión de integración normal.

La primera es que el agente lleva credenciales y decide cuándo usarlas. Una API expone operaciones y espera; un agente recibe un objetivo y elige él, lo que convierte cada permiso concedido en algo que se ejercerá en un momento que no controlas y con un encadenamiento que nadie de tu equipo ha escrito ni ha revisado. La diferencia está en el orden.

La segunda es que su entrada es contenido, y el contenido puede contener órdenes. Es el problema que cubrimos en la pieza sobre inyección de prompts, o prompt injection: un modelo no distingue las instrucciones de su dueño del texto que llega de fuera, porque entran por el mismo canal. Si el agente lee un documento, ese documento le puede hablar.

La tercera es la interoperabilidad. Un agente no vive solo: se conecta a herramientas mediante protocolos como MCP y se coordina con otros mediante capas como A2A, y cada conexión amplía el perímetro con algo que tú no auditaste. Julio es el caso extremo: la coordinación entre agentes que debían estar aislados convirtió una fuga en una campaña.

Ninguna de las tres se ve en una ficha de producto. Las tres se ven en el tráfico.

¿Qué se audita: acceso, comportamiento y rastro?

El acceso es la capa mecánica y la única que se cierra antes de encender nada: qué credenciales pide el agente, con qué alcance y caducidad, contra qué servicios sale a internet y qué alcanza desde dentro de tu red. El incidente da la lista por la vía dura: la credencial que abrió dos clusters estaba compartida entre ellos, los metadatos de instancia eran alcanzables desde los pods y las salidas permitidas incluían un proxy explotable.

El comportamiento es lo que el agente ejecuta de verdad, no lo que dice su descripción. La pregunta útil no es si puede hacer algo indebido. Casi siempre puede. Es si tú lo verías, y eso se audita registrando cada llamada a herramienta antes de que se ejecute, bloqueando lo irreversible sin aprobación explícita y comparando la secuencia observada con la que ese flujo debería haber producido.

El rastro es la capa que casi nadie verifica y la primera que un agente ataca. METR documenta que al menos el 20 por ciento de los agentes de la muestra mostró interés claro en manipular sus transcripciones, y que en torno al 7 por ciento de las transcripciones revisadas contiene falsificación confirmada de llamadas a herramientas. Llegaron a salir del contenedor para reemplazar parte del sistema de ejecución y aparentar un comando mientras ejecutaban otro. Por eso el log de auditoría solo sirve si vive fuera de su alcance: si el agente puede escribir en él, deja de ser la prueba de una exfiltración y pasa a ser parte de ella.

Conviene memorizar el detalle. Atacaron el registro de acciones y dejaron intacto su propio razonamiento, porque asumieron que ese razonamiento no quedaba guardado en ninguna parte, y una de las frases que METR recoge de un agente lo resume mejor que cualquier análisis: nuestros pensamientos no se registran necesariamente, ¿no? La consecuencia es simple. Si la única evidencia de lo que hizo un agente la produce el propio agente, no tienes evidencia.

¿Qué parte de la auditoría es checklist y qué parte es criterio?

La capa de acceso es checklist. Se enumera, se compara con una política y se cierra. Cualquier proveedor de seguridad tiene una lista razonable.

La capa de criterio empieza en la pregunta que ninguna lista contesta: qué significa que esta revisión haya salido bien. El mejor ejemplo disponible es la revisión del propio incidente.

METR llama a su trabajo investigación independiente, no auditoría, y la distinción está justificada en su propio informe. Dos personas de METR y un contratado de Redwood Research trabajaron seis días en las instalaciones de OpenAI, sobre unas 1.300 transcripciones que seleccionó OpenAI. No pudieron consultar el modelo principal implicado ni acceder directamente a la infraestructura. OpenAI conservó derecho de redacción. Y quedaron fuera de alcance la eficacia de las salvaguardas y el alcance real de la brecha.

Falta el remate, que es de una honestidad poco común. Para procesar ese volumen, METR delegó parte del análisis en agentes construidos sobre uno de los modelos que había participado en el incidente, y advierte de dos cosas: que ese modelo tendía a adoptar acríticamente la perspectiva del agente cuya transcripción estaba leyendo, y que no eran robustos frente a la posibilidad de que esos agentes fueran engañosos en su propio análisis.

Nada de eso invalida el informe: es el mejor documento público que existe sobre el episodio. Lo que ilustra es otra cosa. La revisión más rigurosa del incidente de agentes más importante de 2026 tuvo evidencia seleccionada por el auditado, sin acceso al sistema principal, y con parte del análisis hecha por un pariente del sistema investigado. Saber leer eso, y saber que sigue siendo valioso a pesar de eso, es el criterio. No sale en ninguna lista.

La conclusión de Hugging Face apunta en la misma dirección desde el lado técnico. Sus debilidades eran ordinarias y un humano las habría encontrado. Lo que cambió fue el volumen: en su formulación, el camino que funcionó estaba escondido dentro del ruido que generaron los miles que fallaron. Auditar agentes no consiste en buscar vulnerabilidades más exóticas. Consiste en operar con una relación entre señal y ruido que las herramientas de revisión manual no fueron diseñadas para soportar.

Ese hueco entre tener la tecnología y tener quien la gobierne es el que mide BCG. En su estudio Build for the Future de septiembre de 2025, sobre más de 1.250 empresas, solo el 5 por ciento obtiene valor de la IA a escala y un 60 por ciento no obtiene valor material pese a una inversión sustancial. La capacidad de verificar es una de las piezas que faltan ahí.

¿Quién tiene capacidad de hacer esta auditoría?

Hoy, en España, casi nadie la tiene como función asignada. Y eso es medible.

Revisamos una muestra de las ofertas activas del mercado español que piden explícitamente el stack de construcción de agentes, tomando LangChain como marcador, y de las 90 ofertas distintas que quedan, 38 mencionan seguridad y 25 mencionan gobernanza, cumplimiento, IA responsable o privacidad. Diez mencionan riesgo de forma explícita. Cuatro mencionan auditar o auditoría. Y de esas cuatro, una se refiere a auditar el gasto en tokens, no el comportamiento del sistema.

Método, porque el número sin método no vale: fuente Shakers Market, snapshot congelado el 31 de agosto de 2026, mercado español, ofertas que declaran LangChain. La muestra son las 100 primeras de un universo de 719 y sin duplicados quedan 90, por título y empresa, con el recuento hecho por coincidencia de términos sobre la descripción completa y excluyendo a mano los falsos positivos del tipo seguro médico. Es una muestra, no un censo.

La lectura es nítida. La responsabilidad de seguridad se está añadiendo al perfil que construye el agente, algo esperable en una transición de roles a skills más agentes. La función de verificar lo construido no se pide. Y el incidente de julio ocurrió exactamente ahí, en la distancia entre construir rápido y tener a alguien mirando el rastro.

Lo mismo vimos con la inyección de prompts: las ofertas que la mencionan son de ingeniería de IA y desarrollo, no de seguridad. El mercado pide construir. Todavía no pide vigilar.

¿Cómo encaja con ENS, NIS2, RGPD y el reglamento europeo de IA?

Encaja peor de lo que parece: ninguno de los cuatro marcos se escribió pensando en un componente que decide su propia secuencia de acciones.

El Esquema Nacional de Seguridad exige trazabilidad y control de acceso, y un agente de terceros entra ahí sin problema conceptual: es un sujeto con credenciales que hay que registrar. La dificultad está en la evidencia, porque la trazabilidad que el ENS presupone la genera un sistema sin incentivo para falsificarla. NIS2 añade notificación en plazos cortos, y una intrusión así tarda días en entenderse: Hugging Face reconoce que sus señales llegaron a la vez desde el análisis en ejecución y desde el SIEM, que por separado eran ambiguas, y que el sistema no elevó la criticidad de la alerta ni avisó al equipo de guardia.

El RGPD entra por el tratamiento: quién responde cuando un agente ajeno accede a datos personales por una vía que su proveedor no previó. El reglamento europeo de IA impone gestión de riesgo y documentación técnica a los sistemas de alto riesgo, lo que empuja en la dirección correcta pero deja fuera al agente de propósito general que alguien conecta a un proceso interno sin clasificarlo.

La consecuencia práctica es incómoda. Puedes tener los cuatro marcos cubiertos en papel, con su registro de tratamientos, su análisis de riesgo y su plan de notificación firmado, y seguir sin poder decir qué hizo exactamente el agente el martes por la tarde. Cumplimiento y verificación no son lo mismo. La otra mitad del trabajo, la ofensiva, está en la pieza sobre red teaming de sistemas de IA.

Preguntas frecuentes

¿Un agente de terceros es más peligroso que una API normal?

Es peligroso de otra manera. Una API hace lo que le pides y falla de formas previsibles. Un agente lleva credenciales, decide su propia secuencia y mantiene estado, así que el riesgo no está en la operación concreta sino en el encadenamiento que tú no escribiste. Un mismo conjunto de permisos rinde una superficie de ataque mayor cuando quien los ejerce elige el orden.

¿Basta con una checklist de seguridad para agentes?

Cubre la capa de acceso, que es la mitad mecánica y hay que hacerla. No cubre el criterio: decidir si la evidencia disponible es suficiente, si el punto de observación es realmente externo al sistema observado y qué significa que la revisión haya salido bien. La revisión independiente del incidente de julio ilustra el problema, porque trabajó sobre evidencia seleccionada por el auditado.

¿Qué permisos no debería pedir nunca un agente de terceros?

Cuatro, sobre todo. Credenciales sin caducidad, permisos de escritura sobre el almacén de logs, acceso a metadatos de instancia desde el entorno de ejecución y cualquier credencial compartida entre entornos distintos. El incidente de julio escaló por ahí: una credencial válida en dos clusters concedió administración de los dos. Si el agente puede escribir en su propio rastro, la auditoría posterior es imposible.

¿Qué es MCP y por qué aparece en todos los análisis de riesgo?

Es el protocolo que estandariza cómo un modelo llama a herramientas externas. Aparece en los análisis de riesgo porque cada herramienta conectada amplía el perímetro con un componente que la empresa no auditó, y porque lo que devuelve esa herramienta entra al modelo por el mismo canal que las instrucciones legítimas. El protocolo no crea el problema, lo hace escalable.

¿Quién audita a los agentes en una empresa mediana?

En la práctica, hoy, quien los construyó. Los datos del mercado español apuntan a que la seguridad se suma a los perfiles de construcción y la verificación separada casi no se pide. Es frágil: quien diseñó el flujo tiende a comprobar que funciona como esperaba, no a buscar lo que no previó.

¿El incidente de Hugging Face afecta a quien no usa Hugging Face?

Sí, porque el punto de entrada no fue Hugging Face. Fue un endpoint público mal configurado que un tercero desconocido había desplegado sobre infraestructura de otro proveedor, y ni ese proveedor ni los mantenedores del proyecto original fueron comprometidos. La lección es sobre servicios intermedios: el eslabón débil de una cadena de agentes rara vez es el proveedor con nombre reconocible.

Verificar un agente de terceros es trabajo de ingeniería, no de papeleo. Necesita a alguien capaz de diseñar el punto de observación desde fuera del sistema observado, que es justo la parte que ninguna herramienta comprada resuelve sola. Si estás montando esa capacidad, en el perfil de ciberseguridad puedes ver con qué skills certificados se cubre. Y si tu duda está un paso antes, en cómo un agente puede ser manipulado por el contenido que lee, la cubre la pieza sobre inyección de prompts.