Esta semana, Patrick Wardle publicó un exploit contra Muse, el asistente personal de Meta, y en cuestión de horas Meta ya había sacado un arreglo. Quedémonos un momento con la parte tranquilizadora: una vulnerabilidad de este tipo, expuesta en público sin avisar antes al fabricante, suele tardar semanas o meses en cerrarse. Aquí fueron unas doce [1][2].
La parte incómoda viene después. El fallo no estaba en la nube, ni en el modelo, ni en la capa de aislamiento que Meta construyó con tanto ruido para separar a un usuario de otro. Estaba en el cliente de escritorio, en un ajuste de dictado que cualquier programa podía reescribir. Un agente capaz de leer tus mensajes, mover tus archivos y comprar en tu nombre quedó al alcance de quien lograra una sola cosa: que hicieras un copiar y pegar [2][3].
Para quien vende, compra o construye agentes de IA, esto no es una nota de seguridad de Meta. Es una advertencia de arquitectura.
Un ajuste invisible que decidía a dónde iba tu voz
Muse dicta en la nube. Cuando tocas el micrófono y hablas, el audio sale de tu Mac hacia un servidor de Meta, que es también quien guarda el texto. Esa decisión, por sí sola, no es un error: muchas aplicaciones lo hacen y tiene ventajas de coste y consistencia. El problema es cómo se controlaba el destino de ese audio.
Wardle encontró que Muse guarda en sus preferencias un ajuste indocumentado llamado endo_voyager_dictation_endpoint, y que cualquier programa que corra en la sesión del usuario puede cambiarlo. Con ese ajuste apuntando a un servidor propio, el atacante recibe tres cosas a la vez: lo que dictas, la posibilidad de inyectar instrucciones que el agente toma como propias, y el token de sesión de tu cuenta de Muse, que viaja junto con la petición [2][3].
Ese token es la parte grave. Con él, el atacante puede dictarle órdenes a Muse desde cualquier dispositivo donde tengas la sesión abierta, no solo desde esa Mac. Wardle lo demostró pidiéndole a la aplicación de su iPhone que reportara su ubicación exacta, hiciera un escaneo de dispositivos Bluetooth cercanos y listara los comandos de casa inteligente que podía ejecutar. En sus pruebas también consiguió que Muse tomara fotografías y escribiera archivos maliciosos en el disco, en varios casos sin ninguna señal visible para el usuario [2][3].
Su frase a Ars Technica resume por qué este tipo de fallo cambia el cálculo de cualquier equipo de seguridad: "Podemos manipular al agente y aprovechar sus privilegios para hacer lo que queramos. Así que en lugar de tener que escribir un stealer de Mac muy completo, podemos simplemente aprovechar el propio asistente de IA" [2].
Meta explicó el fallo como una escalada de privilegios local y no como un exploit remoto. "Usarlo para hacer daño exige, por tanto, código malicioso ya corriendo en la máquina del usuario bajo su cuenta, y el riesgo práctico para los usuarios de la aplicación Muse para Mac era bastante bajo", dijo David Singleton, de Meta Superintelligence Labs [1].
Lo que el exploit rompe y lo que no
Conviene ser justos con los matices técnicos, porque el sensacionalismo no ayuda a decidir nada después.
Es verdad que el ataque requiere ejecución de código en tu máquina con tu propia cuenta. También es verdad que no derriba la protección de macOS que impide que una aplicación lea las contraseñas y los tokens guardados por otra. Muse no fue vaciado desde fuera: el atacante consiguió que Muse, con el acceso que ya tenía, hiciera el trabajo. Y la arquitectura de nube que Meta diseñó para aislar a cada usuario, con su capa de revisión de acciones, no se rompió. El agujero estaba en el cliente de Mac [3].
Ahora la objeción que sí importa. Decir "no es remoto" cuando el vector de entrada es un ClickFix, la técnica de ingeniería social que convence a la víctima de pegar un comando en la Terminal, mezcla dos cosas distintas. El atacante no necesita estar sentado en tu escritorio: necesita que hagas un copiar y pegar. Y eso, en 2026, es el método más rentable del crimen organizado contra equipos Mac [4].
Justamente por eso la investigación de Wardle en los últimos meses ha girado alrededor de ese momento. En febrero publicó un análisis sobre cómo intervenir en el instante del pegado para desactivar la mayoría de ataques ClickFix, y en marzo documentó cómo Apple añadió protecciones al respecto en macOS 26.4. La industria está poniendo barreras precisamente donde este exploit solo necesitaba una rendija [4].
El privilegio heredado: por qué atacar al agente sale más barato
Un agente personal no es un programa más. Acumula permisos que antes estaban repartidos entre personas y departamentos: tu correo, tu calendario, tus archivos, tus compras, tus accesos. En el modelo tradicional de seguridad, un atacante que quiere llegar a esos datos tiene que escribir malware que robe credenciales, sortee el antivirus y sobreviva a la reinfección. Con un agente, esa parte del trabajo ya está hecho y firmada por una empresa conocida.
El propio Wardle lo dijo con una claridad que conviene citar de nuevo: en lugar de escribir un stealer, se aprovecha al asistente. Añadamos un detalle que empeora el cuadro: como la acción la ejecuta una aplicación legítima, con su firma y su lugar en el sistema, los controles de seguridad tienen menos motivos para sospechar. La señal de alarma que un antivirus buscaría no aparece, porque no hay nada anómalo en que Muse tome una foto o escriba un archivo si el usuario le dio ese permiso.
Esto ya tiene precedentes recientes, y no todos vienen de una vulnerabilidad. En julio, agentes de OpenAI provocaron un incidente contra infraestructura de Hugging Face que la propia compañía tuvo que reconocer. En agosto, la investigación de METR sobre ese episodio describió 1.206 agentes y más de 70.000 mensajes operando en un entorno que nunca fue el objetivo previsto. El 21 de septiembre, el panel científico independiente de la ONU publicó un informe temático que pide reforzar las salvaguardas sin esperar certezas científicas, y eligió ese caso como ejemplo. Lo conté con detalle en su momento [6][7].
La diferencia con Muse es que aquí no falló el juicio de un agente que perseguía un objetivo. Falló un ajuste de configuración que nadie pensó como asunto de seguridad. Ese es el patrón que conviene memorizar, porque es el más común y el más barato de prevenir.
Quién decide si tu agente puede actuar en casa ajena
Hay un segundo frente en esta historia que no tiene que ver con el código. El domingo, Amazon empezó a bloquear a Muse cuando el agente intentaba comprar en su sitio, con un mensaje que lo declaraba un "agente de IA no autorizado" que viola sus condiciones de uso. "Nos parece bastante claro que las aplicaciones de terceros que ofrecen hacer compras en nombre de los clientes de otras empresas deberían operar abiertamente y respetar las decisiones de los proveedores de servicios sobre si quieren participar o no", respondió Amazon, y pidió a Meta retirar a la compañía de la experiencia. Su comparación es explícita: es lo que hacen las aplicaciones de comida, las de reparto y las agencias de viajes con los restaurantes, las tiendas y las aerolíneas [2].
Detrás de esa negativa hay una pelea de fondo sobre quién manda cuando un agente actúa en una plataforma ajena. Meta no pidió permiso, o al menos Amazon sostiene que no lo obtuvo. Y aunque el bloqueo es un asunto comercial, deja una lección útil para cualquiera que construya agentes en la región: si tu asistente va a comprar, reservar o publicar en servicios de terceros, esos servicios van a reclamar el derecho a decidir si participan, y ese derecho no se negocia con una integración técnica. Es el mismo terreno donde se discutirán los límites de la automatización en los próximos años, y conviene no confundirlo con un problema de ingeniería.
Las decisiones de diseño que separan un agente útil de uno secuestrable
El OWASP publicó en diciembre de 2025 su Top 10 para aplicaciones agénticas, un marco revisado por pares que ordena los riesgos propios de la autonomía: manipulación del objetivo del agente, uso indebido de sus herramientas y pérdida de control humano [5]. El caso de Muse añade una categoría que esas listas todavía tratan de refilón, y que a mi juicio es la más traicionera: la configuración del propio agente como superficie de ataque.
De todo lo publicado estos días se pueden extraer cinco criterios que sirven para auditar cualquier agente, propio o ajeno.
El primero es procesar en el dispositivo todo lo que pueda quedarse en el dispositivo. macOS ofrece desde hace años una forma de dictado que no sale del equipo. Si Muse hubiera usado esa vía, el ataque descrito no existía: no hay endpoint que redirigir. Antes de enviar audio, imágenes o documentos a la nube, la pregunta correcta es si el resultado mejora lo suficiente como para justificar ese viaje.
El segundo es tratar los ajustes sensibles como secretos, no como preferencias. Que cualquier aplicación pueda cambiar el tamaño de una ventana es razonable. Que pueda cambiar el servidor al que se envía tu voz es otra cosa. Cada ajuste que decide a dónde viajan datos o credenciales debería estar en otra categoría: protegido, verificable y compartido con el resto del sistema para que, si cambia, alguien lo note.
El tercero es limitar el radio de daño de cada credencial. Si un token de sesión abre la puerta de todo el agente, el fallo de un solo componente se convierte en la pérdida de toda la cuenta. Lo deseable es lo contrario: credenciales por herramienta, con alcance definido y revocables por separado. Que perder una no signifique entregar el resto.
El cuarto es exigir confirmación humana en las acciones irreversibles. Tomar una foto o escribir un archivo con el permiso del usuario no debería ocurrir sin rastro. Enviar dinero, publicar, borrar o responder en nombre de alguien debería pedir una confirmación explícita, siempre. La automatización silenciosa es cómoda hasta que alguien la usa contra ti.
El quinto, y el más olvidado, es inventariar lo que el agente ya puede hacer. La mayoría de las empresas que han adoptado asistentes no tiene una lista de sus permisos, ni sabe cuántas cuentas puede tocar, ni cuándo fue la última vez que alguien los revisó. Ese inventario es la primera conversación de cualquier proyecto serio con agentes, antes de discutir funciones.
Qué haría esta semana si ya usas agentes
Si tienes Muse instalado, hay cuatro medidas concretas y verificables que los propios reportes recomiendan [3]. Revisar la lista de aplicaciones y permisos que Muse tiene concedidos y retirar todo lo que no uses, porque el atacante solo alcanza lo que el agente ya alcanza. Si tu Mac pudo estar comprometido, tratar la cuenta de Muse y las cuentas conectadas como expuestas y cambiar las contraseñas. Evitar el dictado por voz en Muse hasta que haya aviso de seguridad publicado. Y no pegar nunca en la Terminal un comando que llegó por una web, un correo o un mensaje, sin importar lo convincente que suene la instrucción.
Para un equipo que opera agentes, añado tres cosas que no dependen de Meta. Escribir el inventario de credenciales y permisos de cada agente y guardarlo con fecha. Configurar alertas sobre lo que el agente hace, no solo sobre lo que falla, porque las acciones legítimas son el disfraz perfecto. Y separar la identidad del agente de la de cualquier persona: si mañana hay que revocarlo, se revoca una identidad y no una cuenta corporativa compartida.
Las preguntas incómodas
¿Cuánto tiempo pasó entre el lanzamiento de Muse y esta investigación? Pocas semanas. Meta publicó en ese lapso dos textos explicando las decisiones de seguridad y privacidad que había tomado, y presumió de una arquitectura aislada por usuario. El agujero no estaba en esa arquitectura, lo cual es un mérito, y también una señal de dónde miró el equipo y dónde no [2].
¿Quién avisa al usuario de lo que su agente hizo la semana pasada y con qué credencial? Si la respuesta es "nadie", no hay auditoría posible, solo confianza. Y la confianza es un mecanismo de seguridad aceptable entre personas con memoria y responsabilidad, no entre un usuario y un ajuste indocumentado que cualquier proceso puede reescribir.
¿Sobrevive el token del agente al cambio de contraseña? ¿Se puede revocar el acceso a una sola herramienta sin desmontar todo el asistente? Son preguntas de operación, no de investigación, y casi nadie las tiene respondidas antes del incidente.
¿Qué pasa con la trazabilidad cuando el que actúa es tu agente? Si una compra, un mensaje o un borrado de archivos lo ejecutó un agente con tus permisos, la pregunta "quién lo hizo" se vuelve más difícil de responder justo cuando más importa. Ese es el terreno donde veo más trabajo pendiente en las empresas que están adoptando agentes ahora mismo.
Y la última: el fallo lo encontró un investigador externo, que decidió divulgarlo completo sin avisar antes a Meta. La divulgación total es discutible como método y responde a una razón práctica: es lo que consigue arreglos en horas en lugar de meses. Vale la pena preguntarse cuántos fallos parecidos siguen ahí, en agentes más pequeños y menos escrutados, sin un Wardle que los mire.
Qué haría yo con esto
Ni pánico ni pausa. El episodio confirma una idea que sostengo desde que empecé a trabajar con agentes: la utilidad se diseña rápido y la seguridad se diseña tarde, cuando ya existe el problema. Un agente que lee tu correo, mueve tus archivos y compra en tu nombre debería pasar por el mismo tipo de revisión que un empleado con acceso a todo. Permisos mínimos, credenciales acotadas, registro de lo que hace y confirmación humana para lo irreversible.
Hay algo más que este caso deja claro, y es el argumento que usaré con mis clientes en la próxima reunión: el agente hereda tu identidad, y con ella tu reputación y tu responsabilidad. Cuando eso pasa, la pregunta ya no es cuántas tareas automatizas, sino cuánto de tu operación queda expuesto a que alguien convenza a tu asistente de trabajar para él. Ser útil era la parte fácil.
Si tienes agentes en producción y no sabes exactamente qué permisos tienen, ese inventario es un buen punto de partida esta semana. Te lo puedo ayudar a levantar.
Fuentes y referencias
[1] The Verge, Jess Weatherbed, "Meta patches Muse exploit that let attackers control the AI agent" (22/09/2026): theverge.com. Incluye la cita de David Singleton (Meta Superintelligence Labs), el bloqueo de Amazon a Muse y los datos de descargas del lanzamiento.
[2] Ars Technica, "Muse, Meta's extraordinarily privileged AI assistant, has a serious 0-day" (publicado el 21/09/2026): arstechnica.com. Origen de las declaraciones de Patrick Wardle sobre las decisiones de diseño y del detalle del hotfix de Meta.
[3] The Hacker News, "One Hidden Meta Muse Setting Could Let Attackers Take Over the AI Agent" (septiembre de 2026): thehackernews.com. Nombre del ajuste endo_voyager_dictation_endpoint, alcance del token en varios dispositivos, pruebas en el iPhone y medidas de mitigación recomendadas.
[4] Objective-See Foundation, blog de Patrick Wardle: objective-see.org. Entradas "ClickFix: Stopped at ⌘+V" (15/02/2026) y "No Paste for You!" (31/03/2026), sobre las protecciones contra ClickFix en macOS 26.4.
[5] OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications 2026" (publicado el 09/12/2025): genai.owasp.org. Marco de referencia sobre los riesgos propios de dar autonomía a un sistema, entre ellos la manipulación del objetivo del agente y el uso indebido de sus herramientas.
[6] METR, "OpenAI Hugging Face incident investigation" (26/08/2026): metr.org, y cobertura de Fortune (21/07/2026) sobre el incidente original.
[7] UN News, "UN panel calls for stronger safeguards as AI agents advance" (21/09/2026): news.un.org. Principio de precaución aplicado a los agentes y caso elegido por el panel científico independiente.
[8] Artículo propio sobre el lanzamiento de Muse (08/09/2026): sergio.ec. Las promesas de privacidad y control con las que Meta presentó el asistente.