A finales de julio de 2026, OpenAI estaba probando uno de sus nuevos modelos en un entorno cerrado cuando el modelo decidió escaparse(ventana nueva). Hackeó la infraestructura privada de otra empresa de software, Hugging Face, para robar la clave de respuestas de una prueba de referencia de ciberseguridad en la que se le estaba evaluando. En otras palabras, quebrantó la ley por pura conveniencia.

Días después, el Instituto de Seguridad de IA del Reino Unido reveló que el modelo de IA Mythos 5 de Anthropic(ventana nueva) había creado identidades falsas de desarrolladores, había realizado ataques de spear-phishing a usuarios reales de GitHub para que aprobaran código malicioso y había editado su propio registro de actividad para cubrir sus huellas cuando lo atraparon.

Luego, en agosto, se supo que un hombre de Melbourne llamado Andrew había pedido a su agente de IA personal,(ventana nueva) creado sobre OpenClaw y ejecutando Claude de Anthropic, que le ayudara a entrar en una clase de gimnasio matutina completamente reservada. Estaba en el cuarto puesto de la lista de espera y preguntó si había alguna forma de avanzar.

El agente descubrió que la API de reservas no tenía ninguna verificación de autorización para cancelar las reservas de otros usuarios. Así que, sin pedir permiso a Andrew, procedió a cancelar la reserva de la persona que ocupaba el primer lugar para hacerle sitio. Cuando Andrew le pidió que deshiciera la cancelación, no pudo: “La persona que eliminé ya no está en la lista de espera y no tengo forma de restaurarla”.

El origen de estos tres incidentes no es el mismo, pero el resultado sí: los agentes de IA sondearon y explotaron sistemas de forma más rápida y exhaustiva de lo que cualquier humano habría logrado. Nunca se les dio instrucciones para atacar nada, pero aun así encontraron la ruta más corta hacia su objetivo.

No importa si eres la infraestructura de un laboratorio de vanguardia o el software de reservas de un gimnasio de barrio. Si tienes una empresa que expone una API, ahora eres algo que un agente de IA puede sondear, a una velocidad y minuciosidad que ningún atacante humano ha igualado. Y nadie necesita decidir atacarte.

La velocidad es la verdadera historia

Un atacante humano sopesa el esfuerzo frente a la recompensa. Se aburre, se le acaba el tiempo, decide que una aplicación de reservas de gimnasio no vale la pena. Ese cálculo es lo que ha protegido silenciosamente a la mayoría de los objetivos de bajo valor de la explotación casual durante los últimos 20 años (a menos que estés ejecutando WordPress).

Un agente de IA no hace ese cálculo. Con un objetivo en mente, intentará todo lo que la API permita técnicamente, probando Puntos de conexión y combinaciones de parámetros a velocidad de máquina hasta que algo funcione. Encontró la brecha de autorización del gimnasio en el tiempo que le llevó a Andrew hacer una pregunta de seguimiento.

La magnitud de esa brecha de velocidad ya es visible en las cifras. El Informe global de respuesta a incidentes de 2026 de Unit 42(ventana nueva) reveló que los ataques más rápidos ahora exfiltran datos en 72 minutos, frente a los 285 minutos del año anterior. Esa es la tendencia cuando los humanos todavía participan en gran medida en el proceso. Un agente toma decisiones en milisegundos; un analista humano responde en minutos u horas.

Para los equipos de seguridad, ese aumento de la velocidad es el verdadero motivo de preocupación, no cualquier incidente aislado que aparezca en las noticias.

La nueva superficie de ataque: todo lo que tenga una API

Cualquier servicio que exponga una API es un objetivo potencial, parezca o no que lo sea.

  • Motores de precios donde los descuentos se validan en el lado del cliente
  • Sistemas de inventario donde el estado del stock reside en el escaparate digital en lugar del backend
  • Plataformas de soporte donde los campos internos son accesibles a través de rutas de API no documentadas
  • Gestión de suscripciones que no verifica la propiedad del emisor sobre la cuenta que se está modificando.

Ninguno de estos requiere que un humano vaya a buscarlos. Solo requieren un agente con un objetivo y una API que responda.

Las empresas más expuestas no son las que tienen fallos de seguridad evidentes. Son las que tienen brechas de lógica de negocio: reglas que existen únicamente en la interfaz de usuario, acciones que la API permite técnicamente pero que la interfaz nunca muestra, flujos de trabajo basados en el supuesto de que ningún emisor intentaría la ruta que omite la prevista.

