Патрик Уордл заметил странную вещь в новой macOS-версии ИИ-ассистента Meta* Muse: локальный процесс без лишних прав мог подменить адрес сервера для голосового ввода. Дальше схема разворачивалась быстро — ассистент отправлял данные не туда, токен аутентификации утекал, а вместе с ним уходил и контроль над тем, что Muse умеет делать от лица пользователя.

История инцидента

Muse запустили в начале сентября 2026 года как персонального ИИ-агента для почты, календаря, покупок, соцсетей и других сервисов. За удобство пришлось платить широким набором разрешений: доступом к файлам, микрофону, камере и геолокации.

Именно здесь и спряталась проблема. Уордл нашёл недокументированную настройку endo_voyager_dictation_endpoint, которая определяет, куда Muse отправляет голосовой ввод. По умолчанию это сервер Meta*, но изменить адрес мог любой процесс, запущенный от имени текущего пользователя.

Итог для атакующего выглядел почти идеально: перехватить голосовые данные, вставить вредоносные инструкции, украсть токен и затем управлять ассистентом уже напрямую. В разборе о том, как ИИ-системы теряют границу между кодом и данными похожая ошибка описана с другой стороны — когда приложение перестаёт понимать, чему доверять.

Что пошло не так в защите

Главная ошибка — доверие к локальной среде. Разработчики Muse сделали так, что обычный процесс пользователя смог менять критичный параметр без дополнительных проверок. Для современного настольного приложения это плохая новость: один слабый участок превращает весь агент в точку входа.

Второй просчёт — перенос голосового ввода в облако. Уордл отдельно отметил, что macOS умеет обрабатывать речь локально, а значит, часть рисков можно было бы убрать на уровне архитектуры. Когда приложение само отправляет чувствительные данные наружу, любая ошибка в маршрутизации превращается в утечку.

Третий момент — слишком широкие права самого ассистента. Muse мог работать с почтой, камерой, файлами и умным домом. Если злоумышленник получает токен, он получает не просто доступ к чату, а ключ от набора сервисов, которые пользователь уже связал с приложением.

Показательно, что это не взлом macOS в прямом смысле. Система не сломалась; приложение заставили действовать с выданными ему правами. В похожих историях с ИИ-агентами это повторяется снова и снова: не код ломают первым, а доверенную связку между процессом, токеном и данными. Об этом же мы писали в материале как выдать ИИ-агенту доступ к внутренним API и не потерять контроль.

Уроки для читателя

Для обычного пользователя вывод простой: ИИ-ассистент — не «умная кнопка», а отдельный сервис с доступом к вашим данным. Чем больше он видит и умеет, тем дороже ошибка в его защите.

Если приложение просит камеру, микрофон, файлы и геолокацию, стоит десять раз подумать, действительно ли вам нужен весь этот набор. Особенно если речь о сервисе, который отправляет голосовые запросы в облако и хранит токен доступа на устройстве.

Ещё один вывод касается фишинга и социальных атак. Уордл прямо говорит о сценарии ClickFix — когда человека обманом подталкивают выполнить команду в терминале. Это не редкость, а типовая схема: сначала вас заставляют запустить лишнее действие, потом уже добирают остальное.

Для тех, кто пользуется корпоративными или личными ИИ-инструментами, важна простая гигиена: отдельные учётные записи, минимальные права, контроль разрешений и понятная схема отзыва доступа. Если ассистенту не нужен доступ к геолокации или камере, его не должно быть по умолчанию.

Практические выводы и чек-лист

  • Проверьте, какие разрешения выдали ИИ-приложениям на macOS, iPhone или другом устройстве.
  • Отключите доступ к камере, микрофону, файлам и геолокации там, где он не нужен постоянно.
  • Не запускайте команды из терминала по просьбе незнакомых сайтов, чатов и писем.
  • Следите, куда приложение отправляет данные, особенно если речь о голосе, документах и переписке.
  • Используйте менеджер паролей и двухфакторную аутентификацию для аккаунтов, связанных с ИИ-сервисами.
  • Если вы работаете из чужой или публичной сети, добавьте ещё один слой защиты через сервис для приватной работы в чужой сети.
  • После обновлений проверяйте, не изменились ли настройки доступа и не появились ли новые разрешения.
  • Для чувствительных задач отделяйте рабочие аккаунты от личных — это снижает ущерб, если токен всё же утечёт.
Поделиться: