Parcheado el zero-day de Meta Muse, pero la promesa de seguridad del agente se enfrenta a una dura prueba
Meta corrigió el zero-day de Meta Muse en aproximadamente un día, pero el incidente expuso un conflicto en el centro de los agentes personales de IA. Muse necesita un acceso amplio para ser útil, pero una configuración débil de Mac permitió que código local volviera ese acceso contra su propietario.
El investigador de seguridad Patrick Wardle reveló la vulnerabilidad el 21 de septiembre de 2026. Su prueba de concepto redirigía el tráfico de transcripción de voz de Muse, capturaba material de autenticación y utilizaba el agente a través de la cuenta de la víctima.
El ataque no comprometía de forma remota un Mac limpio. Primero, un atacante necesitaba ejecutar código como el usuario que había iniciado sesión, quizá mediante malware o una técnica de ingeniería social como ClickFix.
Esa limitación es importante, pero no resuelve la cuestión de seguridad. El malware local convencional debe encontrar y comprometer cada recurso protegido por separado. Secuestrar Muse ofrecía una vía hacia un agente ya conectado a archivos, servicios, cuentas y permisos del dispositivo.
La rápida respuesta de Meta cerró la vía documentada. No eliminó la preocupación más amplia planteada por el exploit de Meta Muse: los controles de seguridad alrededor de un agente deben proteger toda la ruta, desde su cliente local hasta su infraestructura en la nube.
El incidente llegó menos de dos semanas después del lanzamiento de Muse en Estados Unidos. Meta había presentado el producto como un agente personal basado en la privacidad, el aislamiento, la supervisión y el control del usuario.
Ese momento convirtió un error de implementación limitado en una prueba directa de la promesa de seguridad más amplia de Meta.
Qué cambió realmente el zero-day de Meta Muse
La vulnerabilidad permitía que un proceso local sin privilegios redirigiera un flujo de trabajo confiable de Muse y capturara las credenciales detrás del agente.
Muse normalmente envía las indicaciones dictadas desde su aplicación para Mac al servicio de transcripción de Meta. Wardle encontró una configuración no documentada llamada endo_voyager_dictation_endpoint, que controlaba el destino de ese tráfico.
Según los informes, cualquier aplicación o comando ejecutado bajo la cuenta del usuario podía modificar la configuración sin recibir permisos especiales de macOS. Por tanto, un atacante podía sustituir el endpoint de Meta por un servidor bajo su control.
La redirección se activaba cuando el usuario pulsaba el botón del micrófono de Muse y dictaba una indicación. El endpoint malicioso podía interceptar el intercambio y obtener el token utilizado para autenticar la cuenta de Muse.
Wardle documentó la técnica en una prueba de concepto pública. El repositorio describe varios posibles resultados, entre ellos indicaciones capturadas, instrucciones inyectadas, material de autenticación robado y abuso del acceso concedido a Muse.
Su código también ilustra por qué el fallo iba más allá de una filtración convencional de transcripción de voz. Una vez capturado el token, la prueba de concepto podía comunicarse con la infraestructura de cuentas y agentes más allá de la solicitud inicial de dictado.
Wardle afirmó que el agente podía entonces manipularse a través de la sesión de confianza del usuario. Las demostraciones incluían escribir archivos, usar una cámara autorizada, localizar un iPhone vinculado y buscar dispositivos Bluetooth Low Energy cercanos.
Esos ejemplos dependían de los permisos y conexiones disponibles para la cuenta de Muse afectada. El fallo no otorgaba automáticamente las mismas capacidades a todas las víctimas.
Sin embargo, esa dependencia también era el origen del riesgo. Un atacante podía heredar la colección particular de accesos que cada usuario ya había aprobado.
El fallo de seguridad de Muse no era un error de ejecución remota de código. No permitía que cualquiera en internet comprometiera todos los Mac con Muse instalado.
El atacante necesitaba primero ejecución local. Ese punto de apoyo podía proceder de malware existente, una aplicación maliciosa o un comando que engañara a la víctima para ejecutarlo.
Esta distinción evita una interpretación exagerada del incidente. No hace que el fallo sea inocuo, porque la configuración vulnerable ofrecía amplificación de acceso después de ese punto de apoyo inicial.
El repositorio de Wardle describe que Muse expone más de 50 comandos. El agente podía convertirse en una interfaz común para recursos que el malware tendría que identificar, acceder y controlar por separado.
Meta eliminó la configuración vulnerable de las versiones de producción mediante una corrección urgente. Wardle reconoció posteriormente la solución, indicando que la ruta específica del exploit ya no funcionaba como se demostró originalmente.
La respuesta de la empresa redujo la exposición inmediata. Los usuarios deben seguir manteniendo actualizada la aplicación para Mac, revisar los servicios conectados y eliminar los permisos que Muse no necesite.
Lo más importante es que el parche cambió el producto sin cambiar la lección de seguridad. Un control que parecía una opción de configuración interna había funcionado como un límite alrededor de la autenticación y la autoridad del agente.
Un fallo local llegó mucho más allá de la aplicación local
Calificar el error como local describe su requisito de entrada, no el alcance completo disponible tras un secuestro exitoso.
La seguridad tradicional de escritorio separa las capacidades sensibles mediante permisos. En macOS, las aplicaciones suelen solicitar aprobación explícita antes de utilizar recursos protegidos, como el micrófono, la cámara, la ubicación, los calendarios o archivos seleccionados.
Muse complica ese modelo. El agente puede recibir permisos locales mientras también se conecta a servicios en la nube y opera un entorno dedicado en la infraestructura de Meta.
Meta afirma que Muse puede enviar mensajes, trabajar con calendarios, navegar por sitios web, rellenar formularios, crear documentos, realizar compras y crear conectores. Los usuarios eligen qué cuentas y recursos conectar.
Este diseño concentra capacidades útiles en torno a una interfaz conversacional. También crea un valioso punto de control para un atacante.
El malware local sin permiso de cámara no puede normalmente tomar una foto simplemente porque otra aplicación recibió ese permiso. Debe eludir las protecciones de macOS o comprometer la aplicación autorizada.
El exploit de Meta Muse proporcionaba la segunda vía. En lugar de derrotar cada límite del sistema operativo de forma independiente, un atacante podía emitir instrucciones a través de una sesión de agente ya confiable.
Wardle resumió la distinción en un informe técnico inicial: el atacante podía aprovechar el asistente en lugar de crear un ladrón integral de información para Mac.
Por tanto, la expresión “ataque local” puede generar una falsa sensación de seguridad. Responde dónde comienza el código malicioso, pero no dónde termina la autoridad resultante.
Meta caracterizó el problema como uno que requería un dispositivo previamente comprometido. Es una precisión importante porque un atacante no podía activar el flujo de trabajo vulnerable únicamente desde un sistema remoto arbitrario.
Aun así, la ejecución local suele representar el comienzo de una intrusión, no su objetivo final. Los atacantes utilizan con frecuencia el acceso inicial para robar credenciales, ampliar permisos o llegar a servicios conectados.
ClickFix ilustra el problema. Este método de ingeniería social presenta pasos falsos de solución de problemas o verificación que indican a una víctima que pegue un comando en Terminal.
La víctima proporciona ejecución local sin reconocerla como instalación de malware. Wardle sostuvo que esta técnica podía convertir el fallo nominalmente local en una cadena de ataque iniciada de forma remota.
La distinción es sutil pero esencial. La vulnerabilidad no era ejecución remota de código, mientras que la campaña completa podía comenzar con un señuelo remoto.
Una vez que el comando cambiaba el endpoint de Muse, la interacción normal del usuario podía activar la captura de credenciales. La víctima podría no ver ninguna solicitud de un nuevo permiso para cámara, calendario o ubicación porque Muse ya contaba con la autorización pertinente.
La cuenta especializada en seguridad para Mac informó que las demostraciones de Wardle incluían creación de archivos, uso de la cámara y acceso a la ubicación. Estas acciones mostraron cómo un agente puede multiplicar un punto de apoyo modesto.
Esta amplificación es lo que debería preocupar a desarrolladores y equipos de seguridad empresarial. Un asistente comprometido puede ofrecer un inventario estructurado de capacidades conectadas, en lugar de obligar al malware a explorar el dispositivo a ciegas.
La vulnerabilidad también cruzaba capas arquitectónicas. El entorno en la nube de Meta podía mantenerse aislado según lo previsto mientras un cliente comprometido presentaba material de autenticación válido en su límite.
Desde la perspectiva del servicio en la nube, las solicitudes parecían llegar a través de una cuenta autorizada. El control que falló se encontraba antes en la cadena, donde el cliente de Mac reunía y transmitía datos confiables.
Eso significa que el aislamiento del lado del servidor por sí solo no puede proteger un agente. La autenticación, el almacenamiento local, los enlaces profundos, los canales de actualización, los procesos auxiliares, la entrada de voz y los ajustes de configuración forman parte del mismo perímetro de seguridad.
La arquitectura de seguridad de Meta se encontró con un error común del lado del cliente
La paradoja más marcada es que las avanzadas defensas en la nube de Muse quedaron socavadas por una configuración común y modificable en el cliente.
Meta publicó una explicación detallada de las protecciones de Muse el 8 de septiembre. La empresa describió máquinas virtuales dedicadas, almacenamiento de credenciales separado, controles de red, clasificadores, aprobaciones humanas y supervisión continua.
Cada usuario recibe un ordenador en la nube dedicado donde opera el agente. Meta separa el entorno principal de ejecución del agente de los componentes más sensibles de gestión de datos y credenciales.
Un sistema llamado Sentinel evalúa las acciones del agente y el acceso a la red. Según Meta, las credenciales de los servicios conectados permanecen fuera del entorno principal de ejecución del agente.
La empresa también aplica clasificadores destinados a detectar la inyección de indicaciones, que ocurre cuando contenido hostil intenta manipular las instrucciones de un sistema de IA. Otros controles requieren aprobación humana para determinadas acciones sensibles.
La arquitectura de seguridad de Meta refleja un trabajo serio sobre riesgos propios del software autónomo. También reconoce abiertamente que Muse cometerá errores y se enfrentará a contenido adversarial.
Ninguno de esos controles abordaba directamente la configuración que Wardle encontró en el cliente de Mac. El exploit no necesitaba escapar del contenedor en la nube ni derrotar el diseño interno de Sentinel.
En cambio, capturaba material de autenticación antes de utilizar las mismas vías de confianza disponibles para la aplicación legítima. Se trataba de un fallo de límites alrededor del sistema, no necesariamente dentro de sus defensas más sofisticadas.
Esa diferencia hace que el fallo de seguridad de Muse sea instructivo. Los equipos de seguridad a menudo dedican sus revisiones más exhaustivas a componentes novedosos como los modelos, los bucles de agentes y los filtros de inyección de indicaciones.
Los atacantes pueden elegir algo más sencillo. El almacenamiento de configuración, los registros, los esquemas de URL personalizados, los sockets locales, la gestión del portapapeles, los endpoints de transcripción y los asistentes de actualización pueden convertirse en vías hacia el agente.
La función de voz de Muse creó una de esas vías. Meta eligió la transcripción basada en la nube, lo que exigía que el cliente de Mac enviara datos a un endpoint remoto.
Apple ofrece a los desarrolladores opciones de procesamiento de voz en el dispositivo. Wardle sostuvo que la transcripción local habría eliminado esta oportunidad específica de interceptación de red.
Eso no demuestra que todos los agentes deban procesar siempre la voz de forma local. La transcripción en la nube puede admitir modelos diferentes, un comportamiento coherente y funciones no disponibles a través de un servicio de plataforma.
Sin embargo, enviar información sensible a la nube eleva las exigencias de validación en el endpoint. Los usuarios deben confiar en que la aplicación seleccione el destino correcto y proteja cada credencial asociada al intercambio.
El carácter no documentado de la configuración no ofrecía una protección significativa. Un investigador o atacante puede inspeccionar el comportamiento de la aplicación, las preferencias, el tráfico de red y las cadenas del ejecutable.
Por tanto, los controles no documentados deberían recibir el mismo modelado de amenazas que las configuraciones visibles. La oscuridad puede retrasar el descubrimiento, pero no puede sustituir las restricciones de acceso ni la validación criptográfica.
Según se informa, el parche eliminó el endpoint de producción configurable. Es una solución inmediata sensata, ya que los procesos locales ordinarios ya no necesitan una forma de redirigir el tráfico de dictado en vivo.
Una revisión más sólida también debería preguntar por qué el token de autenticación llegó a ese flujo de trabajo, si puede limitarse estrictamente y con qué rapidez caduca. Los informes públicos no han respondido por completo a esas preguntas.
El alcance del token importa porque las credenciales deberían proporcionar únicamente el acceso necesario para una operación específica. Un intercambio de transcripción no debería exponer autoridad reutilizable sobre funciones no relacionadas del agente.
Las credenciales de corta duración y restringidas por audiencia pueden reducir el daño tras una interceptación. El almacenamiento respaldado por hardware y límites estrictos entre procesos pueden dificultar el robo.
La evidencia pública no establece qué cambios adicionales realizó Meta más allá de eliminar la configuración. El hotfix no debería considerarse prueba de que todas las rutas de credenciales relacionadas recibieron un rediseño completo.
Los agentes de IA convierten el diseño de permisos en un multiplicador de seguridad
El valor de un agente de IA surge de combinar acceso, contexto y acción, lo que hace que cada error de autorización tenga consecuencias mayores.
Un chatbot puede exponer el historial de conversaciones privadas si se ve comprometido. Un agente puede exponer ese historial y, además, usar herramientas, abrir cuentas, contactar servicios y realizar acciones bajo la identidad del usuario.
Esa diferencia cambia la forma en que los desarrolladores deberían medir la gravedad. El código vulnerable puede parecer pequeño, pero su alcance posterior depende de la autoridad acumulada detrás del agente.
Meta afirma que Muse puede trabajar con correo electrónico, calendarios, plataformas sociales, sitios web, flujos de pago, archivos locales y conectores personalizados. No todos los usuarios habilitan todas las capacidades.
Incluso una configuración limitada puede atravesar varios dominios de confianza. Un usuario podría conceder acceso al calendario, conectar el correo electrónico, permitir la creación de archivos y autorizar una sesión de navegador para hacer compras.
Cada permiso puede parecer razonable al evaluarse frente a una función independiente. Juntos, crean una identidad de alto valor capaz de coordinarse entre servicios.
Los profesionales de la seguridad denominan radio de impacto a esta autoridad acumulada: el daño total posible tras el fallo de un componente. En el caso de los agentes, ese radio puede cambiar cada vez que un usuario añade un conector.
El zero-day de Meta Muse demuestra por qué el principio de mínimo privilegio debe ser dinámico. El sistema no debería limitarse a preguntar si un usuario aprobó el acceso en algún momento anterior.
Debería preguntar si una acción concreta necesita ese acceso ahora. También debería determinar si la solicitud actual llegó por un canal esperado y refleja una intención clara del usuario.
La arquitectura de Meta incluye aprobaciones para determinadas acciones externas. Esos puntos de control pueden limitar el daño cuando se aplican de forma coherente y resultan difíciles de imitar para una sesión comprometida.
Sin embargo, las aprobaciones también pueden perder valor por fatiga. Los usuarios pueden confirmar avisos frecuentes automáticamente, especialmente cuando el agente realiza tareas rutinarias en segundo plano.
Un diseño más seguro necesita más que diálogos adicionales. Requiere tokens de alcance limitado, límites de acción, comprobaciones sólidas de origen, historiales visibles, controles de revocación y detección de comportamientos inusuales.
La industria más amplia de los agentes afronta la misma tensión. OpenAI, Anthropic, Google y desarrolladores más pequeños están creando sistemas que navegan, escriben código, conectan servicios y completan trabajos de varios pasos.
Sus implementaciones difieren, pero el acuerdo subyacente sigue siendo similar. Una mayor autonomía requiere más autoridad, y una mayor autoridad incrementa el valor de cada sesión robada.
La industria ya reconoce riesgos a nivel de modelo, como la inyección de prompts y la autonomía excesiva. La guía sobre agentes de OWASP también identifica el abuso de herramientas, la escalada de privilegios, la exposición de datos sensibles y la exfiltración de datos.
El hallazgo de Wardle añade una lección conocida de seguridad de software. Un agente puede verse comprometido sin convencer a su modelo, contaminar su memoria ni escapar de su sandbox.
El atacante puede dirigirse al código ordinario de la aplicación que rodea al modelo. Eso incluye el cliente que obtiene la entrada del micrófono, almacena preferencias, gestiona la autenticación y muestra aprobaciones.
Por tanto, los desarrolladores de agentes deberían evitar tratar la seguridad tradicional de las aplicaciones y la seguridad de la IA como programas independientes. Ambas áreas se encuentran allí donde el código convencional traduce la intención del usuario en instrucciones para el modelo o autoridad sobre herramientas.
Las revisiones de seguridad deberían trazar el recorrido completo de cada credencial. Los equipos necesitan saber qué proceso la crea, por dónde viaja, qué endpoints la aceptan y qué ocurre después de un robo.
También deberían probar qué puede modificar el código local sin privilegios. Los dominios de preferencias, variables de entorno, mensajes entre procesos, archivos en caché y herramientas auxiliares merecen pruebas adversariales deliberadas.
Para los compradores empresariales, el problema va más allá del diseño de la aplicación. Los empleados pueden conectar agentes de consumo a recursos corporativos, creando una forma de IA en la sombra que los controles existentes quizá no identifiquen claramente.
Una prueba de campo de seguridad no encontró una consola empresarial documentada, exportación de auditorías ni integración de prevención de pérdida de datos para Muse. Meta no respondió antes de la publicación de ese informe.
Esa observación no demuestra que esos controles nunca llegarán. Muestra que la adopción por consumidores puede avanzar más rápido que la visibilidad centralizada.
Los equipos de seguridad necesitan registros de servicio, inventarios de conectores, supervisión de claves API y políticas para agentes que actúan mediante identidades de empleados. Vigilar únicamente las concesiones OAuth convencionales puede pasar por alto las credenciales proporcionadas manualmente.
La presión no recae solo sobre Meta. Todos los proveedores de agentes deben explicar cómo los administradores pueden descubrir accesos, restringirlos, investigar abusos y revocarlos con rapidez.
El hotfix cierra el exploit, no la brecha de confianza
Meta resolvió la redirección de endpoint demostrada, pero la evidencia pública aún no permite establecer que el límite completo del cliente de Muse se haya reforzado.
Un parche rápido es significativo. Meta reaccionó aproximadamente un día después de la divulgación pública, eliminó la configuración de producción vulnerable e impidió que la prueba de concepto original funcionara según lo previsto.
Wardle reconoció a la empresa por su rápida respuesta. Ese reconocimiento importa porque distingue una vulnerabilidad remediada de un riesgo para los usuarios abandonado.
El parche también demuestra una ventaja de un cliente mantenido activamente. Un proveedor puede eliminar comportamientos peligrosos rápidamente cuando la aplicación afectada se actualiza automáticamente o solicita a los usuarios instalar una nueva compilación.
Sin embargo, una remediación rápida no responde cómo la configuración sobrevivió al desarrollo y la revisión. Meta lanzó Muse con un programa público de recompensas por errores que ofrecía premios de hasta $300,000 por hallazgos válidos.
La empresa también describió un uso interno extenso, investigación externa, red teaming e ingeniería de defensa en profundidad. Aun así, un endpoint de transcripción modificable llegó a producción en la aplicación para Mac.
Ese contraste no demuestra que Meta ignorara la seguridad. Sugiere que su revisión se concentró en amenazas o capas del sistema distintas de la que examinó Wardle.
Las defensas más visibles de Muse se centran en el agente en la nube, las credenciales dentro de su máquina virtual, la política de red, la inyección de prompts y las decisiones de aprobación. Wardle atacó la confianza entre el cliente de Mac y esos sistemas.
Un seguimiento creíble debería explicar si Meta ha auditado configuraciones ocultas similares. También debería abordar la exposición de tokens, el alcance de las credenciales, la integridad del cliente y las protecciones locales entre procesos.
Los usuarios deberían ser prudentes al asumir que la ausencia de otro exploit público equivale a una prueba de seguridad integral. La garantía de seguridad se desarrolla mediante arquitectura, pruebas, transparencia y tiempo.
La misma cautela se aplica en sentido contrario. Una vulnerabilidad no demuestra que Muse sea permanentemente inseguro ni que todas las cuentas conectadas hayan sido comprometidas.
Los informes públicos no han establecido una explotación generalizada en el mundo real. Wardle publicó una prueba de concepto que demostraba capacidad, no evidencia de que los atacantes ya la hubieran utilizado contra una gran población de víctimas.
El ataque también requería ejecución local e interacción del usuario con el dictado. Esos requisitos redujeron de forma significativa la población expuesta.
Un análisis responsable debe sostener ambos hechos a la vez. El exploit tenía limitaciones, pero su uso exitoso aún podía producir consecuencias inusualmente amplias.
Para los usuarios actuales, actualizar Muse es el paso inmediato. También deberían revisar las cuentas conectadas del agente, los permisos locales, la actividad reciente y cualquier acción que no reconozcan.
Los usuarios que ejecutaron comandos sospechosos en Terminal deberían tratarlo como una señal de compromiso independiente. Actualizar Muse cerraría la falla del endpoint sin eliminar necesariamente el programa que modificó la configuración.
Las organizaciones deberían determinar si los empleados instalaron Muse o conectaron servicios de trabajo. Si es así, los administradores deberían revisar los registros relevantes de correo electrónico, nube, API e identidad.
El evento también respalda un enfoque gradual para adoptar agentes. Los usuarios pueden empezar con un conector de bajo riesgo en vez de conceder acceso amplio a correo electrónico, calendarios, archivos, pagos y dispositivos.
Los permisos deberían eliminarse cuando termina una tarea. El acceso de larga duración crea exposición futura sin aportar necesariamente valor continuo.
El parche de Meta restaura un límite técnico. Reconstruir la confianza requerirá evidencia de que la arquitectura del cliente circundante recibió el mismo escrutinio que las defensas en la nube del agente.
Tres señales mostrarán si Meta aprendió la lección más amplia
La próxima prueba es si Meta trata el incidente como una preferencia eliminada o como evidencia de que la seguridad de los agentes necesita una revisión más amplia del cliente.
La primera señal es una divulgación técnica detallada. Meta debería describir las versiones afectadas, la remediación exacta, el alcance de los tokens, el comportamiento de revocación y si encontró rutas de configuración relacionadas.
Una divulgación así reforzaría la confianza si muestra cambios sistemáticos más allá de eliminar una configuración. El silencio dejaría a los investigadores especulando sobre la superficie de ataque restante del cliente.
La segunda señal es una mayor visibilidad administrativa. Los usuarios de Muse ya necesitan registros claros de las acciones del agente, pero las organizaciones también necesitan formas de identificar conexiones realizadas mediante cuentas corporativas.
Las exportaciones de auditoría documentadas, los inventarios de conectores, la revocación de sesiones y las integraciones de eventos de seguridad demostrarían que Meta entiende al agente como una vía de acceso empresarial. Su ausencia mantendría la preocupación por la IA en la sombra.
La tercera señal son pruebas independientes del cliente actualizado para Mac. Wardle planea hablar sobre la falla y las amenazas más amplias de los asistentes de IA en la conferencia Objective by the Sea en noviembre.
Investigaciones posteriores podrían revelar si Muse ahora aísla las configuraciones sensibles, restringe las credenciales y separa los comandos locales de la autoridad del agente. Nuevos hallazgos del lado del cliente debilitarían la confianza en la remediación inicial.
Meta también planea una opción de Confidential VM destinada a restringir su propio acceso a la información de los usuarios. Esa función aborda la confidencialidad en la nube, no necesariamente la autenticación de clientes comprometidos.
Su lanzamiento no debe considerarse un sustituto de la seguridad de los endpoints. Un entorno de nube confidencial aún puede aceptar solicitudes que incluyan credenciales robadas a un cliente autorizado.
La importancia duradera del exploit Meta Muse reside en esa separación. El aislamiento avanzado dentro de un sistema en la nube no puede compensar todos los eslabones débiles de la aplicación que accede a él.
Los usuarios deben esperar que los agentes reciban un acceso más profundo que los chatbots, pero no deben aceptar garantías vagas en lugar de controles específicos. Los proveedores deben demostrar cómo se limita, supervisa y revoca la autoridad.
Los desarrolladores deben examinar cada punto en el que el código convencional interactúa con las credenciales o instrucciones de los agentes. Los compradores empresariales deben exigir visibilidad antes de permitir conexiones a servicios sensibles.
Meta actuó con la suficiente rapidez para cerrar la vía divulgada. Los próximos uno a tres meses mostrarán si la empresa también reduce la brecha de seguridad más amplia.
Para cualquiera que evalúe Muse u otro agente personal, la pregunta útil no es simplemente si está instalado el último parche. Pregunte qué permisos tiene el agente, cómo se combinan esos permisos y qué podría hacer una sola sesión robada.
