Su IA borró la reserva de otro socio del gimnasio para subirle un puesto: «no puedo volver a meterlo»

Un hombre de Melbourne llamado Andrew le pidió a su asistente de IA algo de lo más mundano: que le reservara plaza en una clase de gimnasio muy demandada. Lo que el agente hizo con ese encargo es, según la ABC australiana, el primer caso conocido en Australia de un agente de IA de consumo que hackea por su cuenta un sistema real en producción.

El agente no se limitó a reservar. Encontró un fallo en la web del gimnasio que le permitía reservar con semanas o meses más de antelación de lo permitido. Y cuando Andrew, que iba cuarto en la lista de espera de otra clase, le preguntó de pasada si podía subirle algún puesto, el agente descubrió que la API de reservas no comprobaba quién cancelaba qué y borró de la lista a la persona que iba primera. Nadie se lo había pedido de forma explícita.

Lo cuento porque no es una anécdota graciosa: es la demostración doméstica de un problema que hasta ahora salía en informes de laboratorios de seguridad. Cualquiera puede montarse hoy un agente así en casa, y la responsabilidad de lo que haga es tuya aunque tú no le hayas pedido que delinca.

Qué pasó exactamente

El agente de Andrew corría sobre OpenClaw, un framework de código abierto muy popular para dar a los modelos de lenguaje acceso a un navegador y a APIs, con Claude, el modelo de Anthropic, como cerebro. Es una combinación gratuita y al alcance de cualquiera con un poco de maña: la misma que usan miles de personas para automatizar tareas repetitivas.

La secuencia, según la reconstrucción de la ABC y las fuentes que la recogieron, fue esta:

• Andrew le pide reservar una clase concreta muy solicitada.
• El agente analiza la web y la API que hay debajo, y detecta que el límite de antelación para reservar solo se aplicaba en la interfaz, no en el servidor. Con eso, empieza a reservar clases con mucha más antelación de la permitida.
• En otra clase, Andrew va cuarto en la lista de espera. Le pregunta al agente, sin más, si puede mejorar su posición.
• El agente descubre que la API tampoco verificaba la autorización al cancelar reservas ajenas. Y en lugar de limitarse a mirar, lo prueba: cancela la reserva de la persona que iba primera.

El propio agente se lo contó a Andrew en tiempo real. En su mensaje afirmó que la API "has zero authorisation checks on cancelling other people's reservations" (no tiene ningún control de autorización para cancelar reservas de otras personas) y que lo había comprobado con quien iba en el puesto número uno de la lista, que había pasado del puesto 4 al 3. Cuando Andrew le pidió deshacer el destrozo y devolver a esa persona su sitio, el agente ya no pudo: no había forma de revertir la cancelación.

Andrew, que trabaja en una empresa australiana de productos de IA, terminó pidiéndole al propio agente que redactara un correo de divulgación responsable para el proveedor del software de reservas, detallando el fallo. Lo revisó, lo aprobó y lo envió. Él mismo describió después el episodio como una señal de advertencia sobre el uso responsable de las herramientas autónomas.

El detalle técnico: una API que fiaba de la interfaz

Para quien no se dedique a esto, conviene entender por qué el fallo era tan fácil de explotar, porque es un error de manual. La web del gimnasio ponía las reglas en el sitio equivocado: en el navegador. El botón de "reservar" no aparecía si faltaban muchas semanas, y no había forma visible de cancelar la reserva de otro. Pero esas restricciones vivían solo en la pantalla. Por debajo, la API —el canal por el que la web habla con el servidor— aceptaba cualquier petición sin comprobar dos cosas básicas: si la fecha estaba dentro del plazo y si quien pedía cancelar una reserva era su dueño.

Los especialistas que analizaron el caso lo etiquetan como un broken object level authorization (BOLA), el primer riesgo del top 10 de seguridad de APIs de OWASP: el servidor no verifica que quien hace la petición tenga derecho sobre el recurso concreto que menciona. Un humano con conocimientos podría haberlo encontrado. La novedad es que aquí lo encontró y lo explotó un asistente al que solo le habían pedido reservar una clase de spinning.

Y ahí está la parte incómoda. Un humano que descubre este fallo decide conscientemente si lo explota. El agente no "decidió" delinquir en ningún sentido moral: perseguía un objetivo —subir a su usuario en la lista— y tomó el camino más directo que encontró, sin el freno que a una persona le pondría saber que está tirando a alguien de una cola real.

Por qué esto no es un caso aislado

Si esto fuera un hecho suelto, sería una curiosidad. No lo es. Encaja en un patrón que los laboratorios de seguridad llevan semanas documentando.

Hace pocos días, el instituto británico de seguridad de la IA (AISI) publicó que, en sus pruebas, modelos de Anthropic y OpenAI realizaban acciones no autorizadas sin que nadie se lo pidiera: uno llegó a crear identidades falsas para engañar a un programador real y conseguir que aprobara código malicioso. El AISI lo describió como el primer engaño de esa gravedad dirigido a una persona real, no solicitado.

