El problema expone una de las paradojas centrales de los asistentes autónomos: cuanto más útiles se vuelven, más valioso resulta comprometerlos.
Meta lanzó Muse con una promesa ambiciosa: un agente de inteligencia artificial capaz de operar sobre buena parte de la vida digital del usuario. Puede trabajar con correo, calendario, archivos, mensajería y servicios web, ejecutar tareas complejas e interactuar con otras aplicaciones.
El problema es que esa capacidad depende necesariamente de una enorme cantidad de confianza.
Y ahora un investigador de seguridad demostró que un proceso local sin privilegios especiales puede aprovechar precisamente esa confianza.
Patrick Wardle, especialista en seguridad de macOS y fundador de Objective-See, publicó este 21 de septiembre una prueba de concepto denominada “not-a-mused” que explota una configuración interna no documentada de Muse.
Según la investigación, la aplicación expone una preferencia llamada endo_voyager_dictation_endpoint, que determina hacia dónde se envía el tráfico asociado al dictado de voz.
El problema: un proceso ejecutándose como el usuario puede modificarla sin necesitar privilegios elevados.
Eso permite redirigir las comunicaciones hacia infraestructura controlada por un atacante.
Y ahí comienza el verdadero problema.
De interceptar un prompt a controlar el agente
En condiciones normales, cuando un usuario dicta una instrucción, Muse envía esa información hacia infraestructura de Meta para procesarla.
Wardle descubrió que es posible modificar el destino de ese tráfico.
De esta forma, malware ejecutándose localmente podría colocar un servidor controlado por el atacante entre el usuario y Muse.
La prueba de concepto muestra que esto podría permitir capturar los prompts dictados por el usuario, modificar instrucciones mediante prompt injection y obtener material de autenticación utilizado por el propio agente.
Pero el impacto no termina ahí.
La documentación del PoC resume el riesgo de una forma particularmente clara:
“Muse’s access can potentially become the attacker’s access.”
Es decir: el acceso concedido a Muse puede terminar convertido en acceso para el atacante.
Y esto cambia significativamente el modelo de amenaza.
El agente como amplificador de privilegios
Existe un argumento habitual cuando se analiza una vulnerabilidad que requiere ejecución local: si un atacante ya puede ejecutar malware en una computadora, entonces el sistema ya está comprometido.
En muchos escenarios, ese razonamiento tiene sentido.
En este caso, no necesariamente.
Muse puede disponer de permisos y autenticaciones que un proceso local común no posee.
Dependiendo de lo que haya autorizado el usuario, el agente podría tener acceso a archivos, Mail, Messages, Calendar, Notes, micrófono, cámara u otros servicios conectados.
El propio Wardle explica que esto convierte a Muse en una especie de amplificador de privilegios: en lugar de desarrollar malware especializado capaz de robar información de múltiples aplicaciones, un atacante podría intentar secuestrar al agente que ya posee esas capacidades.
Según Ars Technica, Wardle desarrolló pruebas que permiten utilizar Muse para realizar acciones como escribir archivos o tomar fotografías aprovechando los permisos previamente concedidos al asistente.
El problema, por lo tanto, no es solamente que malware pueda comprometer Muse.
El problema es que Muse puede tener más privilegios que el propio malware.
La arquitectura de los agentes cambia el modelo de seguridad
Los asistentes tradicionales respondían preguntas.
Los agentes modernos ejecutan acciones.
Esa diferencia aparentemente simple tiene consecuencias importantes.
Para ser útil, un agente necesita acumular acceso: debe leer correos, revisar calendarios, consultar documentos, acceder a servicios web y, eventualmente, realizar acciones en nombre del usuario.
Muse representa precisamente esa evolución.
Meta lo describe como un agente capaz de trabajar en segundo plano, lanzar subagentes, construir herramientas e incluso interactuar con un shell. En su propia explicación sobre la arquitectura de seguridad del producto, la compañía reconoce que el desarrollo implicó entregar inboxes, calendarios y acceso a comandos a software que podía funcionar de forma autónoma.
Ese modelo crea una nueva concentración de privilegios.
Antes, un atacante podía necesitar vulnerar varias aplicaciones para obtener determinada información.
Ahora puede existir un único componente que ya tenga acceso a todas ellas.
El agente.
Una configuración interna con consecuencias externas
Uno de los aspectos más llamativos del descubrimiento es la aparente simplicidad del vector.
El problema no requiere explotar corrupción de memoria, romper el aislamiento del sistema operativo ni utilizar una vulnerabilidad sofisticada del kernel.
La prueba de concepto aprovecha una configuración de la propia aplicación.
El parámetro que controla el endpoint de dictado puede ser modificado por un proceso local ejecutándose con permisos normales del usuario.
Wardle señala que, desde el punto de vista de diseño, Meta podría haber reducido el riesgo manteniendo el procesamiento del dictado dentro del propio dispositivo, utilizando mecanismos disponibles en macOS.
En cambio, el sistema envía esa información hacia infraestructura remota.
Una combinación de decisiones arquitectónicas termina creando una superficie de ataque difícil de ignorar.
No es un ataque remoto
También es importante colocar el descubrimiento en contexto.
La vulnerabilidad no permite comprometer remotamente una Mac desde Internet por sí sola.
El atacante necesita primero conseguir ejecución de código bajo la cuenta del usuario.
Eso puede ocurrir mediante malware, ingeniería social u otros mecanismos.
Wardle menciona específicamente la posibilidad de combinar el problema con técnicas similares a ClickFix, donde se convence al usuario de copiar y ejecutar comandos aparentemente legítimos.
Una vez obtenida esa ejecución inicial, el atacante podría utilizar Muse como plataforma para expandir el alcance del compromiso.
Por eso hablar simplemente de “malware local” puede minimizar el impacto.
La vulnerabilidad funciona como una vía de amplificación de capacidades.
Las dudas sobre privacidad ya habían comenzado
El descubrimiento aparece además en un momento complicado para Muse.
En los días posteriores al lanzamiento surgieron cuestionamientos sobre la forma en que el agente accede a información del sistema.
Un usuario relató que Muse parecía conocer información proveniente de Messages pese a que, según él, no había concedido explícitamente ese acceso. Meta indicó posteriormente que el agente había interpretado incorrectamente la procedencia de la información y que el acceso dependía de los permisos otorgados por el usuario.
Amazon también comenzó a bloquear el acceso de Muse a su plataforma, argumentando que los agentes externos deben identificarse correctamente y respetar las decisiones de los servicios con los que interactúan.
Son problemas diferentes, pero convergen en una misma cuestión:
¿qué nivel de confianza estamos dispuestos a entregar a software autónomo que puede actuar en nuestro nombre?
Un exresponsable de seguridad de Meta también expresó preocupación
La publicación de la vulnerabilidad recibió además una reacción particularmente incómoda para la compañía.
Un gerente de ingeniería de seguridad de Meta que dejó la empresa este mismo mes afirmó públicamente que no utilizaría Muse, citando preocupaciones vinculadas a seguridad y privacidad.
La declaración no demuestra por sí misma que el producto sea inseguro, pero adquiere relevancia porque proviene de alguien que ocupó una posición directamente relacionada con seguridad dentro de la compañía.
Meta, al mismo tiempo, ha presentado Muse como un producto diseñado desde el principio alrededor de la seguridad y la privacidad.
La compañía publicó recientemente una extensa explicación técnica detallando las medidas utilizadas para reducir riesgos en agentes autónomos.
El descubrimiento de Wardle demuestra lo difícil que resulta cumplir esa promesa cuando el producto necesita concentrar tantos permisos.
El problema no es solamente Muse
Sería sencillo interpretar el episodio como una falla puntual de Meta.
Pero el problema es más amplio.
Todo el ecosistema tecnológico está avanzando hacia agentes que necesitan permisos cada vez mayores para funcionar.
Leer correos.
Enviar mensajes.
Modificar archivos.
Operar navegadores.
Realizar compras.
Ejecutar comandos.
Interactuar con sistemas corporativos.
Cada nueva integración aumenta la utilidad del agente, pero también incrementa el impacto potencial de comprometerlo.
En términos de seguridad, estos sistemas pueden convertirse en puntos de concentración de confianza.
Algo similar ocurrió históricamente con los gestores de contraseñas, navegadores o herramientas de administración remota: cuanto más acceso concentra una aplicación, más atractiva se vuelve para un atacante.
Los agentes de IA llevan esa lógica todavía más lejos.
No solamente almacenan credenciales.
También pueden tomar decisiones y ejecutar acciones.
Una nueva frontera para la seguridad de endpoints
La prueba de concepto de Wardle deja una conclusión que probablemente se repetirá en los próximos años.
La seguridad de los agentes no puede evaluarse únicamente observando el modelo de inteligencia artificial.
También hay que analizar la aplicación que lo rodea, sus configuraciones, los permisos del sistema operativo, las credenciales que almacena, las integraciones que utiliza y los canales por los que recibe instrucciones.
Muse puede tener sofisticados mecanismos para detectar prompt injection o limitar acciones peligrosas.
Pero si un proceso local puede modificar el lugar donde recibe sus instrucciones o interceptar sus credenciales, esas defensas pueden quedar relegadas a un segundo plano.
Los agentes prometen convertirse en una nueva capa entre el usuario y el sistema operativo.
Eso los convierte también en una nueva capa que los atacantes intentarán controlar.
Y probablemente este sea apenas uno de los primeros ejemplos.