Персональный ИИ становится намного полезнее в тот момент, когда получает доступ к почте, браузеру и платежам. В этот же момент ошибка перестаёт быть просто плохим ответом: агент может отправить сообщение, купить товар, открыть лишние данные или передать информацию наружу.
8 сентября Meta запустила Muse, персонального агента, который умеет работать в фоне, пользоваться браузером, подключаться к сервисам и продолжать длительные задачи без постоянного присутствия пользователя. Но для меня главное в этом релизе не список функций. Meta пришлось построить вокруг модели отдельный компьютер и целую систему ограничений, потому что обычного промпта для такого уровня доступа уже недостаточно.
Muse хорошо показывает, какой становится архитектура агента, когда ему доверяют реальные аккаунты и реальные действия.
От ответа к действию: что Muse берёт на себя
Обычный чат-бот заканчивает работу там, где нужен следующий шаг пользователя. Он может написать письмо, но отправляет его человек. Может подобрать поездку, но бронировать всё равно приходится пользователю.
Muse рассчитан на другой сценарий. Пользователь задаёт цель, агент составляет план и продолжает выполнять его через доступные инструменты. Он может работать с электронной почтой, браузером, формами, покупками и подключёнными сервисами, а длительные задачи продолжаются после закрытия приложения. На старте Muse доступен только в США: в приложениях, веб-версии и WhatsApp.
Вместо жёсткой схемы «одно сообщение, один ответ» Muse рассчитан на длительный рабочий процесс. Пока агент выполняет одну задачу, пользователь может отправить следующую. Есть память между разговорами, отдельные проекты и долгосрочные цели. На стороне модели за это отвечает Muse Spark 1.3. Meta специально дорабатывала эту модель для длительных агентных сценариев, нескольких параллельных процессов и работы с инструментами.
Часть чувствительных действий остаётся за человеком. Отправка сообщения, покупка или другое действие с заметными последствиями может потребовать отдельного подтверждения. Дальше вопрос уже не в возможностях агента, а в том, кто разрешает ему действовать.
У каждого Muse есть собственный компьютер
Для пользователя создаётся отдельная виртуальная Linux-машина в облаке. Это полноценная рабочая среда с браузером, файловой системой, хранилищем, процессором и памятью.
Агент может писать и компилировать код, создавать собственные инструменты, запускать субагентов, работать по расписанию и создавать коннекторы для сервисов, у которых есть API или интерфейс командной строки. Такой подход делает Muse гораздо ближе к облачному компьютеру с агентом внутри, чем к привычному окну чата.
При этом сама виртуальная машина разделена на зоны. Основной слой управления агентом (agent harness), рабочие файлы и инструменты находятся в изолированной среде выполнения. Сервисы, которые отвечают за учётные данные, разрешения и часть защитных проверок, вынесены за её пределы.
Это важное архитектурное решение. Если модель ошибётся или прочитает вредоносную инструкцию на сайте, она не должна автоматически получить возможность переписать собственные ограничения безопасности.
Sentinel решает, что агенту действительно разрешено
Ключевой компонент Muse называется Sentinel. Это отдельный агент на стороне хоста, который контролирует действия через коннекторы и весь исходящий сетевой трафик.
Muse может предложить действие, но окончательное разрешение выдаёт Sentinel. При сетевом запросе он способен учитывать домен, IP-адрес, порт, протокол, HTTP-метод, путь и содержимое запроса. Для коннекторов он проверяет тип операции, область действия и правила, которые задал пользователь.
Если требуется согласие человека, выполнение останавливается. Запрос на подтверждение приходит в отдельном интерфейсе клиента, а не сообщением внутри разговора с Muse. Это снижает риск ситуации, когда сама модель текстом убеждает пользователя одобрить действие, которое она же предложила.
Разрешения тоже можно ограничивать. Они бывают одноразовыми, действующими в рамках сессии или конкретной задачи, ограниченными по времени или постоянными. Система старается не спрашивать пользователя о каждом чтении данных, но добавляет дополнительную проверку там, где действие действительно меняет внешний мир.
По сути, Meta разделила рассуждение и исполнение. Модель определяет, какое действие выполнить. Отдельный слой проверяет, разрешено ли ей это действие.
Пароли и браузер отделены от модели
Muse не должен видеть настоящие OAuth-токены и другие секреты подключённых сервисов. Для этого используется отдельная служба хранения учётных данных. В рабочую среду агента попадает временный токен-заменитель, а настоящий секрет подставляется только на границе сети после того, как действие разрешено.
С электронной почтой ограничения ещё жёстче. Встроенный коннектор фильтрует одноразовые коды, ссылки сброса пароля и одноразовые ссылки для входа (magic links). Причина практическая: доступ к основному почтовому ящику часто автоматически открывает дорогу к восстановлению паролей от множества других аккаунтов.
Браузер тоже не отдаётся агенту целиком. Muse использует Chromium, но браузерный субагент видит представление страницы через дерево доступности (accessibility tree), а не исходный DOM. Он не может запускать JavaScript в контексте страницы и не получает Chrome DevTools. Когда пользователь сам перехватывает управление или вводит логин и пароль через защищённый интерфейс, агент ставится на паузу.
Для платежей действует ещё один барьер. Meta использует Stripe Link и одноразовые номера карт, ограниченные конкретным продавцом, суммой и временем действия. Каждая покупка требует подтверждения человека.
Здесь хорошо виден общий принцип Muse: секретные данные или необратимое действие стараются держать за пределами рассуждающей модели.
Приватность здесь сложнее рекламного обещания
Meta заявляет, что разговоры с Muse и данные виртуальной машины напрямую не передаются её рекламным системам. Это важное ограничение, но его легко понять шире, чем оно сформулировано.
Если Muse по просьбе пользователя посещает внешний интернет-магазин, такое посещение остаётся действием пользователя во внешнем сервисе. Сам магазин может использовать его для последующего рекламного таргетинга. Поэтому отсутствие прямой передачи содержимого виртуальной машины в рекламную систему не означает, что действия агента никак не повлияют на рекламу.
Есть и более существенная оговорка. Текущая архитектура ограничивает доступ сотрудников Meta к данным организационными и техническими мерами, но не исключает такой доступ на криптографическом уровне. Компания прямо пишет, что при необходимости поддержки, защиты или работы сервиса Meta всё ещё может получить доступ к данным.
Полностью закрытый режим компания обещает позже в 2026 году в виде Muse Confidential VM. По замыслу такая среда должна обеспечить проверяемую криптографическую защиту, при которой даже Meta не сможет читать содержимое виртуальной машины. На момент запуска это будущая функция, а не свойство обычного Muse.
Данные взаимодействия тоже требуют отдельного внимания. Такие последовательности действий Meta называет trajectories: к ним относятся разговоры, вызовы инструментов и передача задач субагентам. После очистки части персональных данных они по умолчанию могут использоваться для обучения следующих версий модели. Это можно отключить в настройках.
Хорошая архитектура ещё не означает надёжного агента
Meta сама признаёт две вещи: внедрение вредоносных инструкций (prompt injection) остаётся открытой проблемой, а Muse будет ошибаться. Компания открыла программу вознаграждений за уязвимости с выплатами до 300 тысяч долларов. Сама программа важна, но она же напоминает, что защита ещё не считается законченной.
Материал Reuters добавляет важный контекст. Reuters сообщило со ссылкой на внутренние сообщения сотрудников Meta, что изначально запуск планировали на апрель, а затем отложили для дополнительной работы над безопасностью. Вице-президент Meta Вишал Шах сказал агентству, что после доработок продукт достиг минимального уровня, достаточного для публичного запуска.
В тех же внутренних тестах сотрудники описывали и полезные сценарии, и серьёзные сбои. В одном случае агент, по данным Reuters, обошёл ограничения и раскрыл личные фотографии из iCloud во время задачи по распознаванию игрушек на фотографиях детского дня рождения. В другом сценарии во время длительного мониторинга агент перестал обновлять страницу, игнорировал ошибки и временами сам отключался. Meta не прокомментировала Reuters конкретно эти эпизоды.
Для оценки Muse это важнее красивой демонстрации. Архитектура безопасности может уменьшать последствия ошибки, но она не доказывает, что многошаговая цепочка действий будет стабильно выполнена правильно.
Что из Muse стоит забрать в корпоративных агентов
Даже если сам Muse пока недоступен вашей компании, его архитектура даёт полезный ориентир для собственных агентов.
Я бы начинал с отдельной идентичности агента и доступа только на чтение там, где запись пока не нужна. Пароли и API-ключи лучше хранить в отдельном слое и подставлять непосредственно при выполнении разрешённой операции. Подтверждение критических действий стоит выводить в канал, который сама модель не контролирует.
Следующий слой нужен для журналирования и наблюдаемости. У каждого действия должен оставаться журнал: какая цель была поставлена, какой инструмент использовался, какие данные ушли наружу, какое правило доступа применилось и кто подтвердил операцию. Внешние страницы, письма и файлы лучше по умолчанию считать недоверенными входными данными, потому что именно через них агент получает инструкции, которых пользователь ему не давал.
Для такого агента я бы измерял не количество сгенерированных ответов. Полезнее смотреть на долю задач, завершённых без ручного исправления, число запросов на подтверждение, количество отклонённых действий, восстановление после сбоя и инциденты с выходом за разрешённую область. Если агент экономит время, но человек постоянно чинит его многошаговые цепочки, автономность существует только на презентации.
И наконец, у процесса должен быть владелец. Muse показывает, что даже сложная система ограничений не исключает человека из процесса. Она просто делает понятнее, в каких местах его решение действительно необходимо.
Почему в Muse интереснее устройство системы, чем сам продукт
Meta продвигает Muse как шаг к персональному сверхинтеллекту. Проверить такую формулировку сейчас невозможно, и я бы на ней не строил выводы.
Для меня важнее архитектура под этим обещанием. Когда агент получает почту, браузер, платежи и возможность работать часами без присмотра, качество основной модели перестаёт быть единственной границей доверия. Приходится изолировать среду, прятать секреты, контролировать сеть, выносить разрешения за пределы модели и сохранять историю действий.
Именно здесь, на мой взгляд, проходит следующий этап развития агентов. Конкурировать будут не только модели, которые лучше рассуждают. Важными станут системы, которые умеют давать модели реальные полномочия так, чтобы одна ошибка не превращалась в полный доступ к цифровой жизни пользователя.
Muse пока не доказывает, что такой персональный агент уже достаточно надёжен для полной автономии. Зато он довольно подробно показывает, какие инженерные слои понадобятся для такой автономии, если мы действительно хотим доверить агентам больше, чем создание черновика в чате.