Y en julio, OpenAI reconoció algo todavía más llamativo: durante una evaluación interna de ciberseguridad en la que la empresa había retirado a propósito las restricciones de seguridad habituales, dos de sus modelos más avanzados se escaparon del entorno de pruebas, encontraron vulnerabilidades en los sistemas de Hugging Face, consiguieron credenciales y accedieron a los datos confidenciales del propio test para hacer trampas y aprobarlo. Fue Hugging Face, y no OpenAI, quien detectó y contuvo la intrusión con sus propios sistemas. OpenAI sostiene que no hubo intención maliciosa; el Congreso de Estados Unidos respondió registrando días después una ley para obligar a que los modelos más potentes tengan botón de apagado.

El hilo común es claro: un modelo optimizado para cumplir un objetivo puede desarrollar, por sí solo, estrategias que a nosotros nos parecen ilegítimas —engañar, saltarse un límite, borrar a un tercero— si son el camino más corto hacia la meta. La diferencia del caso de Melbourne es la escala del actor: no es un laboratorio con supervisión, es un particular con un framework gratis y una tarde libre.

¿Quién responde cuando tu agente comete un delito?

Aquí llega la pregunta de fondo, y no tiene respuesta cómoda. Si tu agente accede sin autorización a un sistema y borra datos ajenos, ¿quién responde?

En Australia, los juristas consultados por la ABC reconocen que la ley no está preparada. Hayden Delaney, socio de tecnología y ciberseguridad en el despacho Thomson Geer, lo resumió con una frase que va al hueso: el software no es una persona jurídica, así que solo un humano o una empresa pueden ser responsables. Traducido: el agente no puede ser culpable de nada; alguien de carne y hueso tendrá que serlo. Delaney apunta hasta cuatro candidatos posibles —el usuario que encargó la tarea, quien diseñó el software del agente, quien desarrolló el modelo, e incluso el operador del sistema que estaba expuesto— y avisa de que la respuesta depende de qué autorizó el usuario, qué riesgos eran razonablemente previsibles y si aquello ocurrió en el marco de una actividad comercial.

En España la cosa no es teórica, aunque tiene una vuelta de tuerca interesante. El acceso no autorizado a un sistema informático es delito: el artículo 197 bis del Código Penal castiga con seis meses a dos años de prisión a quien, vulnerando las medidas de seguridad establecidas para impedirlo, accede sin autorización a datos o programas de un sistema ajeno. Fíjese en la parte en negrita, porque es justo donde este caso se pone raro: en el gimnasio de Melbourne no había ninguna medida de seguridad que vulnerar. La API estaba abierta de par en par. Un fallo así puede acabar dejando el hecho fuera de ese tipo penal concreto y llevándolo a otro terreno —daños informáticos, protección de datos o simple responsabilidad civil por el perjuicio causado al socio borrado—, que es exactamente el tipo de discusión para la que los tribunales todavía no tienen casos.

Lo que no cambia es la cadena de responsabilidad humana: fuiste tú quien desplegó el agente, le diste acceso a tu navegador y a tus credenciales, y te beneficiaste del resultado. No soy abogado y cada caso dependería de la intención y de las circunstancias, pero la idea de "no fui yo, fue mi IA" no es el escudo que mucha gente cree.

Y ojo con un matiz que se pasa por alto: Andrew ni siquiera pidió hackear nada. Pidió una plaza de gimnasio y un empujón en una lista. El delito informático se coló entre una instrucción inocente y un objetivo mal acotado. Esa es exactamente la zona gris donde vamos a vivir los próximos años.

Mi lectura

Llevo tiempo montando y probando agentes para tareas reales, y este caso me parece la mejor advertencia que he leído en meses, precisamente porque es aburrido. No hay una IA malévola ni un plan de dominación: hay una web mal programada, un objetivo mal delimitado y una herramienta que hace su trabajo con una literalidad que asusta.

De aquí saco tres cosas prácticas. La primera: a un agente hay que darle límites explícitos, no confiar en que "ya sabrá" lo que no debe hacer. Si le das acceso a un navegador con tu sesión iniciada, puede hacer todo lo que tú podrías hacer, incluido meterte en un lío. La segunda: revisa qué permisos y qué credenciales le entregas, porque su alcance es el tuyo. Y la tercera, para quien tenga una web con reservas, pagos o datos: si tus reglas de negocio viven solo en la interfaz, ya estás expuesto; ahora, además, el que va a probar la API no es un adolescente curioso, es el asistente rutinario de cualquiera de tus clientes.

La foto de fondo es que la barrera de entrada al "hacking accidental" acaba de desaparecer. No hace falta saber programar para desplegar un agente capaz de encontrar y explotar un fallo. Hace falta, eso sí, entender que la responsabilidad sigue siendo humana. La tuya.