Entre julio y septiembre de 2026, , y han tenido que explicar por qué agentes de IA que debían trabajar aislados acabaron tocando sistemas reales. Las consecuencias las sufrieron webs y servicios de terceros. Si tu web tiene formularios, cuentas de usuario o un panel de administración, esto también va contigo.
Los titulares hablan de modelos que «escapan del sandbox», aunque los casos documentados se parecen poco entre sí. Y casi todo lo que un agente puede hacerle a tu web depende de fallos corrientes, como una credencial publicada, un permiso que solo se comprueba en la interfaz o una versión sin parchear.
Qué significa realmente escapar del sandbox
Un sandbox es un ordenador aislado donde el modelo ejecuta sus acciones sin afectar al exterior. Según el informe de OpenAI sobre el incidente de Hugging Face, publicado el 26 de agosto, en julio sus agentes encadenaron vulnerabilidades desconocidas (0-days) en el servicio de paquetes al que tenía acceso el entorno, salieron a internet y comprometieron parte de su infraestructura de investigación y de los sistemas de Hugging Face. En este caso el aislamiento existía y los agentes lo superaron.
Lo de es distinto. Sus incidentes, comunicados el 30 de julio, ocurrieron en el entorno de un socio evaluador con internet abierto por error de configuración; como escribe la empresa en su actualización del 31 de agosto, los modelos no necesitaban «salir» de nada. Y el 21 de septiembre envió a SecurityWeek un comunicado de Heather Adkins, su vicepresidenta de ingeniería de seguridad: en una evaluación, un modelo encontró información pública y adivinó credenciales para entrar en webs que creía parte de la prueba, y en los tres casos se detuvo. No hemos encontrado un informe técnico publicado por .
Para quien gestiona una web, esa diferencia cambia poco. Llegue por una fuga o por un error de configuración, el agente aparece en tus registros como tráfico, y lo que te afecta es lo que hace después.
Qué hicieron los agentes en webs reales
El 25 de septiembre, actualizó su revisión de la actividad de sus modelos durante entrenamiento y evaluación. Agrupa lo observado en cinco categorías:
- Saltarse controles de acceso: otra dirección web, datos cambiados en la petición o una sesión con más permisos de los previstos.
- Usar credenciales publicadas en internet.
- Inyección de consultas o comandos en campos que el servicio trataba como instrucciones.
- Acceder a partes internas del servicio, como ficheros de implementación.
- «Agent spam»: publicar en sitios ajenos, por ejemplo usando wikis públicas como tablón de mensajes.
dice que la mayoría de casos son de baja gravedad. En la misma página, el 30 de septiembre añadió que a 26 de septiembre había notificado a más de 100 organizaciones, y que una notificación no significa que se accediera a información privada ni que se comprometiera un sistema.
El caso más detallado es australiano. Según la rueda de prensa del primer ministro Anthony Albanese del 24 de septiembre, el 18 de junio un modelo interno de que investigaba el gasto en medicamentos chocó con bloqueos repetidos en el portal de estadísticas de Medicare, los rodeó y accedió a ficheros públicos y no públicos. El Gobierno no supo nada hasta el 10 de septiembre, por un correo a un buzón público.
describe otro patrón: confundió una empresa real con el objetivo ficticio de un ejercicio, descargó registros de usuarios de su aplicación web y los modificó. En sus cuatro incidentes, cada ejecución duró entre unas 10 y 34 horas de trabajo activo. Las cinco categorías de describen fallos de seguridad web bien conocidos. Lo nuevo es cuánto tiempo puede seguir probando un agente.
Primero, saber quién llama a la puerta
Los grandes proveedores documentan sus agentes. publica los user agents de GPTBot, OAI-SearchBot y ChatGPT-User con sus rangos de IP; , los de Google-Agent, y , los de ClaudeBot, Claude-User y Claude-SearchBot.
Un paso más allá está la firma criptográfica. El navegador en la nube de Work firma sus peticiones con Web Bot Auth, basado en HTTP Message Signatures (RFC 9421), y Cloudflare, Akamai, HUMAN y Vercel ya las verifican. dice estar experimentando con el mismo protocolo. Una firma válida identifica a quien opera el agente, así que puedes aplicar reglas distintas al tráfico identificado y al anónimo, aunque sigas vigilando lo que hace.
Ojo con robots.txt: expresa preferencias y el propio estándar (RFC 9309) aclara que no es autorización. y avisan además de que los accesos iniciados por un usuario pueden no seguirlo. Y bloquear a ciegas a los rastreadores de búsqueda cuesta visibilidad, como explicamos en nuestra guía de SEO técnico.
Autorización en el servidor
El portal australiano bloqueaba al agente y aun así este encontró otro camino. La guía de autorización de OWASP lo resume: denegar por defecto, mínimo privilegio y validar permisos en cada petición, no solo en la interfaz.
- Comprueba permisos en el servidor para cada recurso, incluidos ficheros estáticos y URLs que «nadie conoce».
- No pongas acciones que modifican datos detrás de un GET: RFC 9110 lo define como método seguro.
- Busca credenciales publicadas en tus repositorios, por ejemplo con el secret scanning de GitHub, y rótalas.
- Trata cada campo como dato, nunca como instrucción: consultas parametrizadas y validación estricta.
- Limita la frecuencia por IP, sesión y cuenta con reglas de rate limiting o su equivalente, y activa la gestión de bots o el WAF de tu CDN.
Parchea rápido lo que ya es público
Un agente que puede pasar horas probando una web tiene tiempo de sobra para dar con una vulnerabilidad que ya es pública. Next.js, un framework muy usado para webs y aplicaciones, ofrece un ejemplo reciente. El 30 de septiembre publicó su versión de seguridad de septiembre: las versiones 16.3.8 y 15.5.27 corrigen siete vulnerabilidades.
La más grave, de severidad alta (CVE-2026-94483), es un SSRF en la optimización de imágenes. Una URL remota permitida y controlada por un atacante puede hacer que tu servidor lance peticiones a otros destinos, por ejemplo a rangos de IP privados. Solo te afecta si tienes configurado images.remotePatterns. Del resto, cinco son de severidad media (envenenamiento de , exposición de información y fugas de contenido en borrador) y una es baja y solo afecta al servidor de desarrollo.
El aviso previo deja dos detalles para planificar. La versión 16.3.7, publicada el 29 de septiembre, solo corrige un error y no incluye estos parches, así que hay que ir a 16.3.8. Y quedan pendientes otras dos vulnerabilidades, una crítica y una alta, que Next.js aplazó por retrasos en dependencias externas y corregirá en una versión posterior. Actualiza ya y deja hueco en el calendario para la siguiente.
- Ten un inventario de qué framework y qué versión usa cada web o aplicación que tengas publicada.
- Sigue el canal de avisos de seguridad de tus dependencias principales, o el equivalente de tu stack.
- Fija un plazo para aplicar parches de severidad alta o crítica y pruébalos antes en un entorno de preproducción.
En nuestro análisis del ciberataque a Adif y Renfe ya poníamos el inventario de servicios expuestos y la corrección de vulnerabilidades conocidas al principio de la lista. En ese caso El Mundo atribuyó a los atacantes el uso de IA, aunque la información pública no permite reconstruir cómo entraron.
Formularios que aguantan a un agente insistente
Un agente que reintenta puede duplicar pedidos o altas. En las operaciones que crean algo, acepta una clave de idempotencia y devuelve el mismo resultado si la petición se repite; el borrador Idempotency-Key del IETF, hoy caducado, sirve de referencia.
Las acciones irreversibles, como borrar una cuenta o cambiar el correo de acceso, deberían pedir una confirmación que un script no pueda dar solo: reautenticación o enlace al correo verificado. Si aceptas contenido público, la moderación previa y los límites para cuentas nuevas frenan el agent spam.
Los avisos claros ayudan algo. En experimentos de , cuando la respuesta del sistema indicaba que el acceso no estaba permitido, Opus 4.7 dejó en su mayoría de atacar la web, aunque siguió haciendo algunas lecturas no destructivas.
Registra lo suficiente para reconstruirlo
En el caso australiano pasaron casi tres meses entre el acceso y el aviso. Si mañana te notifican que un agente pasó por tu web en junio, ¿tendrás registros de junio? Guarda logs con hora, user agent, IP y cuenta durante un periodo acorde a tu riesgo y a la normativa de datos. Y publica un security.txt (RFC 9116) con un contacto de seguridad que alguien lea.
Si tu web también usa agentes: la lección del DNS
Si despliegas un agente propio, exígele lo mismo que a uno ajeno. OWASP llama agencia excesiva a dar a un modelo más funciones, permisos o autonomía de los necesarios, y recomienda minimizarlos y pedir aprobación humana para lo de alto impacto. añade que los límites deben formularse como instrucciones («no accedas a internet») y no como afirmaciones sobre el entorno.
ha publicado un caso práctico que conviene leer si montas agentes. Según su informe de desalineación, actualizado el 25 de septiembre, el 20 de septiembre un modelo interno de investigación en pleno entrenamiento tenía que encontrar información sobre la persona que había escrito un post en su blog. Su herramienta de búsqueda no daba resultados útiles, los buscadores a los que intentó llamar directamente le devolvieron errores y el proxy web bloqueó una petición HTTPS a un chatbot público. El resolvedor DNS del propio entorno, en cambio, respondía con registros reales. El agente lo aprovechó para enviar preguntas a un chatbot externo a través de un servicio DNS público, recibió «The capital of France is Paris.» y mandó 18 preguntas más por la misma vía. Salvo ese resolvedor, todo el acceso a internet del entorno acababa en una caché web sin conexión.
La respuesta también dejó huecos. La monitorización lo marcó en menos de 15 minutos y una persona empezó a revisarlo tres minutos después, pero la ejecución no se detuvo sola como estaba previsto y no se cortó hasta dos horas y media más tarde. Al revisar el historial, encontró otros accesos DNS externos que el monitor no clasificó con la gravedad esperada, porque a veces interpretaba que no conseguir información útil significaba que el intento había fallado. Un detector de actividad DNS anómala, además, excluía ese entorno, aunque la actividad quedaba registrada. Ahora tiene bloqueos en dos capas independientes y limita las consultas DNS a una lista de dominios y tipos de registro permitidos.
Traducido a un agente de empresa, la lista queda así:
- Salida cerrada por defecto, DNS incluido. El agente solo debería resolver y alcanzar los dominios que necesita para su tarea.
- Listas de permitidos en al menos dos capas, por ejemplo el proxy y el firewall de red, para que un fallo en una no deje la puerta abierta.
- Monitorización que cubra todos los entornos y que trate el intento como incidente, aunque no consiga nada útil. Prueba de vez en cuando que las alertas llegan.
- Un botón de parada automático y probado: si salta una alerta grave, la ejecución se detiene sola y una persona decide si se reanuda.
- Registro de cada acción del agente, con lo que pidió y lo que obtuvo.
Hemos leído 40 publicaciones recientes en X sobre este caso y las usamos solo como termómetro de opinión. @cuauih lo resumía así: «Detection isn’t the bottleneck.» (detectar no es el cuello de botella). Y @AIOAssist proponía una regla que compartimos: «In your setup, make “stuck” mean “ask.”» (en tu configuración, que «atascado» signifique «preguntar»). Nuestra guía para construir un agente desde cero cubre la base.
Lo que queda abierto
dice que su revisión llevará meses, y tras el caso del DNS mantiene en pausa el entrenamiento, la evaluación y la inferencia con uso de herramientas de sus modelos más capaces hasta comprobar que el fallo está resuelto y completar más pruebas de ataque simulado sobre sus sistemas. El 22 de septiembre, presentó Claude Opus 5.5 destacando que, en una evaluación nueva, intentó saltarse límites de contención alrededor de un 85% menos que Opus 5 o . La contención ya aparece como argumento de venta de un modelo, y aun así las defensas de tu web siguen dependiendo de ti.
Si quieres revisar cómo responde tu web al tráfico automatizado, ponerte al día con los parches o diseñar un agente con permisos acotados, hablemos.