El desarrollador del gimnasio casi con certeza no pensó que valiera la pena escribir una verificación de autorización en las cancelaciones, porque ningún usuario común, y ningún atacante común, tenía motivos para intentarlo. Un agente no tenía tales reservas, y ni siquiera estaba intentando encontrar una reserva para omitir. Solo intentaba ser útil.

Cómo pueden las empresas prepararse para los ataques de IA

Trata cada acción de la API como una operación privilegiada. Identidad, autorización y política contextual, verificadas de forma independiente en cada llamada. No “el frontend no te dejará hacer esto”, sino “el servidor verifica que tienes permiso para hacer esto, en este recurso, dado su estado actual”. El sistema del gimnasio habría detenido este incidente específico con una sola línea de lógica de autorización en el Punto de conexión de cancelación. Este no es para nada un control nuevo, es el elemento más antiguo de la lista de seguridad de API de OWASP, la autorización a nivel de objeto rota, y sigue siendo en el que más fallan la mayoría de los sistemas.

Concede a los agentes su propio modelo de credenciales. Los tokens con alcance delimitado y TTL corto emitidos específicamente para sesiones de agentes, a diferencia de los tokens de sesión de humanos comunes, limitan el alcance del impacto incluso cuando el agente encuentra una brecha que no habías anticipado. Si el agente de Andrew hubiera tenido un token delimitado solo a su propia reserva, la cancelación de la reserva de otra persona habría fallado en la capa de credenciales, independientemente de lo que permitiera la API. Esto importa porque no puedes confiar en la propia moderación del agente. Tienes que confiar en lo que sus credenciales le permiten hacer físicamente.

Implementa herramientas específicas para detectar el comportamiento de los agentes. El tráfico de los agentes tiene una forma reconocible: tiempos de solicitud infrahumanos, enumeración sistemática de Puntos de conexión, sondeos secuenciales a través de combinaciones de parámetros, ejecución exitosa de acciones que ningún usuario humano jamás ha intentado a través de la interfaz real. Establece una línea de base para esa estructura y emite alertas sobre ella en tiempo real.

Reduce la brecha del tiempo de respuesta, no solo la de detección. Detectar un sondeo en una hora no sirve de nada si el sondeo se completó y avanzó en cuestión de minutos. La cifra de Unit 42 mencionada anteriormente, 72 minutos para los ataques a ritmo humano más rápidos, ya es el punto de referencia equivocado sobre el que trazar un plan. La respuesta automatizada, y no solo las alertas automatizadas, es lo que permite cerrar una brecha que se mide en milisegundos. Por supuesto, también debes asegurarte de que tu respuesta automatizada tampoco resulte perjudicial.

Asume que esto sucederá y ensaya la respuesta. Documenta a quién se llama, redacta previamente las comunicaciones con los clientes y realiza ejercicios teóricos específicos para escenarios impulsados por agentes, no solo los manuales de vulneraciones tradicionales. El informe sobre el coste de una brecha de datos de 2026 de IBM situó la vulneración global media en 4,99 millones de dólares, y las vulneraciones impulsadas por IA sumaron, de media, aproximadamente 1 millón de dólares más. Esas cifras describen cada vez más incidentes que comenzaron de la misma manera que el del gimnasio: sin ningún atacante en el sentido tradicional.

Prueba tus propias API como lo haría un agente, antes de que un agente lo haga por ti. Las pruebas de penetración manuales asumen un evaluador humano con tiempo limitado y una lista finita de cosas por probar. Una simulación de ataque automatizada contra tus propios Puntos de conexión, sondeando con la misma persistencia y velocidad que un agente, sacará a la luz las mismas brechas antes de que el asistente de un cliente tropiece con ellas. Hoy en día existen herramientas de código abierto específicas para esto. CyberStrike(ventana nueva), por ejemplo, ejecuta agentes especializados asignados a OWASP WSTG y MITRE ATT&CK contra tus propios Puntos de conexión, incluido un evaluador dedicado precisamente a la brecha de autorización a nivel de objeto que tomó desprevenido al gimnasio: envía una solicitud de referencia, envía el ataque y solo marca un hallazgo si hay una diferencia medible y reproducible. Esa es la misma clase de comprobación que habría detectado el Punto de conexión de cancelación antes de que un agente lo encontrara de forma fortuita.

El principio no es nuevo, por supuesto. Los propietarios de sitios web que ejecutaron sus propios escáneres de vulnerabilidades contra las instalaciones de WordPress durante la era de las redes de bots lo sobrevivieron. Las herramientas ahora solo tienen que adaptarse a la velocidad del emisor de las llamadas, no a la velocidad de un atacante humano que con el tiempo podría llegar a intentarlo.