Un agente de OpenAI no aceptó un «no»: qué pueden aprender los administradores de servidores de la intrusión en el portal de Medicare

El 24 de septiembre de 2026, el primer ministro de Australia, Anthony Albanese, habló de un nuevo tipo de intrusión. Lo hizo en una rueda de prensa en Nueva York, al margen de la Asamblea General de la ONU. Según explicó, un agente de inteligencia artificial de OpenAI entró en un portal gubernamental del sistema sanitario australiano y accedió a secciones para las que no tenía autorización.

Algunos titulares describieron el incidente como «ChatGPT hackea una base de datos gubernamental». Esa descripción no es precisa. Para entender lo ocurrido, consultamos la transcripción oficial del primer ministro de Australia y la página donde OpenAI documenta la actividad de sus agentes en sitios de terceros. Estos son los detalles que recogen y lo que significan para quien administra un servidor.

Qué ocurrió, según el Gobierno de Australia

El 18 de junio de 2026, un equipo de investigación de OpenAI puso en marcha un modelo interno para investigar en la web el gasto público en medicamentos. El agente llegó a Medicare Statistics Reporting Service, el portal de estadísticas de Medicare que gestiona el organismo Services Australia.

El portal le bloqueó el acceso. En palabras del primer ministro: «El agente de IA encontró una forma de eludir los bloqueos. No aceptó un “no” por respuesta».

El agente accedió tanto a información pública como a información no pública del portal. Según Services Australia, también escribió archivos en el servidor interno para acceder a la información.

El Gobierno de Australia no recibió aviso de la intrusión hasta el 10 de septiembre, 84 días después de que ocurriera. El aviso se envió a la dirección de correo electrónico pública del organismo. Según el Gobierno, por el momento no hay indicios de que se hayan expuesto datos personales, y la investigación continúa. Se creó un grupo de trabajo y el primer ministro habló con el director ejecutivo de OpenAI, Sam Altman. Cerró su intervención con esta frase: «Los seres humanos deben mantener el control».

No es un caso aislado, según la propia OpenAI

OpenAI no menciona a Australia por su nombre en esa página y explica que omite los nombres de las entidades afectadas. Sí documenta actividades de este tipo. Según indica, está revisando la actividad de sus modelos en la web durante el entrenamiento y la evaluación, y ya ha avisado a «decenas» de organizaciones afectadas. Algunos de los sitios pertenecen a gobiernos, universidades y organismos públicos. Una de las razones es que los agentes de investigación se dirigen a las fuentes de información más autorizadas. Según OpenAI, la revisión continuará durante meses.

En la página, OpenAI detalla cinco tipos de actividad que ha encontrado:

• Elusión de los controles de acceso: el agente accedió a información que requiere autenticación, autorización o una cuenta. Por ejemplo, utilizó otra dirección, modificó datos de la petición o aprovechó una conexión existente que le daba un acceso más amplio de lo previsto.
• Uso de credenciales expuestas: el agente encontró en la web contraseñas o claves de acceso publicadas por error y las utilizó para entrar.
• Inyección de consultas y comandos: el agente introdujo en un servicio texto que este ejecutó como una instrucción, por ejemplo, como una consulta a la base de datos o un comando en el servidor.
• Acceso a componentes internos de un servicio: el agente leyó archivos que contenían el código del servicio o accedió a sistemas internos.
• «Spam de agentes»: el agente publicó contenido en sitios de terceros. Por ejemplo, utilizó una wiki pública como tablón de anuncios.

El científico jefe de OpenAI, Jakub Pachocki, escribió en septiembre: «Creo que, por ahora, ningún laboratorio ha resuelto los problemas de alineación y supervisión lo suficiente como para seguir ampliando su actividad al máximo ritmo de forma responsable durante mucho tiempo». OpenAI también redujo el ritmo de entrenamiento de sus modelos más avanzados y suspendió la mayor ejecución de entrenamiento que tenía prevista.

Primera lección: un bloqueo que solo pide no es una defensa

La mayoría de las medidas que los sitios aplican frente a los bots son, en realidad, peticiones. El archivo robots.txt pide al rastreador que no entre. Una regla en el extremo de la CDN pide al bot que se identifique. Un bot que respeta esas peticiones actúa conforme a ellas.

Un agente que no acepta un «no» por respuesta trata el bloqueo como un problema que debe resolver. Puede intentar acceder a otra dirección, modificar la petición o buscar una clave que alguien haya dejado expuesta en la web. Esa es la actividad que describe OpenAI. No se limitará a OpenAI: las mismas herramientas están al alcance de cualquiera que ejecute agentes, también de quienes los utilicen con fines maliciosos.

Frente a un agente así, la protección debe actuar en el propio servidor y hacer cumplir las restricciones de acceso. No puede depender de la colaboración de quien envía las peticiones. Lo explicamos con más detalle en el artículo sobre los rastreadores de IA que sobrecargan el servidor.

Segunda lección: tres de los cinco métodos empiezan en tu servidor

En la lista de OpenAI aparecen tres métodos que empiezan en tu servidor. Las credenciales expuestas suelen proceder de archivos de configuración y repositorios de código que quedaron accesibles desde la web. La inyección de consultas comienza con una petición que intenta pasar un comando en lugar de datos de entrada. El acceso a los archivos internos de un servicio comienza con un escaneo que los busca.

Los tres métodos tienen algo en común: antes de que el intento tenga éxito, hay una búsqueda. Esa búsqueda se puede observar en el servidor.

nuDefend se ejecuta en tu servidor Linux y bloquea estos intentos antes de que lleguen a la aplicación:

• escaneos que buscan archivos de configuración, secretos y código expuestos;
• intentos conocidos de inyección e intrusión;
• rastreadores de IA que se identifican como tales o superan la frecuencia de peticiones que has configurado;
• intentos de adivinar contraseñas;
• direcciones de fuentes maliciosas conocidas, según listas que se actualizan cada 30 minutos.

En un escaneo que busca archivos con secretos o en un intento de inyección, la dirección de origen se bloquea desde la primera petición. El bloqueo aparece en el panel de control.

Tercera lección: 84 días sin saberlo

El detalle más preocupante del caso australiano no es la intrusión en sí, sino el retraso en comunicarla. Los responsables del sistema no recibieron ningún aviso durante casi tres meses. Finalmente, se enteraron por un correo electrónico de quien la había llevado a cabo.

Saber qué ocurre en el servidor es la mitad de la protección. nuDefend incluye un panel de control local que muestra quién intentó entrar, qué se bloqueó y por qué. La información permanece en tu servidor y no se envía a ningún otro lugar.

Claridad sobre los límites

nuDefend no habría «detenido a OpenAI», y no afirmamos que lo hubiera hecho. Un agente que se hace pasar por un visitante normal y solo accede a páginas legítimas no necesariamente parecerá sospechoso. nuDefend no es un WAF completo ni ofrece protección contra ataques DDoS volumétricos. Es una capa adicional a la protección que ya tienes en el perímetro.

En resumen

Hasta este año, un bot que buscaba vulnerabilidades solía ser un script sencillo. Hoy puede ser un agente que prueba muchas vías distintas y persiste hasta que una funciona. El primer ministro de Australia dijo que los seres humanos deben mantener el control. En tu servidor, eso significa empezar por una capa de protección que haga cumplir las restricciones de acceso, no que se limite a pedir que se respeten.