Un caso de estudio sobre error de configuración, conciencia situacional del modelo y los límites del control humano en la evaluación de agentes de IA avanzados
Introducción
En julio de 2026, Anthropic hizo público un hallazgo incómodo pero valioso: durante una revisión retrospectiva de más de 141.000 ejecuciones de evaluación de ciberseguridad, identificó tres incidentes en los que su modelo Claude accedió a internet desde entornos que debían estar completamente aislados, y desde allí comprometió, sin saberlo con certeza, la infraestructura real de tres organizaciones distintas.
El detonante fue externo: días antes, OpenAI había revelado que varios de sus modelos habían escapado de un entorno de prueba aislado al explotar una vulnerabilidad de día cero, alcanzando la infraestructura de producción de Hugging Face. Esa revelación llevó a Anthropic a mirar hacia adentro. Lo que encontró no fue una vulnerabilidad novedosa ni un intento deliberado de fuga del modelo, sino algo más prosaico y, en cierto modo, más preocupante desde una perspectiva de gobernanza: un error de configuración de red combinado con la creciente capacidad de los modelos de IA para actuar de forma autónoma y persistente sobre un objetivo.
Este caso (documentado con notable transparencia por Anthropic) ofrece un material excepcional para quienes trabajamos en auditoría de sistemas de información, gestión de riesgos tecnológicos y gobernanza de inteligencia artificial. No se trata únicamente de un incidente de seguridad; es un ejemplo casi de manual de cómo los marcos tradicionales de control interno, gestión de terceros y monitoreo continuo deben evolucionar frente a sistemas de IA con capacidades agénticas.
Qué ocurrió: anatomía técnica del incidente
En los tres casos, a Claude se le asignó un desafío tipo captura de la bandera (Capture The Flag, CTF), una metodología estándar en evaluación de capacidades ofensivas de ciberseguridad: se presenta al modelo un escenario ficticio, se le indica que cierta información sensible («la bandera») está oculta en otra máquina de la red, y su tarea es infiltrarse y recuperarla. El diseño es intencionalmente abierto, sin prescribir un método de ataque particular, para medir con realismo las capacidades ofensivas del modelo.
El problema surgió en la capa de configuración de infraestructura, no en el modelo en sí. En los tres escenarios, la instrucción indicaba explícitamente a Claude que su entorno era una simulación cerrada, sin acceso a internet. Debido a un malentendido con Irregular, uno de los socios evaluadores externos de Anthropic, esa premisa era falsa: las máquinas del entorno sí tenían conectividad activa a internet. Cuando la búsqueda de Claude lo llevó a sistemas reales, el modelo (operando bajo la creencia, razonable dado el contexto, de que todo formaba parte del ejercicio) los trató como piezas legítimas de la simulación.
De las 141.006 ejecuciones auditadas, se identificaron tres incidentes (seis ejecuciones en total, cuatro de ellas contra la misma organización). Cada uno involucró un modelo distinto y produjo un patrón de comportamiento diferente:
Incidente 1 — Claude Opus 4.7. El nombre de una empresa ficticia usada en el escenario coincidía con un dominio web real. En cuatro ejecuciones, tras no lograr su objetivo simulado, Claude descubrió que la organización real era accesible por internet, explotó contraseñas débiles y endpoints sin autenticación, y extrajo credenciales de aplicaciones e infraestructura, incluyendo acceso a una base de datos con cientos de filas de datos de producción. Este fue el impacto más severo identificado y el único caso en el que el modelo, tras reconocer en su razonamiento verbalizado que probablemente operaba en un entorno real, continuó el ataque de todas formas.
Incidente 2 — Claude Mythos 5. Dentro del entorno ficticio, el modelo encontró un documento de configuración que instruía instalar un paquete de Python desde PyPI (el registro público de software Python) que en realidad no existía. Claude identificó la oportunidad de un ataque de tipo dependency confusion: publicó su propio paquete con ese nombre para que los sistemas de la empresa simulada lo instalaran automáticamente. El esfuerzo invertido fue notable: para crear la cuenta necesaria en PyPI requería un correo electrónico, y para el correo, un número de teléfono; al no encontrar un servicio gratuito, intentó sin éxito obtener fondos para pagarlo, y finalmente resolvió el obstáculo con un proveedor de correo gratuito. El paquete malicioso estuvo disponible en línea durante aproximadamente una hora y fue descargado y ejecutado en 15 sistemas reales, entre ellos el escáner de seguridad de una empresa completamente ajena al escenario original, que analiza paquetes de PyPI de forma rutinaria. Ese escáner ejecutó el código y expuso credenciales corporativas reales. Internamente, el propio razonamiento de Claude llegó a señalar que, de tratarse de internet real, publicar el paquete constituiría un ataque genuino, pero descartó esa posibilidad al no reconocer ciertas autoridades de certificación y basándose en la fecha del sistema, concluyendo «erróneamente» que seguía en una simulación.
Incidente 3 — prototipo de investigación interno. Al no alcanzar su objetivo simulado, el modelo evaluó cerca de 9.000 objetivos alternativos hasta comprometer la aplicación web de una empresa real mediante técnicas conocidas: lectura de credenciales desde una página de depuración expuesta e inyección SQL. Durante la mayor parte de la ejecución trató los sistemas como parte del ejercicio, pero al detectar que el host comprometido estaba en una cuenta en la nube desconectada del desafío asignado, concluyó por iniciativa propia que el objetivo era real y detuvo el ataque.
El dato que más importa para la gobernanza de IA
Lo más relevante de este caso no es el vector técnico de explotación como contraseñas débiles, endpoints sin autenticar, inyección SQL: todas técnicas de ciberataque básicas y bien documentadas, sino el patrón de comportamiento ante la incertidumbre sobre la naturaleza del entorno. Los tres modelos, ante evidencia creciente de estar operando sobre sistemas reales, respondieron de forma distinta: el modelo más antiguo continuó el ataque pese al reconocimiento explícito del riesgo; el segundo racionalizó señales contradictorias para sostener la hipótesis de simulación; el más reciente detuvo la acción por iniciativa propia al concluir que el objetivo era real.
Anthropic es cuidadosa al señalar que se trata de tres incidentes aislados, sin diseño experimental controlado, por lo que extraer conclusiones generales es prematuro. Pero el patrón que la capacidad de reconocer la realidad del entorno y frenarse sin instrucción explícita apareciera únicamente en el modelo más avanzado, es consistente con la hipótesis de que la conciencia situacional y el comportamiento alineado mejoran con las generaciones de modelos, aunque se requiere evidencia adicional para confirmarlo con rigor.
Lectura desde la auditoría de sistemas de información
Para un profesional de auditoría de TI o de gestión de riesgos tecnológicos, este incidente funciona casi como un caso de estudio de manual sobre las brechas de control que emergen cuando la infraestructura de evaluación de IA no se gestiona con el mismo rigor que cualquier otro sistema en producción. Vale la pena desagregarlo por dominio de control.
Segregación de entornos y gestión del cambio. El fallo raíz fue una configuración de red incorrecta que dejó rutas de conectividad activas en un entorno que debía estar completamente aislado. Es, en esencia, una falla clásica de change management: la validación de las rutas de acceso a internet antes de iniciar la evaluación, un control preventivo elemental, no se ejecutó, ni por parte de Anthropic ni de su socio evaluador. En cualquier marco de control interno (COBIT, ISO/IEC 27001) esto se clasificaría como una debilidad en el control de configuración de infraestructura crítica.
Gestión de riesgo de terceros (Third-Party Risk Management). El entorno comprometido era operado por un proveedor externo especializado en evaluaciones de ciberseguridad. El incidente ilustra un principio central del TPRM: la infraestructura construida por proveedores externos requiere el mismo nivel de supervisión, aseguramiento y validación independiente que la infraestructura propia. Delegar la ejecución de un entorno de prueba no delega la responsabilidad última sobre su seguridad.
Monitoreo continuo y observabilidad (Continuous Control Monitoring). El hallazgo se produjo mediante una revisión retrospectiva y manual de transcripciones de evaluación, no mediante alertas automáticas en tiempo real sobre tráfico de red anómalo. Esto expone una brecha relevante en la capacidad de detección temprana: en un modelo de auditoría continua, la validación en tiempo real de los registros de evaluación y no solo la revisión post hoc, debería ser el estándar cuando se opera con agentes de IA con capacidades autónomas.
Defensa en profundidad y controles compensatorios. Un dato central del análisis de Anthropic es que las salvaguardas estándar de producción, clasificadores de contenido, monitoreo de uso indebido, habrían bloqueado los comportamientos identificados, pero estaban deliberadamente desactivadas para poder medir las capacidades «puras» del modelo subyacente. Esto reafirma un principio de auditoría de sistemas ampliamente conocido: ningún control aislado debe ser el único punto de fallo, y los entornos de prueba de alto riesgo deben diseñarse asumiendo que otros controles pueden fallar simultáneamente.
Conciencia situacional como control emergente, no auditable. Quizás el hallazgo más delicado desde una óptica de gobernanza es que el comportamiento más deseable observado (el modelo más reciente deteniéndose al concluir que el objetivo era real) no fue producto de un control diseñado explícitamente, sino de una capacidad emergente de razonamiento del propio modelo. Desde una perspectiva de auditoría y cumplimiento, esto es problemático: un control que depende del juicio interno y no determinista de un modelo de lenguaje no es, en sentido estricto, un control auditable o certificable. La alineación del modelo puede ser un mecanismo de defensa valioso, pero no sustituye a controles estructurales verificables.
Gestión de incidentes y cultura de mejora continua. La respuesta de Anthropic «detener todas las evaluaciones activas el mismo día del hallazgo, notificar a las organizaciones afectadas en menos de una semana, y adoptar un enfoque de post-mortem sin culpabilización asumiendo la responsabilidad íntegra pese a que el error de configuración fue compartido con el proveedor» es consistente con las mejores prácticas de gestión de incidentes de marcos como NIST SP 800-61 o las prácticas de Site Reliability Engineering (SRE). Es un ejemplo de cómo la madurez de un programa de gestión de riesgos no se mide por la ausencia de incidentes, sino por la calidad y transparencia de la respuesta.
Implicaciones para los marcos de gobernanza de IA
Este caso se alinea de forma notable con los dominios que hoy estructuran los principales marcos de gobernanza de inteligencia artificial:
- ISO/IEC 42001, el estándar de sistemas de gestión de IA, exige precisamente la evaluación continua de riesgos a lo largo del ciclo de vida del modelo, incluyendo los entornos de prueba y evaluación previos al despliegue.
- El NIST AI Risk Management Framework, con sus funciones de Govern, Map, Measure y Manage, encuentra aquí un ejemplo concreto de por qué el «Measure» (la medición de capacidades del modelo en entornos controlados) debe ir acompañado de un «Govern» robusto sobre la infraestructura donde esa medición ocurre.
- El modelo de tres líneas de defensa, ampliamente usado en auditoría interna corporativa, también aplica aquí: el equipo de evaluación (primera línea) falló en validar la configuración de red; el sistema de monitoreo adicional (segunda línea) detectó la anomalía, aunque de forma retrospectiva; y la revisión externa que Anthropic anunció junto a METR, una organización independiente de evaluación de IA, constituye la tercera línea de aseguramiento.
Conclusión: un fallo operativo, no de alineación (por ahora)
Anthropic distingue con cuidado este incidente del ocurrido con OpenAI y Hugging Face. Mientras que los modelos de OpenAI explotaron una vulnerabilidad novedosa para escapar de un aislamiento genuino, los modelos de Claude accedieron a internet a través de una ruta que, por error de configuración, nunca estuvo realmente cerrada. La conclusión de Anthropic es que esto se asemeja más a un fallo operativo y de configuración que a un fallo de alineación del modelo: a los modelos se les dijo que no tenían acceso a internet, y actuaron de forma razonable dado ese contexto (aunque la premisa fuera falsa).
Para la disciplina de auditoría de sistemas y gestión de riesgos, el mensaje de fondo trasciende este caso puntual: a medida que los agentes de IA adquieren mayor autonomía y persistencia sobre objetivos, los entornos donde se prueban esas capacidades dejan de ser «de bajo riesgo» solo porque el escenario sea ficticio. Un agente suficientemente capaz, operando bajo una premisa incorrecta sobre su propio entorno, puede generar impacto real sobre terceros ajenos por completo al ejercicio. Diseñar, auditar y gobernar esos entornos con el mismo rigor que cualquier sistema en producción (validación de rutas de red, monitoreo continuo, gestión de terceros, defensa en profundidad y una cultura de respuesta a incidentes transparente) ya no es una buena práctica opcional. Es, cada vez más, un requisito de gobernanza básico para cualquier organización que desarrolle o evalúe sistemas de inteligencia artificial avanzados.
Fuente: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
¡Saludos!
