El pasado fin de semana, varios atacantes consiguieron tomar el control de cuentas de Instagram sin hackear ningún servidor, sin instalar ningún malware y sin necesitar la contraseña de las víctimas. ¡Les bastó con hablar con el chatbot de soporte de Meta!

Le pidieron al asistente que vinculara la cuenta a un nuevo correo electrónico y el chatbot procesó la solicitud para, posteriormente, enviar el código de verificación al atacante. Con ese código, pudieron restablecer la contraseña y la cuenta ya era suya.

Entre los perfiles afectados se encontraban la cuenta de la Casa Blanca de la era Obama, la cadena de cosméticos Sephora y un alto cargo de la Fuerza Espacial estadounidense. La propia Meta confirmó el ataque el lunes y aseguró haber corregido la vulnerabilidad.

El fallo no estaba en la infraestructura. Estaba en la lógica del agente.

Qué pasó exactamente

El chatbot de Meta tenía permiso para ejecutar acciones en nombre del usuario: reportar fraudes, gestionar suplantaciones o tramitar recuperaciones de cuenta. Era un agente con acceso real a los sistemas. Y el problema es que nadie le enseñó a verificar quién estaba al otro lado antes de actuar.

Los expertos en ciberseguridad tienen un nombre para esto desde los años 80: confused deputy. Esto es, un agente confundido. Es cuando un sistema ejecuta órdenes con privilegios que no le corresponden a quien las da, porque no distingue entre el titular legítimo y un impostor.

Para evadir las alertas automáticas de la plataforma, los atacantes usaron VPNs para simular que estaban en la misma ubicación geográfica que la víctima. En algunos casos, crearon vídeos deepfake de los titulares con imágenes obtenidas del propio Instagram.

Una tecnología avanzada al servicio de una vulnerabilidad primitiva: un agente al que nadie le definió los límites.

No es un problema de Meta sino de método

Meta tiene miles de ingenieros y presupuestos de seguridad que ninguna pyme puede imaginar. Y, aún así, desplegó un agente con capacidad de modificar credenciales sin validación de identidad.

No lo hicieron por incompetencia sino por la misma razón por la que la mayoría de empresas cometen errores similares: el foco estaba en que el agente funcionara, no en qué pasaría si alguien lo manipulaba.

Cuando una empresa integra un sistema basado en IA para gestionar atención al cliente, ejecutar flujos de trabajo o acceder a datos internos, está transfiriendo confianza operativa a un agente que va a tomar decisiones. Esas decisiones pueden ser manipuladas si no se han definido correctamente sus límites, sus permisos y sus puntos de validación.

La pregunta no es si tu empresa va a tener un chatbot o un agente. Ya los tienes… o los tendrás pronto. La pregunta es si sabes exactamente qué puede hacer, qué no puede hacer y quién supervisa qué antes de que actúe.

Lo que las empresas ignoran cuando despliegan IA

Hay un patrón que veo con frecuencia en los proyectos de adopción de IA en empresas medianas. Se elige la herramienta, se integra en el sistema, se comprueba que funciona correctamente en condiciones normales y se pone en producción ‘a las bravas’.

Nadie se pregunta qué pasa en condiciones anormales, qué ocurre si alguien le da instrucciones que no debería poder dar, qué datos puede filtrar si se le hace la pregunta adecuada o qué acciones puede ejecutar si se le manipula.

Por eso, esta situación no es un problema tecnológico, es un problema de criterio antes del despliegue.

El incidente de Meta es el ejemplo más visible de una categoría de riesgo que ya tiene nombre en la industria: la superficie de ataque de la IA. No es el servidor, ni la red, ni la aplicación. Es la lógica del modelo. Y las herramientas de ciberseguridad tradicionales no están diseñadas para verla.

Qué deberías hacer antes de que te pase a ti

No hace falta tener 2.000 millones de usuarios para estar expuesto. Cualquier empresa que haya integrado un chatbot de atención al cliente, un asistente con acceso a datos internos o un agente que ejecuta tareas automáticas tiene una superficie de ataque que gestionar.

Tres preguntas concretas que deberías poder responder hoy:

  • ¿Qué acciones puede ejecutar cada agente o asistente de IA que tienes en producción?
    No en teoría. En la práctica real. Si no lo sabes con certeza, hay un problema.
  • ¿Quién verifica la identidad antes de que el agente actúe sobre una cuenta, un dato o un proceso crítico?
    Si la respuesta es «el propio agente», hay un problema.
  • ¿Tienes visibilidad de lo que está haciendo tu IA en tiempo real?
    No de los resultados finales. Del proceso completo. Si no tienes esa trazabilidad, no puedes detectar un incidente hasta que ya es demasiado tarde.

La autenticación multifactor sigue siendo el consejo más básico y más ignorado. El ataque a Meta no tuvo éxito en las cuentas que la tenían activada. Y, ciertamente, no es el sistema más vistoso, pero funciona.

Más allá de eso, el siguiente paso es auditar la IA que ya tienes desplegada con los mismos criterios con los que auditas cualquier sistema con acceso a datos sensibles. No como una herramienta de productividad sino como lo que realmente es: un agente que actúa en nombre de tu empresa.

La IA no falla. Falla el criterio con el que se despliega

Meta no desplegó una IA defectuosa. Desplegó una IA sin los controles adecuados para el nivel de acceso que tenía. Es una diferencia importante.

El error no fue tecnológico sino, más bien, de diseño. Nadie definió qué debía verificar el agente antes de actuar, qué acciones estaban fuera de su alcance y qué nivel de supervisión humana necesitaba en las operaciones más sensibles.

Si eso le puede pasar a Meta, le puede pasar a cualquier empresa que esté desplegando IA más deprisa de lo que está pensando cómo gobernarlo.

La velocidad de adopción no es el problema. El problema es adoptarla sin criterio.