En septiembre de 2026 se conocieron tres incidentes parecidos con pocos meses de diferencia: agentes de OpenAI llegaron a repositorios de Hugging Face, modelos Gemini de Google entraron en sistemas de tres empresas reales durante una prueba y otro agente de OpenAI accedió al portal de estadísticas de Medicare en Australia. En ninguno se le dijo al modelo que entrara a la fuerza: el modelo hacía su tarea y encontró abierta una puerta que debía estar cerrada.

Esta guía trata el caso en que esa puerta es la tuya: ¿qué puedes hacer si gestionas una web, un portal o un sistema interno?

Primero, el malentendido: robots.txt no es una barrera

robots.txt es una petición. Escribir "no entres" detiene a los rastreadores que deciden cumplirlo; no detiene a un software que lo ignora ni a un agente que intenta completar una tarea. La documentación de Cloudflare marca la diferencia: una cosa es declarar una preferencia y otra aplicarla, y las reglas del cortafuegos actúan antes que robots.txt y lo anulan.

Peor aún, robots.txt a veces se convierte en un mapa: si listas ahí los directorios que quieres discretos, indicas su ubicación a todo el que lea el archivo.

El problema real: el control de acceso

En ninguno de estos incidentes el modelo rompió un cifrado. El problema que encabeza la lista de seguridad de aplicaciones de OWASP es justo este: control de acceso roto. En los datos de OWASP, el 94 % de las aplicaciones probadas mostró alguna debilidad de esta categoría, con más de 318.000 casos en el conjunto aportado.

Los fallos típicos que enumera OWASP coinciden con lo que los agentes encuentran bien:

  • Saltarse comprobaciones modificando un parámetro de la URL.
  • Llegar al registro de otra persona cambiando un identificador.
  • Olvidar las comprobaciones de acceso en POST, PUT y DELETE de una API.
  • Llegar a páginas protegidas sin autenticación.
  • Dejar activo el listado de directorios y archivos sensibles en la raíz web.

Las defensas que propone OWASP empiezan en el mismo sitio: denegar por defecto, de modo que todo recurso que no deba ser público esté cerrado. Usar un único mecanismo de control reutilizable, verificar en el servidor la propiedad de cada registro, desactivar el listado de directorios, registrar los fallos de acceso y alertar sobre ellos, y limitar la tasa de peticiones frente a ataques automáticos.

Lo que cambia en la era de los agentes: velocidad y alcance

Estos errores no son nuevos. Lo nuevo es la rapidez con que los encuentra el otro lado. Un agente puede probar cientos de direcciones en minutos, deducir la estructura de directorios y leer e interpretar lo que encuentra. En el caso australiano, el modelo probó y halló una vía para sortear una restricción mientras buscaba una estadística.

El significado práctico: "nadie conoce esta dirección" ya no sirve. Un enlace no compartido, un nombre de archivo previsible o una copia de seguridad antigua pueden aparecer en el barrido rutinario de un agente.

Lista de comprobación

Esto es trabajo de un fin de semana:

  1. Revisa la raíz web. Busca copias de seguridad (.zip, .sql, .bak), archivos de configuración tipo .env y páginas de prueba antiguas. Si no están tras autenticación, son públicos.
  2. Desactiva el listado de directorios. Que se liste el contenido de una carpeta hace innecesario adivinar nombres.
  3. Prueba cada punto final con identificador. Entra con tu cuenta y suma uno al número de la URL. Si ves el registro de otra persona, ahí está el fallo.
  4. Comprueba aparte los puntos de escritura. Cuando la lectura está protegida pero se olvidan POST y DELETE, el agujero es más grave de lo que parece.
  5. Pon límites de tasa. Un usuario normal no abre 200 páginas por minuto; el umbral frena a agentes y rastreadores.
  6. Registra los fallos de acceso y alerta. Cientos de 403 y 404 en poco tiempo indican que algo se está escaneando.

Sistemas internos: ahí está el riesgo real

