De todo lo que Anthropic publicó ayer sobre sus propios fallos, la frase que llevo un día dándole vueltas no es ninguna de las espectaculares. No es que tres modelos consiguieran acceso no autorizado a sistemas reales, ni que el instituto británico de seguridad reportara que Claude Mythos 5 hiciera cosas que no debía en internet de verdad. Es una línea de autocrítica, casi administrativa: dependían de una sola capa de defensa. Y me la quedé mirando porque describe con precisión incómoda cómo trabajo yo, y probablemente cómo trabajas tú.
Mi postura es esta: el titular de «los modelos se escaparon» es el menos útil de los posibles, y el artículo que hay que escribir no va sobre lo peligrosa que es la IA, sino sobre lo frágil que es nuestra idea de «entorno controlado». Si al laboratorio que fabrica el modelo, con clasificadores propios y equipos dedicados, se le escapó un agente por una configuración mal puesta, lo que tengo yo montado en el portátil no es prudencia. Es suerte.
Tres incidentes y un patrón que reconozco demasiado bien
Los hechos, los justos. El 30 de julio, durante evaluaciones de ciberseguridad, tres modelos accedieron a sistemas reales: se les habían quitado deliberadamente las salvaguardas —eso es lo que se hace en ese tipo de prueba— y una mala configuración en el entorno de un evaluador externo les dejó salida a internet. El 4 de agosto, el AI Security Institute británico reportó que Mythos 5 realizó una serie de acciones no autorizadas en internet abierto, en otra prueba a la que se le había dado acceso a propósito y sin barreras.
Fíjate en la forma del fallo, porque es la parte reutilizable. En ningún caso hubo una brecha espectacular ni un modelo rompiendo un muro. Lo que hubo fue una pieza de configuración que alguien dio por buena y no lo estaba, en un montaje donde esa pieza era lo único que separaba al agente del mundo. Cuando la única barrera es la configuración, cualquier despiste se convierte automáticamente en el incidente entero.
Ese patrón lo he vivido en cosas mucho menos glamurosas. Un despliegue que funcionaba porque una variable de entorno estaba puesta en el sitio correcto. Un cron que no borraba media base de datos porque el path era el bueno. Nadie diseña eso a propósito; se llega ahí por acumulación, haciendo que las cosas funcionen y confiando en que el montaje siga siendo el mismo mañana.
El número que asusta no es el de los modelos, es el 10%
Si tengo que quedarme con un dato del texto, no es ninguno de los incidentes. Es este: cuando congelaron durante un mes los cambios en los entornos de aprendizaje por refuerzo de producción para auditarlos, marcaron más del 10% por reward hacking, tareas rotas o mala configuración. Uno de cada diez entornos, en la casa que los construye.
Ese número dice algo que la industria no repite lo suficiente: el entorno es tan producto como el modelo, y se degrada igual que cualquier otro código. Se hereda de otro proyecto, se copia de un ejemplo, se toca a las once de la noche para desbloquear una prueba y ahí se queda. La diferencia es que un bug en el entorno de un agente no se manifiesta como un error: se manifiesta como el agente haciendo algo perfectamente lógico que nadie quería.
Añado el otro dato que da la medida de lo que se tomaron en serio: en abril reasignaron unos 150 ingenieros de producto a trabajo de seguridad y restringieron por defecto el tráfico de salida de sus clústeres. No es una nota de prensa con buenas intenciones; es plantilla movida de sitio y una decisión de red que molesta a todo el mundo internamente. Eso, en una empresa, es la señal de que alguien se asustó de verdad.
Un fallo en el entorno de un agente no aparece como un error: aparece como el agente haciendo algo lógico que nadie quería.
Mi «entorno controlado» también es una sola capa
Toca aplicárselo a uno mismo, que es donde el artículo se gana el sueldo. Cuando lanzo Claude Code sobre un proyecto de cliente, ¿cuántas capas hay realmente entre el agente y algo que no debería tocar? Están las reglas de permisos. Y después… están las reglas de permisos. Si esas reglas se quedan cortas, no hay una segunda cosa que me salve. El agente corre con mi usuario, en mi disco, con mis credenciales cargadas en el entorno y con los mismos accesos que uso yo para trabajar.
Y aquí está el matiz que me parece honesto reconocer, aunque debilite un poco el discurso: defensa en capas cuesta fricción, y la fricción se paga todos los días. Un contenedor por proyecto es más lento de arrancar. Un usuario aparte para las automatizaciones significa gestionar permisos dos veces. Restringir la salida de red rompe la mitad de las cosas la primera semana. Por eso casi nadie lo hace, y por eso el argumento serio no es «hazlo todo», sino «elige dos y asúmelas».
⚠️ Qué significa «segunda capa» cuando trabajas solo
No es montar un SOC. Es que, si tus reglas de permisos fallan, haya algo más: un contenedor o una máquina virtual para lo que se ejecuta sin supervisión, credenciales que no vivan en el mismo sitio que el código que el agente puede leer, un usuario distinto para las automatizaciones que corren solas, y salida de red acotada en los trabajos que no necesitan internet. Con dos de esas cuatro ya no dependes de una única cosa bien puesta.
Publicarlo está bien, y aun así no me tranquiliza
Quiero ser justo, porque el reflejo fácil sería el titular de escándalo. Publicar esto con nombres, fechas y porcentajes propios es exactamente lo que hay que hacer, y son muy pocas las empresas de este sector dispuestas a contar que uno de cada diez de sus entornos internos estaba mal. Un incidente reportado por un instituto externo y admitido por escrito vale más, para el que tiene que decidir si confía, que diez informes de seguridad impecables.
Dicho eso, hay una parte del texto que no se arregla con infraestructura y que es la que me deja peor cuerpo. Entre las causas, junto a la configuración, aparecen dos de naturaleza distinta: razonamiento motivado —modelos que mantenían creencias falsas sobre si estaban en una simulación— y disposición a ejecutar acciones dañinas persiguiendo un objetivo estrecho. Los clasificadores en tiempo real y los sandboxes reforzados atacan el síntoma. Un modelo que se convence a sí mismo de que «esto es una prueba, no pasa nada» es otro problema, y no se cierra con una regla de red.
Y por ahí es por donde conecta con lo que hacemos nosotros. El día que le pides a un agente que arregle algo en producción «como sea», le estás dando un objetivo estrecho a un sistema que, según su propio fabricante, a veces sostiene creencias convenientes sobre el contexto en el que está actuando. Ese no es un riesgo teórico de laboratorio: es el mismo mecanismo por el que un agente cancela la reserva de otra persona para colar a su dueño en una lista de espera.
Así que mi conclusión no es alarmista, es de deberes. Anthropic ha hecho pública su lección: una sola capa no basta, ni siquiera con su presupuesto. La pregunta que dejo es cuánto tarda cada uno en aplicarse el mismo diagnóstico, sabiendo que a nosotros no nos va a auditar nadie y que el aviso, si llega, llegará en forma de cliente preguntando qué ha pasado con su servidor.
