Guía · IA y seguridad
Agentes de hacking con IA:qué es real y qué cambia.
La IA ya reduce el esfuerzo necesario para encontrar vulnerabilidades: fallos de seguridad que pueden permitir acceder a datos o hacer algo sin permiso. Google y Mozilla han documentado casos reales. El avance importa tanto a quienes protegen el software como a quienes intentan atacarlo, y cada vez llega a más manos.
Qué aporta un agente a una revisión de seguridad
Un modelo de IA puede leer código y señalar un posible error. Un agente puede además usar herramientas, comprobar lo que ha encontrado y continuar la revisión con ese resultado. Esa capacidad de encadenar trabajo explica por qué las mejoras en programación también se traducen en mejores herramientas de seguridad.
El NCSC, organismo británico de ciberseguridad, advierte de que la IA hará más fácil, rápido y barato descubrir y aprovechar fallos. Para una empresa, eso deja menos margen para aplazar las correcciones. Fuentes y versiones revisadas el 30 de septiembre de 2026.
Si necesitas aclarar qué autonomía aporta un agente, lee dónde ayudan los agentes de IA y qué debe seguir bajo reglas.
Tres casos que van más allá de una demostración
En julio de 2025, Google explicó que su agente Big Sleep había encontrado un fallo en SQLite, un componente de bases de datos utilizado en muchas aplicaciones. La investigación partió de información de su equipo de amenazas: había un agente capaz, pero también contexto aportado por personas.
En marzo de 2026, Mozilla confirmó 22 fallos de seguridad, 14 de gravedad alta, encontrados en colaboración con Anthropic. Sus ingenieros los verificaron y corrigieron en Firefox 148.
En abril, Mozilla informó de otros 271 fallos corregidos en Firefox 150 tras evaluar Claude Mythos Preview. Las dos cifras proceden de trabajos distintos; no sirven para calcular cuántas veces había mejorado el modelo.
Lo relevante es que los responsables del software confirmaron los problemas y publicaron las correcciones. Es una prueba más sólida que una respuesta convincente de un chatbot.
Encontrar un fallo no es lo mismo que entrar en un sistema
No todos los errores permiten lo mismo. En una tienda online, un fallo podría mostrar datos de un pedido a la persona equivocada sin dar acceso al resto del negocio. Sigue siendo grave, pero su alcance es distinto al de controlar el servidor.
Por eso, una revisión útil debe explicar qué falla, a quién afecta y cómo comprobar que se ha corregido. Una alerta del agente es el principio de ese trabajo.
- 01 Posible fallo El agente señala algo que merece revisión.
- 02 Fallo confirmado Se comprueba que el problema existe.
- 03 Alcance conocido Se determina qué datos o funciones afecta.
- 04 Corrección comprobada Se verifica que el cambio resuelve el problema.
Por qué algunos proveedores limitan estas capacidades
Anthropic ofrece un ejemplo concreto. A septiembre de 2026, reserva Mythos 5.1 a organizaciones verificadas. Fable 5.1 comparte el mismo modelo de base y permite buscar fallos en código, pero incorpora límites para las pruebas de intrusión y la creación de código que aproveche vulnerabilidades.
Es decir, la capacidad existe aunque el servicio limite su uso. Esto ayuda a entender por qué una herramienta acepta revisar una aplicación y rechaza otras tareas. Las condiciones dependen del proveedor y de la versión; no todos los modelos estadounidenses funcionan igual.
GLM-5.3: qué sabemos del avance de los modelos chinos
GLM-5.3, de Z.ai, ya se puede descargar y ejecutar fuera del servicio del fabricante. Su ficha técnica muestra mejoras frente a GLM-5.2 tanto en programación como en pruebas de seguridad. Son resultados del fabricante, que conviene contrastar con evaluaciones externas.
El 29 de septiembre, Anthropic describió cómo GLM-5.3 encontró fallos desconocidos y los combinó en un ataque funcional contra un navegador, en pruebas aisladas con investigadores. También observó protecciones insuficientes frente al uso malicioso. Es la evaluación de otro fabricante; aporta evidencia adicional a la de Z.ai.
El 17 de septiembre de 2026, CAISI, el centro estadounidense de evaluación de IA del NIST, lo situó como el modelo de pesos abiertos más capaz en ciberseguridad evaluado hasta entonces. Aun así, estimó que estaba unos cuatro meses por detrás de los líderes estadounidenses en sus pruebas.
Los cuatro meses son una comparación entre modelos publicados, no una predicción. CAISI también probó modelos estadounidenses sin sus restricciones de ciberseguridad cuando correspondía. Para una empresa importa tanto lo que puede hacer un modelo como quién puede acceder a esas capacidades.
Qué cambia cuando el modelo se puede descargar
«Pesos abiertos» significa que se pueden descargar los datos que permiten ejecutar el modelo en infraestructura propia, bajo su licencia. No obliga a publicar todo el proceso de entrenamiento ni significa que funcione en cualquier portátil: los modelos grandes siguen necesitando equipos potentes.
La diferencia de control es importante. Como explica AISI, el instituto británico de seguridad de IA, un proveedor puede bloquear cuentas en su servicio, pero tiene mucho menos control sobre las copias que otros ejecutan.
Esto amplía el acceso para investigadores y empresas, y también las posibilidades de abuso. El acceso deja de depender exclusivamente de unas pocas plataformas, aunque usar bien estas herramientas siga requiriendo recursos y conocimientos.
Qué revisaría hoy en una web o aplicación
Para quien mantiene una web, la decisión inmediata es revisar qué fallos podrían afectar a clientes, datos o actividad. Empezaría por estos puntos:
- Saber qué servicios están accesibles desde internet y retirar los que ya no se utilizan.
- Tener a alguien responsable de aplicar las actualizaciones de seguridad, con un plazo claro.
- Comprobar que cada usuario solo puede acceder a sus datos y que las claves privadas permanecen en el servidor.
- Dar a cada cuenta, integración o agente únicamente los permisos que necesita.
- Conservar registros para investigar incidentes y probar que las copias de seguridad se pueden restaurar.
La IA también puede ayudar en esta revisión. La usaría sobre código propio, en un entorno de pruebas y con permisos limitados. Una persona debe confirmar los hallazgos y revisar las correcciones. El resultado útil es un problema resuelto; que el agente no haya encontrado nada no garantiza que todo esté bien.
Para revisar dónde guarda permisos y credenciales una aplicación, empieza por secretos en apps, claves API y seguridad del backend.
Fuentes y lecturas
- Google · Big Sleep, julio de 2025Hallazgo en SQLite con inteligencia de amenazas.↗
- Mozilla · marzo de 2026Validación y correcciones en Firefox 148.↗
- Mozilla · abril de 2026Resultados de la evaluación con Mythos Preview.↗
- Anthropic · acceso y salvaguardasCondiciones consultadas el 30 de septiembre de 2026.↗
- Z.ai · ficha de GLM-5.3Pesos disponibles y resultados publicados por el fabricante.↗
- Anthropic · estudio de GLM-5.3, 29 de septiembre de 2026Capacidades y protecciones evaluadas por otro fabricante en entornos controlados.↗
- CAISI/NIST · GLM-5.3, septiembre de 2026Evaluación externa publicada el 17 de septiembre y condiciones de las pruebas.↗
- AISI · riesgos de los pesos abiertosDiferencias de control tras distribuir un modelo.↗
- NCSC · defensa ante el avance de la IAOrientación para empresas, 15 de abril de 2026.↗
Dudas antes de empezar
¿La IA hace más fácil hackear?
Sí, reduce el tiempo y los conocimientos necesarios para algunas tareas, como encontrar ciertos fallos. Eso beneficia tanto a quienes revisan software como a quienes intentan atacarlo. El éxito de un ataque sigue dependiendo del sistema y de sus defensas.
¿GLM-5.3 ya iguala a los mejores modelos cerrados en ciberseguridad?
No según la evaluación de CAISI de septiembre de 2026. Destaca entre los modelos de pesos abiertos, pero seguía por detrás de los líderes estadounidenses en esas pruebas. El resultado también depende de las herramientas y restricciones con las que se evalúa cada modelo.
¿Puede una revisión con IA decirme si mi web es segura?
Puede descubrir problemas y ayudar a corregirlos, pero no certificar por sí sola que la web sea segura. Hay que validar lo encontrado y revisar también permisos, configuración y componentes externos.