La disputa sobre la privacidad de Meta Muse pone a prueba sus promesas de permisos
Meta refutó un informe según el cual Muse leyó Messages privados sin permiso, convirtiendo el debate sobre la privacidad de Meta Muse en una prueba de relatos técnicos contrapuestos.
El columnista de Inc., Jason Aten, afirma que Muse mostró detalles de conversaciones privadas después de que él rechazara dar al agente acceso a Messages. Meta sostiene que esa secuencia no puede producirse mediante la arquitectura del producto que desarrolló.
El desacuerdo es especialmente marcado. Aten afirma que Muse accedió a datos de mensajes mientras Full Disk Access parecía estar desactivado. Meta sostiene que tanto ese permiso de macOS como un conector independiente de Muse deben estar activados antes de que el agente pueda leer Messages.
Ninguna de las dos versiones se ha reproducido de forma independiente en una prueba controlada. Esto deja a los usuarios ante algo más que un informe rutinario de error de software. Deben decidir si un agente merece un acceso amplio mientras su desarrollador y un usuario discrepan sobre lo ocurrido.
La disputa también surgió poco después de que Meta presentara Muse como un agente personal diseñado para trabajar entre aplicaciones, archivos, comunicaciones y servicios web. Su utilidad depende de acceder a información que los chatbots convencionales no pueden ver.
Ese mismo acceso convierte los límites del consentimiento en un elemento central del producto. Un agente personal resulta más útil a medida que obtiene contexto, pero cada conector adicional amplía las consecuencias de un estado de permisos poco claro.
Las afirmaciones sobre la privacidad de Meta Muse se enfrentan a un relato contradictorio de un usuario
El hecho central no es que se haya demostrado un acceso no autorizado, sino que Meta y Aten describen estados de permisos incompatibles.
Según la disputa original, Aten advirtió que Muse hacía referencia a una conversación con el copresentador de su pódcast sobre nuevos iPhones. Según los informes, el agente también señaló un mensaje de su editor sobre la cercanía de la fecha límite de una columna.
Aten dijo que no había pedido a Muse que vigilara esas conversaciones. Más importante aún, recordó haber rechazado explícitamente el acceso a Messages, su calendario y otra información personal durante la configuración.
Al ser consultado, Muse supuestamente dijo que había recibido texto de banners de notificaciones entrantes, en lugar de leer el historial de mensajes subyacente. Aten rechazó posteriormente esa explicación tras examinar la configuración y el estado de sincronización del agente.
Informó haber descubierto que el conector de Messages se había sincronizado hasta la fila 187.462 de su base de datos local de Messages. Una fila de base de datos no equivale necesariamente a un mensaje completo, por lo que esa cifra no debería describirse como 187.462 mensajes.
La cifra sigue siendo relevante. Apunta a una sincronización de la base de datos, en lugar de la visibilidad limitada y transitoria que sugieren las vistas previas de notificaciones.
El ejecutivo de comunicaciones de Meta, Andy Stone, cuestionó esa versión. Dijo que la integración de Messages de Muse en Mac es totalmente opcional y exige que los usuarios activen dos controles independientes.
Uno es Full Disk Access, un permiso de macOS que permite al software autorizado acceder a información protegida perteneciente a otras aplicaciones. El segundo es el conector de Messages dentro de Muse.
David Singleton, ejecutivo de Meta Superintelligence Labs, ofreció una respuesta más técnica. Describió tres pasos de permisos independientes a nivel de aplicación y sistema operativo, incluida una confirmación manual dentro de Configuración del Sistema de macOS.
Meta afirma que los usuarios primero deben conceder Full Disk Access. Después pueden elegir un nivel de acceso a Messages dentro de Muse, y las opciones no disponibles permanecen desactivadas cuando el permiso del sistema está apagado.
Cambiar el control del sistema también reinicia la aplicación Muse, según Singleton. Meta sostiene que estos pasos hacen improbable una activación accidental e impiden que la aplicación eluda el límite impuesto por el sistema operativo.
Aten mantiene que Full Disk Access estaba desactivado cuando inspeccionó la configuración. Esto plantea la pregunta sin resolver en el centro de la disputa: ¿qué estado de permisos existía cuando comenzó la sincronización, no solo cuando se observó más tarde?
La evidencia pública actual no responde a esa pregunta. Las capturas de pantalla pueden documentar un estado posterior, mientras que los registros podrían establecer cuándo cambiaron los permisos, qué proceso accedió a la base de datos y qué datos salieron del dispositivo.
Meta también ha cuestionado la explicación de Muse sobre la sincronización de notificaciones. Singleton dijo que el agente se confundió y generó una versión incorrecta de su propio comportamiento.
Esa respuesta puede resolver una afirmación concreta, pero revela otra debilidad. Un agente que no puede explicar con precisión la fuente de sus datos ofrece a los usuarios evidencia deficiente para evaluar un comportamiento inesperado.
Por qué el acceso de Muse a Messages exige más que una captura de pantalla de la configuración
La disputa no puede resolverse tratando un único interruptor visible como un registro completo de accesos anteriores.
Apple describe Full Disk Access como un permiso que permite a una aplicación acceder a archivos en todo un Mac, incluidos datos de Mail, Messages, Safari y otras aplicaciones. Los usuarios lo gestionan mediante los controles de privacidad de Mac.
Esta protección del sistema respalda el argumento de Meta. Una aplicación convencional de Mac no debería poder leer la base de datos protegida de Messages simplemente porque solicite acceso.
Apple también señala que las aplicaciones que buscan acceso completo al almacenamiento deben añadirse explícitamente en Configuración del Sistema. Esa acción crea un límite del sistema operativo fuera de la propia interfaz de Muse.
Sin embargo, una pantalla de configuración actual no demuestra automáticamente todos los estados anteriores. El permiso podría haberse activado temporalmente, cambiado durante la configuración, eliminado después del acceso o asociado a otro proceso auxiliar.
Se trata de hipótesis, no de hallazgos sobre el dispositivo de Aten. Establecer cualquiera de ellas exigiría registros del sistema operativo con marcas de tiempo, registros de la aplicación, identificadores de procesos y registros de sincronización del lado del servidor.
La distinción entre autorización y activación también importa. Un usuario puede aprobar un permiso amplio del sistema mientras cree que una opción más limitada dentro de la aplicación restringe cómo lo utiliza el software.
A la inversa, una aplicación puede mostrar un conector como activado sin contar con el permiso del sistema necesario para recuperar sus datos de origen. La interfaz debería hacer visible esa discrepancia y explicar si los datos sincronizados previamente siguen disponibles.
La versión de Meta sugiere un consentimiento por capas. El usuario aprueba el acceso al sistema operativo, selecciona un conector, elige su nivel de acceso y reinicia la aplicación antes de que los datos puedan leerse.
La superposición de capas puede reducir el acceso accidental, pero solo cuando cada capa refleja el mismo estado efectivo. Si las etiquetas son ambiguas, están desactualizadas o se sincronizan mal, más controles pueden crear más incertidumbre en lugar de un consentimiento más sólido.
La posición de base de datos reportada plantea otra cuestión técnica. No está claro si ese valor representaba una carga completada, un cursor de sincronización local, un punto de control de indexación u otro marcador interno.
No debería especularse sobre esta distinción. Un índice local puede indicar procesamiento sin demostrar que cada registro mencionado llegó a un modelo remoto o a un servidor de Meta.
La página pública del producto Muse de Meta afirma que los usuarios controlan los permisos y aprueban determinadas acciones. También dice que Muse puede conectarse a aplicaciones, trabajar en segundo plano y continuar después de que el usuario cierre la aplicación.
Estas capacidades requieren registros duraderos de aquello a lo que el agente puede acceder y de lo que ya ha recopilado. Por ello, una auditoría de permisos debe abarcar tanto el acceso actual como las copias conservadas.
Revocar un conector debería responder varias preguntas con claridad. ¿Puede Muse seguir buscando contenido sincronizado previamente? ¿Se elimina el contenido almacenado en caché, se desvincula de tareas futuras o se conserva bajo otra política?
El desacuerdo público no ha resuelto esas cuestiones de retención. Sin embargo, son esenciales para comprender el significado práctico de desactivar un permiso.
Una investigación técnica útil reconstruiría la secuencia desde la instalación hasta la primera sugerencia inesperada. Identificaría cada solicitud de permiso, transición de estado, lectura de base de datos, transferencia de red y recuperación del agente.
Sin ese registro, Meta puede explicar cómo está diseñado el sistema, mientras que Aten puede documentar lo que experimentó. Ninguna de las dos formas de evidencia establece por sí sola y plenamente el mecanismo.
El conflicto real es entre el diseño de permisos y la experiencia del usuario
La arquitectura de Meta puede funcionar según lo diseñado y, aun así, la experiencia global de consentimiento puede fallarle a un usuario.
Esta es la tensión principal en la disputa sobre la privacidad de Meta Muse. Meta describe múltiples salvaguardas que deberían bloquear el acceso. Aten describe un resultado del producto que parecía vulnerar su decisión explícita.
Estas posiciones no equivalen a una prueba de conducta indebida ni a una prueba de error del usuario. Muestran que los sistemas de permisos necesitan un comportamiento observable, no solo controles internos.
En una aplicación normal, los usuarios suelen tolerar la incertidumbre sobre por qué apareció una sugerencia. Un agente modifica ese cálculo porque puede combinar información personal, iniciar tareas y seguir trabajando fuera de una conversación activa.
Muse está diseñado para ir más allá del modelo de solicitud y respuesta de un chatbot. Puede conectarse a servicios, supervisar objetivos en curso, navegar, preparar documentos y actuar a lo largo de varios pasos.
Eso significa que el producto debe distinguir entre al menos cuatro operaciones: ver datos, copiar datos, razonar sobre datos y actuar con datos. Una sola etiqueta de permiso puede no comunicar las cuatro.
"Leer" podría significar recuperar un único mensaje cuando se solicita. También podría significar indexar años de conversaciones para que el agente pueda hacer sugerencias no solicitadas más adelante.
Un usuario podría aceptar el primer comportamiento y rechazar el segundo. Si la interfaz no expresa la diferencia, un consentimiento técnicamente válido puede seguir sin reflejar la expectativa del usuario.
La explicación atribuida al agente empeora esta brecha. Aten afirma que Muse atribuyó su conocimiento a vistas previas de notificaciones, mientras que Meta dice que esa respuesta fue un error de IA.
Los grandes modelos de lenguaje generan texto probable en vez de consultar un registro interno garantizado de cada evento del sistema. A menos que el producto vincule las explicaciones con registros autorizados, los usuarios pueden recibir respuestas seguras pero inexactas sobre el acceso.
Esa limitación debería dar forma a la interfaz. Preguntas como "¿De dónde obtuviste esto?" deberían devolver un registro estructurado de procedencia en lugar de una reconstrucción conversacional.
Una respuesta útil identificaría el conector, el elemento de origen, la hora de recuperación, la concesión de permiso y la tarea que utilizó los datos. También debería mostrar si el contenido procedía de un dispositivo local o de una copia remota.
Aquí es donde los agentes de consumo difieren de las herramientas de conocimiento convencionales. En una base de conocimiento personal tradicional, los usuarios normalmente esperan que el material añadido deliberadamente pueda buscarse.
Un agente proactivo puede inferir cuándo cierta información podría ser útil y mostrarla sin una solicitud directa. Ese comportamiento plantea una cuestión de consentimiento más difícil: ¿el usuario autorizó el mero acceso o también la interpretación continua?
Meta comercializa Muse como un producto que comprende objetivos e impulsa el trabajo en segundo plano. Por tanto, la proactividad no es una función incidental. Forma parte de la propuesta de valor.
Sin embargo, una sugerencia proactiva basada en una conversación privada puede resultar intrusiva incluso cuando el acceso estaba técnicamente autorizado. El agente cruzó un límite contextual al llevar una comunicación a otro flujo de trabajo.
Por lo tanto, el desafío de los permisos es más amplio que determinar si un interruptor estaba activado. Meta debe demostrar que los usuarios pueden predecir qué hará el agente cuando se habilite un conector.
Si la investigación determina que Aten habilitó brevemente el acceso, Meta aún tendría que explicar por qué la interfaz y el historial de actividad no dejaron clara la sincronización resultante.
Si concluye que no existía el permiso requerido, el problema pasaría a ser un fallo directo de seguridad o implementación. La evidencia actual no justifica elegir entre esos resultados.
El historial de confianza de Meta eleva el costo de la ambigüedad
Un evento de acceso controvertido resulta más difícil de contener cuando el desarrollador ya arrastra un largo historial de polémicas sobre privacidad.
Meta entró en el mercado de los agentes con una desventaja de confianza. Los usuarios no evalúan Muse como un producto aislado de una startup sin historial corporativo.
La empresa ha afrontado años de escrutinio regulatorio, litigios y críticas sobre la forma en que Facebook y servicios relacionados manejaron la información personal. Ese historial no prueba la acusación de Aten.
Sí modifica la carga probatoria. Una negación categórica puede satisfacer a quienes se centran en la arquitectura de permisos documentada, mientras que otros exigirán registros de dispositivos y servidores.
Muse se lanzó en Estados Unidos el 8 de septiembre de 2026 como un agente personal para adultos. Meta hizo hincapié en la privacidad y la seguridad al describir una máquina virtual dedicada para el agente de cada usuario.
La cobertura del lanzamiento de la época señaló que Muse podía gestionar tareas que iban desde horarios y compras hasta correo electrónico y viajes. El alcance del producto convierte la confianza en un requisito para su adopción.
Meta también lanzó una aplicación para Mac que puede trabajar con archivos locales, Messages, Calendar y Notes cuando los usuarios conceden permiso. El acceso de escritorio proporciona a Muse un contexto que un asistente exclusivamente web no puede obtener.
Esa ventaja sitúa a Meta en competencia con otros creadores de agentes que persiguen el control del navegador, el uso del ordenador, el contexto local y la memoria persistente. El sector incluye productos de OpenAI, Anthropic, Google y desarrolladores de agentes más pequeños.
La comparación relevante no es qué empresa crea el chatbot más capaz. Es qué proveedor puede hacer que el acceso amplio sea comprensible, reversible y auditable.
Una preocupación de seguridad independiente surgió poco después del lanzamiento de Muse. El investigador de seguridad Patrick Wardle informó de una vulnerabilidad relacionada con material de autenticación en la aplicación para Mac, que Meta corrigió.
El zero-day reportado involucraba malware que ya se ejecutaba bajo la cuenta de un usuario, no el mismo mecanismo alegado por Aten. No debería presentarse como prueba de acceso no autorizado a Messages.
Sí refuerza la necesidad de visibilidad. Los equipos de seguridad y los usuarios necesitan saber a qué recursos puede acceder un agente, qué credenciales conserva y qué acciones tuvieron lugar.
Otro usuario, el YouTuber Matt Robb, alegó por separado que Muse gestionó incorrectamente una tarea de Facebook Marketplace y compartió su dirección con un comprador. Según se informó, Meta estaba examinando ese episodio.
De nuevo, esa afirmación se refiere a una acción saliente, no al acceso a los Messages de Aten. Combinar los acontecimientos en un patrón probado exageraría la evidencia.
En conjunto, ilustran dos caras del riesgo de los agentes. Un agente puede recuperar más información de la esperada o usar información autorizada en una acción inesperada.
Los permisos tradicionales se diseñaron en torno a aplicaciones que abren archivos o usan hardware. Los agentes añaden planificación, inferencia, memoria y ejecución entre servicios después de que se haya concedido el acceso.
Eso hace más difícil el diseño de mínimo privilegio. Un agente de calendario puede necesitar títulos de eventos, pero no archivos adjuntos. Un agente de compras puede necesitar una ciudad de entrega, pero no una dirección completa hasta el momento del pago.
Muse necesita controles que se correspondan con estas distinciones a nivel de tarea. Los conectores amplios son más fáciles de crear y explicar, pero trasladan más responsabilidad interpretativa a los usuarios.
La reputación de Meta implica que cada resultado sin explicación se interpretará a la luz de fallos pasados. La empresa solo puede reducir esa presión con evidencia que los usuarios y los investigadores independientes puedan examinar.
Lo que los permisos de Meta Muse deben demostrar
La respuesta más sólida sería un relato reproducible del incidente y un cambio de producto que facilite resolver disputas similares.
La explicación actual de Meta se centra en lo que se supone que debe requerir la aplicación para Mac. El siguiente paso es demostrar qué ocurrió en el dispositivo implicado.
Eso podría incluir una cronología revisada conjuntamente basada en registros de la aplicación, registros de permisos de macOS, historial de conectores y eventos de sincronización del lado del servidor. No sería necesario divulgar públicamente contenido sensible de los mensajes.
La revisión debería responder cuándo se concedió Full Disk Access, si es que se concedió, y qué ejecutable lo recibió. Debería identificar cuándo cambió de estado el conector de Messages y qué acción del usuario provocó el cambio.
También debería explicar la fila 187,462. Si ese número era un cursor local y no un registro de contenido cargado, Meta debería describir la diferencia en lenguaje claro.
Si los datos de mensajes llegaron a los sistemas de Meta, la empresa debería explicar su alcance, retención y estado de eliminación. Si nunca salieron del Mac, debería mostrar cómo Muse generó las sugerencias.
La empresa debería evitar apoyarse en la propia explicación del agente. Meta ya ha dicho que Muse se confundió al describir la sincronización de notificaciones, lo que convierte esa respuesta en evidencia poco fiable.
Un registro de actividad ofrecería una respuesta mejor. Cada sugerencia podría incluir un control de "¿Por qué estoy viendo esto?" conectado a registros inmutables del sistema.
El registro debería distinguir la recuperación de información de la acción. Leer un mensaje para responder a una solicitud directa es distinto de indexar continuamente conversaciones o enviar información a otro servicio.
Las pantallas de permisos también deberían mostrar las consecuencias antes de la activación. "Leer Messages" informa menos que "sincronizar el historial de mensajes y usarlo para sugerencias proactivas".
Los usuarios necesitan una elección separada para la sincronización histórica, la supervisión continua y la recuperación específica para tareas. Esos controles permitirían a alguien conceder acceso sin aceptar toda forma de proactividad.
La revocación necesita la misma claridad. Cuando un usuario desactiva el acceso, Muse debería indicar si eliminó los datos en caché, dejó de recopilar datos nuevos o simplemente desconectó la fuente activa.
Para los compradores empresariales, los administradores probablemente exigirán registros de auditoría exportables y políticas de conectores. Los usuarios consumidores merecen una versión legible de esa misma rendición de cuentas.
Una cuenta independiente resumió las posturas contrapuestas sin resolverlas. Aten afirma que la base de datos se sincronizó mientras el acceso estaba desactivado, mientras que Meta sostiene que las protecciones requeridas no pueden eludirse.
Esa brecha de verificación es la historia. Presentar cualquiera de las dos afirmaciones como una conclusión técnica establecida iría más allá de la evidencia disponible.
Meta podría reducir esa brecha publicando un análisis detallado posterior al incidente. El documento debería abordar el comportamiento observado, el método de investigación, los hallazgos, las limitaciones y cualquier acción correctiva.
Si la empresa concluye que las acciones del usuario habilitaron el conector, debería demostrar esas acciones con registros y no mediante insinuaciones. Los usuarios olvidan ajustes, pero el software debería conservar un rastro de auditoría.
Si detecta un problema de interfaz o gestión de estado, reconocerlo no validaría necesariamente todas las acusaciones. Demostraría que la empresa trata los informes de acceso inesperado como evidencia de ingeniería.
Un programa de recompensas por errores es útil para las vulnerabilidades, pero este incidente puede situarse entre la seguridad, el diseño de producto y el comportamiento del modelo. Ese límite exige una gestión de incidentes más amplia que la mera divulgación de exploits.
El estándar más amplio debería ser sencillo: los usuarios no deberían tener que confiar ni en la explicación de un agente ni en el diagrama de arquitectura de una empresa. Deberían poder inspeccionar lo que ocurrió.
Tres señales decidirán el debate sobre la privacidad de Meta Muse
La siguiente fase debería juzgarse por la evidencia técnica, el rediseño de permisos y los informes de otros usuarios, en ese orden.
La primera señal es una reconstrucción documentada del caso de Aten. Un relato creíble establecería la cronología de permisos, identificaría el proceso que accedió y aclararía si los datos llegaron a infraestructura remota.
Esa evidencia reforzaría la posición de Meta si mostrara una concesión explícita seguida de una sincronización esperada. Debilitaría la negación de la empresa si el acceso se produjo sin la aprobación requerida del sistema operativo.
También importaría una conclusión de que los registros son insuficientes. Un agente que maneja comunicaciones privadas debería conservar metadatos suficientes para investigar un evento de acceso controvertido sin exponer el contenido de los mensajes.
La segunda señal es un cambio en los controles de permisos y procedencia. Meta puede concluir que su arquitectura funcionó correctamente y aun así decidir que los usuarios necesitan opciones más claras.
Hay que observar controles separados que regulen importaciones históricas, supervisión en vivo, sugerencias proactivas, retención y acciones salientes. También hay que observar explicaciones a nivel de fuente vinculadas a registros de auditoría.
Dichos cambios indicarían que Meta reconoce la diferencia entre la autorización formal y las expectativas informadas. La ausencia de cambios dejaría la misma ambigüedad para futuras disputas.
La tercera señal es si usuarios o investigadores independientes reproducen el comportamiento. Un solo relato puede identificar un problema grave, pero resultados repetidos en condiciones documentadas establecerían un patrón técnico más sólido.
Los investigadores deberían registrar la versión de macOS, la versión de Muse, la ruta de instalación, los procesos auxiliares, el estado del conector y la secuencia exacta de elecciones de permisos. Sin esos detalles, informes aparentemente similares pueden implicar mecanismos distintos.
La ausencia de más informes no demostraría que Aten se equivocó. Reduciría la evidencia de un defecto generalizado, al tiempo que dejaría sin resolver su experiencia individual.
Meta también debería publicar notas de versión específicas para cualquier corrección relevante. Los cambios discretos dificultarían determinar si las pruebas posteriores evalúan el mismo software que utilizó Aten.
Para los usuarios que estén considerando Muse ahora, la respuesta práctica no es el pánico ni la confianza ciega. Revisen tanto Full Disk Access de macOS como cada conector dentro de Muse antes de añadir datos privados.
Usen un perfil o dispositivo de prueba separado al evaluar el comportamiento de un agente nuevo. Comiencen con fuentes limitadas, inspeccionen su actividad y amplíen el acceso solo después de que sus sugerencias coincidan con sus expectativas.
Para desarrolladores y compradores empresariales, la lección va más allá de Meta. Los permisos de los agentes deben ser observables en el momento del acceso y explicables posteriormente.
La disputa sobre la privacidad de Meta Muse sigue sin resolverse porque la evidencia pública documenta un conflicto, no un mecanismo verificado. Meta ha descrito salvaguardas y Aten ha descrito un resultado que esas salvaguardas deberían impedir.
¿Qué se ganaría su confianza: otra garantía categórica o un rastro de auditoría que muestre exactamente cuándo un agente accedió a sus datos, por qué lo hizo y qué ocurrió después?
