Los investigadores de seguridad ofensiva, los que encuentran vulnerabilidades antes que los criminales, no pueden usar los modelos frontier para su trabajo. Los guardrails de OpenAI y Anthropic bloquean solicitudes que huelen a exploit, incluso cuando quien las hace es un defensor.

Chris Anley, chief scientist de NCC Group, lo explica con un ejemplo concreto: pedirle a un modelo que explote un bug es el paso fundamental para confirmar que la vulnerabilidad es real y debe cerrarse. Si el guardrail rechaza, el defensor se queda sin herramienta. El prompt “corrige este código” sirve tanto para defender como para atacar: separar ambos usos es imposible sin romper la herramienta.

Algunos investigadores han vuelto a modelos open-source sin guardrails. Paolo Stagno de Crowdfense evita los modelos cloud por una razón adicional: cargar datos en un modelo cloud significa arriesgar que terminen en los próximos ciclos de entrenamiento. Para bugs que valen millones de dólares, es un riesgo inaceptable.

La paradoja es clara. Los laboratorios propietarios impulsan limitar modelos open-weight citando riesgos de seguridad, como reportamos ayer. Pero los modelos open sin guardrails son los únicos que los investigadores de seguridad pueden usar sin bloqueos ni fugas de datos. La seguridad que los labs quieren construir en sus modelos es la misma que expulsa a los profesionales serios de esos modelos.

En detalle

Varios investigadores de seguridad ofensiva, la rama de la ciberseguridad que busca activamente vulnerabilidades en sistemas, describen un problema operativo concreto. No es una queja genérica: es un bloqueo en el trabajo diario.

Existen programas de acceso. OpenAI tiene Trusted Access for Cyber, Anthropic el Cyber Verification Program: quién trabaja en seguridad puede candidatarse, pasar verificación y obtener modelos con menos restricciones. Pero la aprobación no está garantizada y los guardrails, incluso aligerados, siguen interfiriendo.

Chris Anley, chief scientist de NCC Group, lo explica con un ejemplo preciso. Cuando encuentras un posible bug, el siguiente paso es confirmarlo construyendo un exploit. Si le pides a un modelo de IA que lo intente y el guardrail rechaza, pierdes la herramienta cuando más la necesitas. El prompt “corrige este código” es el mismo que sirve para cerrar la vulnerabilidad y entenderla a fondo. Anley lo compara con un martillo: herramienta y arma, inseparables.

Paolo Stagno, CTO de Crowdfense, añade un segundo nivel al problema. Incluso sin guardrails, usar un modelo cloud para trabajar en vulnerabilidades no parcheadas significa cargar datos sensibles en infraestructura de terceros. El riesgo es que esos datos terminen en ciclos de entrenamiento futuros. Por eso Stagno usa modelos frontier solo para reverse engineering y cambia a modelos open-source locales para todo lo relacionado con descubrimiento y desarrollo de exploits.

Giuseppe Cali, otro investigador entrevistado, tiene una posición diferente. Usa IA solo para reverse engineering inicial y construcción de herramientas de soporte, no para descubrimiento de bugs. Su posición sugiere que, por ahora, el rol de IA en seguridad ofensiva es complementario más que central.

También está el contexto de controles de exportación. En junio el gobierno estadounidense impuso restricciones en los modelos Mythos y Fable de Anthropic, en parte por un report que demostraba la posibilidad de eludir guardrails diseñados para prevenir ataques. Las restricciones fueron parcialmente revocadas: Fable 5 volvió a acceso general el 1 de julio, Mythos 5 fue reintroducido solo para organizaciones estadounidenses verificadas.

Hace días reportamos cómo un investigador encontró una vulnerabilidad RCE en WordPress gastando 25 dólares de compute con GPT-5.6 (/es/radar/wordpress-rce-gpt-5-6-sol-security-research-25-dollars). Ese ejemplo muestra el potencial de IA para seguridad defensiva: exactamente el tipo de trabajo que los guardrails arriesgan hacer más difícil.

Para quién usa IA en contextos técnicos serios, el panorama tiene dos implicaciones concretas.

La elección entre cloud y local es también una elección de soberanía de datos. Cuando tus datos son vulnerabilidades no parcheadas, cargarlos en un modelo cloud es un riesgo empresarial, no solo técnico.

La retórica sobre seguridad de modelos frontier y la práctica de seguridad ofensiva apuntan en direcciones opuestas. Los labs quieren modelos que no puedan ser usados para atacar, pero atacar es exactamente cómo se descubren las vulnerabilidades a cerrar. La pregunta es dónde ponen límite los guardrails: y por ahora se detienen demasiado pronto, dejando a quien defiende con una herramienta mutilada.