Версия Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Блокировка Muse компанией Amazon ставит под вопрос, кто выбирает торгового агента покупателя

> Сообщение о блокировке Meta Muse на Amazon разделяет согласие покупателя и готовность продавца допустить агента. Последствия касаются охвата поиска, оформления покупки и поддержки клиентов.

By BIG CHANGE Editorial

Published: 2026-09-22T07:50:15.731Z
Updated: 2026-09-22T07:50:15.731Z
Canonical: https://bigchange.ai/blog/amazon-muse-shopping-agent-access

![A browser-shaped shopping card, blank instruction slip and orange pen stand outside a generic storefront with a closed door.](https://bigchange.ai/api/media/file/shopping-agent-store-access-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. A shopper can instruct an assistant while the retailer refuses that agent access. The closed storefront represents a software access boundary, not a shop barring the buyer. Conceptual illustration, not a screenshot of Muse or Amazon.

По сообщению GeekWire от 20 сентября Amazon заблокировала Meta Muse для покупок клиентов на своём сайте. Amazon заявила изданию, что Muse работала без соглашения и надлежащего распознавания агента, а также выразила обеспокоенность сбором и хранением учётных данных клиентов. В статье приведён снимок экрана с блокировкой, предоставленный Amazon. К вечеру воскресенья на момент публикации Meta не ответила. Это возражения Amazon, а не установленные факты утечки данных. [Первоначальный материал GeekWire](https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/)

Для покупателя такое прерывание ставит неловкий вопрос. Если вы поручаете ассистенту сравнить товары и оформить заказ, какая часть вашего выбора сохраняется, когда магазин решает, каких ассистентов принимать?

Ответ поможет понять, упростят ли торговые агенты сравнение магазинов или ограничат покупателей новым кругом одобренных партнёров. Это важно и для небольших продавцов: они могут приветствовать новый источник заказов, но беспокоиться о том, кто будет объяснять их товары и исправлять ошибки. Полномочия покупателя, участие магазина и одобрение платежа — разные стороны сделки.

## Работающее подключение к оплате всё ещё требует согласия магазина

8 сентября Meta представила Muse как персонального агента, способного продолжать задачи на выделенном облачном компьютере. В описании запуска упомянуты покупки и сказано, что для важных действий, включая оплату, нужно одобрение. Это описание компании, а не результаты испытаний BIG CHANGE. [Анонс Muse от Meta](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/)

Stripe конкретнее описывает подключение платежей. В объявлении от 8 сентября сказано, что потребители в США могут подключить Link к Muse. В магазинах, использующих Link, агент может задействовать сохранённый предпочтительный способ оплаты клиента. В остальных случаях Link может выдать одноразовую виртуальную карту для одобренной покупки. Клиент подтверждает сумму в разговоре, а Muse не получает исходные платёжные данные. [Объявление об интеграции Stripe](https://stripe.com/newsroom/news/stripe-helps-meta-muse-shop-with-link)

Защищённый способ оплаты может сократить объём сведений, необходимых агенту для платежа. Но он сам по себе не обязывает продавца принять визит агента. Так же и указание покупателя приобрести конкретную вещь не объясняет магазину, как отличить это поручение от нежелательной автоматизации. Системам нужно распознавать полномочия покупателя и не считать, что любое действие программы входит в их пределы.

В нашем предыдущем [анализе платёжных разрешений для ИИ-агентов](https://bigchange.ai/blog/ai-agent-payments-mastercard-visa-credit-card) рассматривались ограничения расходов. Нынешний спор обнаруживает более раннюю зависимость: ассистенту нужен доступ к достаточной части процесса покупки, чтобы подготовить заказ для одобрения клиентом.

Представим гипотетическое поручение купить совместимую деталь для бытового прибора в пределах фиксированного бюджета и доставить её до назначенного ремонта. Ассистенту нужно найти точную подходящую модель, проверить наличие и доставку, а затем перейти к оплате. Одобренное платёжное поручение полезно лишь после выполнения этих условий. Блокировка во время поиска может повлиять на выбранные товары, а блокировка на этапе оплаты — вынудить покупателя повторить уже делегированную работу.

![Three separate groups show a blank instruction sheet and pen, a storefront, and a payment card beside a terminal.](/api/media/file/three-shopping-decisions-inline-v1.png)

## Хранение пароля и доступность его модели — разные вопросы

В техническом описании Meta сказано, что учётные данные хранятся в защищённой службе внутри виртуальной машины пользователя, отдельно от среды выполнения основного агента. Браузер получает их при необходимости, а основная модель агента их не видит. Отдельный надзорный компонент проверяет действия и может потребовать одобрения. Meta также сообщает, что действующие операционные меры технически не мешают компании при необходимости получить доступ к виртуальной машине для работы сервиса. Предлагаемая версия с конфиденциальными вычислениями — будущий этап. [Описание защиты и безопасности Meta](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse)

Если пароль не попадает в контекст модели, это может ограничить один из способов его раскрытия. Однако сервису всё равно нужно где-то хранить или использовать учётные данные. Следует выяснить, кто может обращаться к этому хранилищу, какие права даёт сеанс и как можно отменить доступ. Заявление об одном компоненте не отвечает на все вопросы.

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

Коммерческий интерес Amazon в сохранении отношений с покупателями не делает опасения компании по поводу безопасности ложными. Защиту, описанную Meta, также нужно независимо изучить. Данные о реальном доступе и сбоях были бы полезнее, чем предпочтительные каждой компанией описания конкурента.

## Amazon тоже хочет, чтобы агенты совершали покупки за пределами её магазина

В опубликованном описании сервиса Buy for Me Amazon объясняет покупку товаров на сайтах сторонних брендов через своё приложение. Клиент подтверждает заказ; бренд отвечает за доставку, возвраты и поддержку. По словам Amazon, бренды могут сами решать, участвовать ли в программе. На странице описывается начало бета-тестирования, поэтому её не следует считать текущим полным списком поддерживаемых магазинов. [Описание Buy for Me от Amazon](https://www.aboutamazon.com/news/retail/amazon-shopping-app-buy-for-me-brands)

Этот пример показывает, почему условия участия нужно изучать. Продавец может приветствовать автоматические заказы, если знает посредника и согласовал способ разрешения проблем. Тот же продавец может возражать против незнакомого агента, использующего аккаунты клиентов через обычный браузер. Различия в реализации могут оправдывать разный подход.

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

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

## Решение по Comet не разрешает спор вокруг Muse

4 августа Апелляционный суд девятого округа отменил предварительный судебный запрет в отношении Perplexity и вернул дело на дальнейшее рассмотрение. На основании имевшихся материалов суд решил, что Amazon, вероятно, не докажет необходимый элемент доступа по федеральному закону о компьютерном мошенничестве и злоупотреблениях и его аналогу в Калифорнии. Браузер Comet работал на компьютере пользователя; суд рассматривал ситуацию как доступ самого пользователя к Amazon с помощью ИИ-инструмента. Суд отдельно сохранил за Amazon право регулировать действия пользователей условиями частного соглашения. [Первоначальное решение апелляционного суда](https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf)

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

Для компаний, планирующих сервисы на базе агентов, благоприятное решение по другому продукту не заменяет понимания собственных условий доступа. В обещаниях клиентам следует точно описать, где сервис действительно работает и что происходит при споре о разрешениях.

## Утверждение «лучшее из доступного» требует ясных границ поиска

Самый убедительный аргумент в пользу торговых агентов — сокращение повторяющейся работы. Человек должен иметь возможность один раз указать важные условия, сравнить подходящие предложения и сохранить контроль над итоговой покупкой. Особенно полезной надёжная помощь может быть тому, кому трудно заполнять формы или некогда искать точную замену.

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

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

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

Уверенный ответ в чате может легче скрыть ограниченный поиск, чем открытый список магазинов. В нашем предыдущем [разборе коммерческих стимулов Muse](https://bigchange.ai/blog/meta-muse-zuckerberg-make-money-earnings-business-model) рассматривалось, кто выигрывает от рекомендаций ассистента. Ограничения доступа могут влиять на результат ещё сильнее: некоторые продавцы могут вообще не попасть в сравнение.

## Продавцам нужны данные о завершённых заказах

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

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

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

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

## Sources

- [GeekWire: Amazon блокирует торгового агента Meta Muse](https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/) — Первоначальный материал Тодда Бишопа, опубликованный в воскресенье вечером. Amazon предоставила заявление и снимок экрана; этот материал независимо не подтверждает факт нарушения безопасности.
- [Meta: представляем Muse — персонального ИИ-агента](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/) — Описание запуска подтверждает предполагаемый процесс покупок и требование одобрения. Заявления о продукте исходят от Meta; BIG CHANGE не тестировало его эффективность при покупках и не воспроизводило описанную блокировку.
- [Stripe: покупки через Muse с Link](https://stripe.com/newsroom/news/stripe-helps-meta-muse-shop-with-link) — Описание интеграции платёжным провайдером для США, одобрения транзакции и виртуальных карт с ограниченным назначением. Оно объясняет заявленный механизм оплаты, но не подтверждает разрешение посещать любой магазин или гарантию успешной покупки.
- [Meta: защита и безопасность ИИ-агентов — подход Muse](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse) — Техническое описание различает хранение учётных данных, видимость для модели, надзор и операционный доступ. Версия с конфиденциальными вычислениями описана как будущая работа. Это описание разработки поставщиком, а не независимый аудит безопасности.
- [Amazon: Buy for Me и магазины внешних брендов](https://www.aboutamazon.com/news/retail/amazon-shopping-app-buy-for-me-brands) — В объявлении бета-функции от Amazon описаны участие брендов и ответственность за доставку и возвраты. Источник используется для сравнения моделей участия, а не для подтверждения всеобщей доступности, исчерпывающего списка продавцов или фактического соблюдения правил всеми участниками.
- [Апелляционный суд девятого округа: Amazon.com Services против Perplexity AI, дело № 26-1444](https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf) — Оригинальное решение, страницы 15–17 и сноска 5. Факты об архитектуре Comet отличаются от архитектуры Muse.