Manus, Gmail y un correo que le susurró al oído: el día que un asistente de inteligencia artificial obedeció a un desconocido

Les voy a contar algo que, si uno lo piensa en frío, parece de ciencia ficción pero ya pasó y lo demostraron en serio: un correo electrónico cualquiera, de esos que llegan sin pedir permiso, fue capaz de darle órdenes a un agente de inteligencia artificial y hacer que ejecutara código en su propio entorno. No es un cuento de hackers de película, es el resultado de una prueba controlada que publicó Salt Labs, el equipo de investigación de la empresa de seguridad Authentik, y que involucra a Manus, el asistente autónomo chino que viene ganando titulares desde hace unos meses. La buena noticia es que la falla fue reportada y está parcheada. La noticia de verdad, la que me parece que vale la pena mirar de cerca, es lo que este episodio dice sobre el momento que estamos viviendo con estas herramientas.

Para entender la dimensión del asunto hay que detenerse un segundo en cómo funcionan estos agentes. A diferencia de un chat tradicional, al que uno le hace una consulta y punto, un agente como Manus está pensado para ejecutar tareas: revisar la casilla, mover archivos, buscar información, completar formularios, interactuar con otras aplicaciones. Para eso necesita permisos. Y acá aparece el nudo de la cuestión: si uno le concede acceso al correo electrónico, el asistente va a leer mensajes que no escribió nadie de nuestro círculo de confianza, sino remitentes que pueden ser cualquiera, incluso un desconocido con buenas o malas intenciones. La línea entre "leer un correo" y "cumplir lo que un correo dice" parece delgada, y la investigación de Salt Labs mostró que, en determinadas condiciones, esa línea se puede cruzar.

El mecanismo que aprovecharon los investigadores tiene un nombre técnico que viene sonando cada vez más: inyección de instrucciones o, en inglés, prompt injection. La idea es simple y a la vez preocupante: si el sistema interpreta el contenido de un mensaje como una orden en vez de como un texto a analizar, entonces lo que diga ese mensaje puede convertirse en una acción. En la prueba, los investigadores escondieron código malicioso dentro de un correo usando una técnica llamada JSFuck, que

Un payload escrito con seis caracteres

JSFuck es una rareza del mundo de la programación: permite escribir código JavaScript válido usando solamente seis caracteres, que son los símbolos de paréntesis, corchetes, signo más y signo de exclamación de cierre. Para una computadora el resultado es perfectamente entendible. Para un sistema de defensa que escanea buscando patrones de código sospechoso, en cambio, ese galimatías parece ruido inofensivo. Y así fue como, en las pruebas de Salt Labs, las barreras de seguridad del agente reconocieron la amenaza cuando la instrucción maliciosa venía "vestida" de manera reconocible, pero bajaron la guardia frente a la misma amenaza escrita en el alfabeto extraño de JSFuck. El agente procesó el contenido, ejecutó el código dentro de su propio entorno y, una vez que la acción ya había ocurrido, mostró una advertencia al usuario. Es decir: el aviso llegó tarde, cuando la cosa ya había pasado.

Salt Labs reportó el hallazgo a través del programa de recompensas por errores que depende de Meta, ya que Manus mantiene integraciones con varios servicios del ecosistema de la compañía de Menlo Park. Desde la empresa confirmaron que la vulnerabilidad fue corregida y que el procedimiento específico que explotaron los investigadores dejó de funcionar. La comunicación fue la esperada en este tipo de avisos: aviso responsable, parche, silencio sobre detalles internos. Pero el caso quedó documentado y publicado, y por eso sirve como una ventana para ver el problema más de cerca.

Lo que está en juego cuando se delegan tareas sobre el correo

Imaginen por un momento lo que podría hacer un atacante con un poco de ingenio y un asistente obediente. El propio informe de Salt Labs menciona el ejemplo, sin afirmar que haya ocurrido en esta prueba: una instrucción podría pedirle al agente que busque en la casilla todos los mensajes que contengan la palabra contraseña y los reenvíe a una dirección externa. La diferencia entre esa posibilidad y un correo concreto con trucos no es menor, pero el vector está abierto en cualquier sistema que no diferencie con claridad entre lo que el usuario le pide y lo que el contenido de un mensaje le pide al sistema. Esa es, me parece, la verdadera línea roja de esta historia.

Y acá conviene mirar un dato que pone las cosas en perspectiva. El informe "2026: The State of Consumer AI", publicado por Menlo Ventures, releva que el 36 por ciento de los consumidores ya le dio acceso a su correo electrónico a un asistente de inteligencia artificial. El 31 por ciento lo conectó con aplicaciones de mensajería, el 29 por ciento con almacenamiento en la nube y el 27 por ciento con el calendario. Son cuatro servicios que, juntos, pintan un retrato bastante completo de la vida digital de una persona: con quién se escribe, qué archivos guarda, qué tiene agendado, dónde se mueve. Cuando uno mira esos números y los cruza con lo que mostró Salt Labs, el escenario deja de ser teórico.

Qué mirar antes de cederle la llave al asistente

Entonces, ¿qué hacer con esto? No se trata de dejar de usar estas herramientas, que claramente llegaron para quedarse y pueden ahorrar mucho tiempo. Se trata, más bien, de entender hasta dónde uno está dispuesto a llegar con la delegación. Algunas ideas que me llevo después de leer el caso completo: las primeras son bastante obvias. Desactivar las integraciones que no se usan, revisar periódicamente qué permisos tiene cada agente, evitar que el asistente pueda ejecutar acciones de escritura o envío sin confirmación explícita, y tener presente que cualquier contenido proveniente de fuentes externas merece el mismo tratamiento que tendría un archivo adjunto de un remitente desconocido. La segunda parte es más filosófica, pero no por eso menos importante. Cuando le pedimos a un sistema que actúe por nosotros, también le estamos cediendo una parte del criterio sobre qué es seguro y qué no lo es. Y en materia de seguridad, el criterio humano sigue siendo, al menos por ahora, el más difícil de hackear.

La vulnerabilidad en Manus ya fue corregida y, como dijo Salt Labs, el procedimiento exacto que explotaron los investigadores dejó de funcionar. Pero el tipo de ataque que pusieron en evidencia no es exclusivo de Manus ni de Meta ni de Gmail. Es una propiedad emergente de cualquier sistema que procese instrucciones en lenguaje natural y, al mismo tiempo, ejecute acciones sobre servicios conectados. Mientras esa combinación exista, el riesgo va a estar latente en todos los asistentes que ofrezcan ese tipo de capacidades. La investigación de Salt Labs, en definitiva, no descubrió un bug aislado: descubrió una clase entera de problemas que la industria todavía está aprendiendo a nombrar y, sobre todo, a contener.

Dónde se puede leer el informe completo

La investigación completa de Salt Labs, con los detalles técnicos de la prueba, las capturas de pantalla de las conversaciones con Manus y la cronología del reporte a Meta, está disponible en el blog oficial de Authentik en autentik.security, bajo el título del hallazgo. Para quienes quieran profundizar en el fenómeno más general de las inyecciones de instrucciones en sistemas de inteligencia artificial, vale la pena seguir el trabajo del OWASP Gen AI Security Project, que mantiene un catálogo abierto de este tipo de vectores y publica recomendaciones actualizadas para desarrolladores y usuarios. En un tema que evoluciona semana a semana, esos recursos son, por ahora, la manera más concreta de no quedar corriendo detrás de cada nuevo titular.