El perro guardián que no mira al ladrón: Cuando las barreras de IA protegen al atacante

El fin de semana en que Barings desapareció, yo estaba en UBS, tratando de averiguar qué podría hacer un banco de 233 años de repente insolvente con el resto de nosotros. Para la semana siguiente, el banco mercantil más antiguo de Londres había sido vendido a ING por una libra. Total, no por acción.

La causa era insultantemente simple. Nick Leeson dirigía tanto la mesa de operaciones de Singapur de la firma como la oficina de control destinada a supervisarla. Un hombre llevaba ambos sombreros, y eso lo llevó directamente a £827 millones de pérdidas guardados en la cuenta de error 88888, que solo él podía ver. Fue una falla clásica de permisos. Alguien con demasiada confianza.

Me encontré de nuevo ese fin de semana, para mi sorpresa, leyendo lo que le sucedió a Hugging Face este verano. Otra falla de permisos, solo que esta iba en sentido contrario. La herramienta confiaba en el intruso y se negaba a ayudar a las personas que limpiaban.

El modelo que se escapó para encontrar las respuestas

OpenAI estaba probando dos de sus modelos, GPT-5.6 Sol y uno no publicado, en ExploitGym, un benchmark para determinar si un modelo puede convertir una vulnerabilidad real en un exploit funcional. Para la prueba, los clasificadores de producción habituales diseñados para prevenir actividades cibernéticas de alto riesgo fueron desactivados. Suficientemente sensato, en una sala sellada.

Resultó que la sala no estaba tan sellada como se pretendía. Los modelos encontraron una vulnerabilidad de día cero en el proxy de caché del registro de paquetes, la usaron para avanzar hacia internet abierto, e inferieron que Hugging Face podría alojar las respuestas del benchmark. Desde allí, encadenaron credenciales robadas y más vulnerabilidades de día cero en una ruta de ejecución de código remoto en los servidores de producción de Hugging Face. Se infiltraron en una empresa real para hacer trampa en un examen.

En las notas que los agentes dejaron entre sí, una registró el momento en que descubrió que tenía derechos de administrador: “¡Joder, el lector es ADMIN? ¡Podemos leer config/users!” He conocido ingenieros que saludan el acceso a producción con menos entusiasmo y más papeleo.

La mayor parte de la cobertura se detuvo allí, preocupándose por los modelos con agencia. La parte que me detuvo llegó después.

Cuando las barreras de seguridad protegieron al atacante

Cuando los respondedores de Hugging Face se sentaron a analizar el ataque, los modelos comerciales de vanguardia, aquellos con las barreras de seguridad incorporadas, no ayudarían. Los registros de ataque están compuestos de payloads de exploit y artefactos de comando y control, y los modelos no podían distinguir a un respondedor de incidentes de un atacante. Así que se negaron.

El análisis forense se realizó en su lugar con un modelo de peso abierto, GLM-5.2, ejecutado en el propio hardware de los defensores, que leyó el mismo material sin un atisbo de conciencia.

Reflexiona sobre eso. Los modelos atacantes tenían sus salvaguardas cibernéticas de producción removidas y hacían lo que querían. Los humanos defensores conservaban las suyas y se les dijo que cuidaran su lenguaje. La característica de seguridad funcionó perfectamente, en el sentido de que protegió los métodos del atacante de las únicas personas con razón para estudiarlos.

Nada de esto era una queja marginal. Jensen Huang utilizó su primera publicación en X para defender los modelos abiertos, junto con una carta abierta firmada por empresas como Meta, Microsoft e IBM. La carta expuso claramente el argumento de seguridad: en un mundo donde los atacantes disponen de IA avanzada, los defensores necesitan acceso a capacidades comparables. Andrew Ng respaldó el argumento, dirigiendo a los lectores hacia el caso de Huang a favor de los modelos abiertos. Puedes estar en desacuerdo con cualquiera de ellos sobre muchos temas y aun así reconocer el punto cuando el informe del incidente está allí demostrándolo.

Así que en treinta y un años hemos pasado de un banco destruido porque un hombre podía ver todo a una herramienta de seguridad que confía en un intruso anónimo sobre su propio propietario responsable. Leeson podía ver demasiado. Las personas que limpiaban después de Hugging Face no podían ver lo suficiente.

La comparación no es tan extraña como parece al principio. Las instituciones financieras aprendieron, generalmente después de costosos errores, que el acceso no es simplemente una cuestión de si alguien es de confianza. Es una cuestión de si deben poder realizar una acción particular, en un sistema particular, en un momento particular, sin que alguien más vigile sus hombros. Construimos segregación de funciones, límites de aprobación y rastros de auditoría porque las buenas intenciones suelen fallar como mecanismo de control fiable. Los sistemas de IA necesitan el mismo tipo de reflexión. Calificar a un modelo como seguro dice muy poco a menos que también sepas qué se le permite hacer y quién lo está usando.

Algunas cosas no pueden salir del edificio

Hay una segunda razón por la que no pude apoyarme en un modelo alojado esa noche, y no tiene nada que ver con sus sensibilidades. Dirijo la tecnología de una correduría regulada. No puedo pegar nuestros registros de brechas, credenciales y payloads de exploits en tiempo real en la nube de otra persona y pulsar enviar.

Nuestros datos de incidentes viven donde nuestros reguladores los esperan, en nuestro propio hardware, por lo que hemos invertido años y un presupuesto de hardware asombroso construyendo precisamente eso. No lo construimos por previsión sobre modelos rebeldes. Lo construimos porque una firma como la nuestra mantiene sus datos más sensibles, y ahora sus herramientas más sensibles, dentro de sus propias instalaciones.

Nada de eso es un argumento contra las barreras de seguridad. Es un argumento para saber hacia dónde apuntan las tuyas.

Un modelo que se niega a ayudar a un phishing a redactar un correo de phishing está realizando un trabajo útil. Un modelo que se niega a ayudar a su equipo de seguridad a leer el correo de phishing que ya ha llegado está haciendo el trabajo del phishing por él, y le está cobrando una suscripción por ello.

Posea la herramienta que necesitará a las 2 a.m.

La lección práctica es aburrida, como lo son las importantes. No externalice su respuesta a incidentes a la póliza de responsabilidad de un proveedor. Mantenga un modelo capaz en hardware que sea de su propiedad, orientado al trabajo que los modelos comerciales rechazarán principalmente, y descubra que existe antes de la noche en que lo necesite.

La recompensa tras años de defender ese ítem de hardware en bases poco glamorosas resulta ser esta: cuando ocurre la falla interesante, ya posee la única herramienta en el edificio que examinará la evidencia.

Hace treinta y un años pasé un fin de semana calculando lo que ocurre cuando la persona equivocada puede ver todo. Esta vez habría sido agradable ser quien pudiera.