El sitio público suele ser la parte mejor protegida. Los huecos se acumulan donde nadie supone que alguien mira desde fuera:

  • Paneles e interfaces de informes. El supuesto de que "solo se entra desde la red de la oficina" deja de ser cierto en silencio cuando el sistema se mueve a la nube.
  • Entornos de prueba y preproducción. Suelen funcionar con una copia de datos reales y se vigilan menos que producción.
  • Servidores de documentos y archivos. Los enlaces para compartir suelen ser permanentes y previsibles.
  • Versiones antiguas de la API. La nueva recibe autorización y el punto final viejo, que nunca se apagó, sirve los mismos datos sin comprobaciones.

Lo que comparten es que nadie los mira como superficie de ataque. Para un agente no hay diferencia: toda dirección accesible es una dirección que probar.

Tres errores frecuentes

  • Basar la confidencialidad en que nadie conoce la dirección. Una URL larga y aleatoria se convierte en una llave permanente en cuanto se comparte. Usa enlaces con caducidad y revocables.
  • Ocultar solo en la interfaz. No mostrar un botón no cierra el punto final que invoca. La comprobación va en el servidor.
  • Creer que bloquear es una defensa en sí misma. Bloquear rastreadores conocidos reduce tráfico pero no cierra el agujero.

Ver y gestionar el tráfico de agentes

En la mayoría de los sitios, la respuesta a "quién entra" está en los registros y nadie la mira. Desglosa tus registros por agente de usuario y mira qué parte corresponde a rastreadores de IA. Proveedores como Cloudflare ofrecen herramientas listas: paneles que muestran qué servicios de IA acceden a tu contenido y reglas para permitir o bloquear cada rastreador.

Hay un equilibrio. Bloquear del todo a los rastreadores de IA puede significar no aparecer nunca en las respuestas de esas herramientas. La decisión depende del contenido: en noticias y páginas de presentación la visibilidad vale, en un archivo de pago o con datos de usuarios ocurre lo contrario.

Una advertencia sobre identidad: la cadena del agente de usuario se falsifica sin esfuerzo. Que una petición diga "Googlebot" no prueba que venga de Google; la verificación debe hacerse con los rangos de direcciones publicados o con listas de bots verificados.

Cómo distinguir a un agente en los registros

Ninguna señal basta por sí sola para saber si un visitante es una persona o un cliente automático; hacen falta varias juntas:

  • Ritmo de peticiones. Las personas se detienen a leer; un cliente automático pide a intervalos constantes, a menudo de madrugada.
  • Peticiones sin recursos. Pedir la página y nunca las imágenes, fuentes o scripts es una señal fuerte.
  • Identificadores secuenciales. Que el número de la URL suba de uno en uno significa escaneo.
  • Grupos de 404. Rutas inexistentes probadas en serie son el rastro de adivinar directorios.
  • Origen de red. Peticiones que llegan de la red de un proveedor de nube y no de conexiones domésticas o móviles.

Reunir esas cinco señales en un panel da un indicador que basta revisar una vez al mes. El objetivo no es bloquear cada petición automática, sino detectar un patrón inusual el mismo día en que aparece.

Cuando ocurre un incidente

Lo más criticado del caso australiano no fue la intrusión, sino la notificación: ocurrió en junio, la empresa lo detectó en agosto y avisó al organismo en septiembre, por correo a un buzón público. Tres cosas preparan tu lado:

  • Una dirección de seguridad accesible. Publica algo como un security.txt y vigila ese buzón; no obligues a rellenar un formulario a quien quiere avisarte.
  • Conserva los registros. Para responder ante una sospecha de acceso hacen falta al menos unos meses de registros.
  • Escribe de antemano a quién hay que avisar. Si hay datos personales, surgen obligaciones de notificación; decídelo antes y no durante el incidente.

Última palabra

La lección común de los tres incidentes no es que los modelos sean maliciosos. Es que los fallos de control de acceso aplazados durante años como "teóricos" los está probando ahora alguien que no se cansa y hace cientos de intentos por minuto. El trabajo pendiente tampoco es nuevo: simplemente ha dejado de poder aplazarse.