Апелляционный суд США дал разработчикам практических AI-агентов решение, которое будут цитировать ещё долго, хотя спор далеко не завершён. 4 августа 2026 года Девятый округ снял предварительный запрет, мешавший shopping assistant Perplexity Comet работать на Amazon. Юридически это узкий вывод по Computer Fraud and Abuse Act и калифорнийскому аналогу CDAFA. Практически сигнал шире: если человек поручает AI-браузеру использовать сайт, который сам имеет право открыть, такой агент выглядит скорее инструментом пользователя, чем взломщиком.

AI-ассистент пользователя действует на торговом сайте с учётом платформенных и юридических ограничений

Что именно изменилось

Amazon подала иск против Perplexity в ноябре 2025 года и в марте 2026-го добилась preliminary injunction в федеральном суде Северного округа Калифорнии. В центре спора был Comet, браузер Perplexity с функцией Assistant. В материалах дела Comet описан как браузер, работающий локально на компьютере пользователя. Когда пользователь просит Assistant найти товар на Amazon, с экрана браузера делаются screenshots, они отправляются с компьютера пользователя на серверы Perplexity, а обратно приходят инструкции, как двигаться по странице. Amazon считал это несанкционированным доступом к своим системам. Perplexity настаивала: сайт открывает пользователь, а программа только помогает ему действовать.

Девятый округ на стадии предварительного запрета принял эту логику. Суд указал, что Amazon, вероятно, не сможет доказать, что сама Perplexity ‘accessed’ компьютеры Amazon в смысле CFAA. Главная фраза решения важна для всех команд, делающих агентов: по имеющимся фактам именно пользователь получает доступ к системам Amazon с помощью Assistant, чтобы выполнить конкретные действия на Amazon.com. По CDAFA суд пришёл к тому же результату, отменил запрет и вернул дело в нижестоящий суд.

Это не окончательная победа по всем вопросам. Это не разрешение игнорировать правила сайтов. Это не юридическая консультация для стартапов. Суд сам сузил рамку: речь о prong ‘access’ в CFAA и CDAFA, о текущем record и о preliminary injunction. Основное дело продолжается. Amazon может ссылаться на terms of service, договорные ограничения, безопасность аккаунтов, защиту потребителей, privacy, unfair competition или другие основания, если факты позволят. Но один сильный аргумент платформ ослаб: user-directed agent уже труднее автоматически называть незаконным компьютерным вторжением.

Почему это больше, чем онлайн-шопинг

Покупка товара — самая понятная сцена, но не главный предел темы. Полезные AI-агенты становятся полезными не в чате, а когда умеют читать страницы, заполнять формы, сравнивать варианты, переносить данные между сервисами, просить подтверждение и выполнять рутинные действия. Это касается retail, travel booking, expense reports, procurement, support consoles, SaaS administration, CRM, invoices и внутренних веб-инструментов, у которых нет нормального API. Во многих компаниях веб-страница всё ещё является настоящим рабочим интерфейсом.

Платформы смотрят на это будущее иначе. Marketplace, авиакомпания, издатель или SaaS-сервис проектируют интерфейс не только ради удобства, но и ради ranking, рекламы, рекомендаций, fraud controls, analytics, rate limits и поддержки. Сторонний агент может обходить sponsored placements, игнорировать cross-sell, собирать comparison data, будить антибот-системы, выбирать не тот товар или создавать traffic, который трудно атрибутировать. В аргументах Amazon речь шла не только о рекламе: фигурировали private customer accounts, stored payment and delivery information, automated traffic и вопрос, должен ли внешний assistant действовать внутри защищённого аккаунта.

Поэтому это тема именно для практики AI. Команды, делающие browser agents, получили более реалистичный путь для user-directed access, но вместе с ним — обязанность строить агентов как accountable tools, а не скрытых автоматов. Платформам выгоднее проектировать официальные пути делегирования, а не только ставить блокировки. Бизнесу, который внедряет агентов, пора считать browser automation не удобной инженерной фичей, а юридическим, безопасностным и управленческим решением.

Логика суда простыми словами

CFAA задумывался как anti-hacking statute. Верховный суд США и Девятый округ уже не раз осторожно относились к попыткам превратить обычное использование компьютера в федеральное преступление только потому, что задействован компьютер. В этом деле вопрос был: кто вошёл в систему Amazon? Серверы Perplexity напрямую не запрашивали страницы Amazon. Страницу запрашивал браузер пользователя, показывал её пользователю, а Assistant анализировал то, что уже отобразил браузер. Серверы Perplexity могли получать screenshots и возвращать instructions, но суд сказал: этого самого по себе недостаточно, чтобы считать, что Perplexity gained entry to Amazon’s servers.

Суд отдельно подчеркнул: Assistant — инструмент, а не юридическое лицо. CFAA говорит о ‘whoever’ intentionally accesses a protected computer. Каким бы сложным ни был Assistant, для целей статута он остаётся tool, not a person. Это важно, потому что в продуктовых дискуссиях AI-агентов часто описывают как самостоятельных акторов. В других правовых контекстах поведение агента могут приписывать компании, и суд прямо не решал tort liability или весь правовой режим agentic AI. Но для элемента access в hacking-law анализе фокус был на человеке и архитектуре браузера.

Не менее важен public interest. Суд указал, что запрет на действия, которые, вероятно, не нарушают CFAA или CDAFA, ограничил бы consumer choice и development of a nascent technology. Эту фразу будут любить AI-компании и digital-rights groups. Но footnote тоже важна: решение не лишает Amazon возможности регулировать доступ через private terms of service для пользователей. Суд не сказал, что у платформ нет контроля. Он сказал, что антихакерский закон нельзя растягивать слишком широко на этом наборе фактов.

Что должны вынести разработчики

Неправильный вывод — ‘запускаем бота, юристы потом разберутся’. Правильный вывод — архитектурный. Направление пользователя должно быть явным, конкретным и записанным. Агент, который действует только после определённой команды пользователя, защищается лучше, чем агент, который молча бродит по сайтам, кликает и покупает. Для checkout, изменения аккаунта, подписок, отмен, возвратов, сообщений и любых действий с деньгами нужны approval gates. Пользователь должен понимать, когда агент читает, когда заполняет форму и когда вот-вот создаст обязательство.

Идентичность агента тоже нельзя оставлять в тени. Спор о user-agent string не исчез из-за отмены injunction. Если платформа считает, что агент маскируется под обычный Chrome, чтобы избежать блокировки, конфликт переедет в contracts, anti-fraud, доверие и коммерческие санкции. Команды должны заранее решить, как агент представляется, какие настройки есть у пользователя и что происходит, когда сайт запрещает automation. Скрытый обход может выиграть демо, но проиграть рынок.

Data minimization становится функцией продукта. В описанной архитектуре Comet screenshots браузера могут уходить на удалённые серверы, чтобы модель решила следующий шаг. Это может быть технически оправдано, но вызывает вопросы: какие поля попадают в кадр, видны ли account data, адреса и payment information, как долго хранятся screenshots и traces, можно ли маскировать sensitive fields, возможен ли local processing для enterprise. Агент, читающий procurement portal или HR-систему, нуждается в data-handling design раньше, чем в красивом проморолике.

Что спросить компаниям, внедряющим агентов

Предприятие не должно трактовать решение как разрешение направить автономный браузер во все внутренние и внешние сервисы. Первый вопрос — authority: кто дал команду агенту, для какой цели, под каким аккаунтом и с каким лимитом расходов? Второй — evidence: какие logs показывают instruction, промежуточные решения, approvals, ошибки и итоговое действие? Третий — site policy: разрешает ли целевой сервис automation, требует ли API, запрещает ли credential sharing или non-human traffic? Четвёртый — containment: может ли агент работать в sandboxed profile со scoped credentials, а не в полном браузере сотрудника?

Для procurement, travel и SaaS administration чеклист вполне практический. Нужны подтверждения перед покупками и отменами. По возможности — отдельные payment instruments. Агент должен работать только с approved vendors. Действия стоит rate-limit. Аудитные следы нужны, но не надо бессрочно хранить лишние screenshots. Нужно тестировать prompt injection из product pages, messages и hidden instructions. И заранее определить, кто отвечает, если агент заказал не тот товар, изменил неправильный tenant или забронировал неудобный рейс.

Что делать платформам

Платформы тоже не обречены. Блокировать любого стороннего агента как bot будет сложнее там, где пользователь явно делегирует действие. Но ничего не делать невозможно. Retailers и SaaS-сервисы могут строить official agent APIs, delegated-auth flows, scoped tokens, agent-readable policies, checkout confirmation protocols и audit channels. Они могут отличать помощника, покупающего один товар для пользователя, от scraper, который массово собирает catalog data. Они могут отдавать безопасные comparison feeds, не отдавая полный контроль над payment flows.

Retail media — болевая точка бизнеса. Если агент сравнивает товары по цене, доставке, возвратам и реальным предпочтениям пользователя, sponsored ranking и recommendation funnels теряют часть силы. Рекламодатели покупают человеческое внимание, а агент может игнорировать баннеры и upsell. Это не смерть рекламы, но перенос борьбы на agent layer: structured claims, reputation signals, first-party assistants, paid placement в agent-readable results. Тогда регуляторы и пользователи спросят, служит ли агент человеку или рекламному инвентарю платформы.

Безопасность остаётся трудной частью

Browser agents особенно уязвимы к prompt injection. Product page, review, email, support chat или hidden webpage text могут попытаться приказать агенту игнорировать пользователя, утечь данные, выбрать худший товар или сменить delivery address. Shopping agent работает с платежами, адресами, возвратами и доверием аккаунта. Даже если закон видит в нём инструмент пользователя, пользователь не примет ответ ‘инструмент сам нажал’, когда потеряны деньги. Нужны isolation, instruction hierarchy, transaction confirmations, sensitive-field masking, rollback paths и fraud monitoring.

Девятый округ отметил, что доказательства Amazon по cyber-risk были ограничены в этом record. Это не означает, что agentic browsing безопасен. Это означает, что Amazon не доказал достаточно для injunction. Security-команды должны исходить из того, что агента будут атаковать через страницы, которые он читает: malicious listings, hidden text, misleading buttons, fake login prompts, poisoned comparison tables, refund abuse и account-takeover scenarios.

Граница: инструмент, а не скрытый оператор

Сильная версия agentic web automation — это agency пользователя: человек вправе принести инструмент, который помогает понимать, сравнивать и действовать в сервисах, куда он уже имеет доступ. Слабая версия — stealth operation: серверы компании управляют действиями в аккаунте, скрывают identity агента, собирают лишние данные и воспринимают platform rules как помеху. Решение суда помогает первой истории. Оно не защищает каждую версию второй.

Для AI-стартапов выигрышный язык дизайна должен быть скучным и проверяемым: explicit user instruction, consent, least-privilege credentials, transparent identity, logs, confirmation gates, data minimization, platform-aware fallbacks и refusal, когда сайт не разрешает automation. Для бизнеса это повод пилотировать осторожно, а не обходить legal and security review. Для платформ — предупреждение, что user choice становится частью спора о вебе.

Итог

Perplexity-Amazon decision не легализовал всех AI-ботов и не решил судьбу agentic commerce. Он сделал более узкую и полезную вещь: показал, что genuinely user-directed browser assistant труднее приравнять к hacking under CFAA на этих фактах. Этого достаточно, чтобы сдвинуть практический разговор. Следующее поколение агентов будут оценивать не только по способности кликать по сайту, а по тому, могут ли они доказать, чью команду выполняют, какие данные трогают, как себя обозначают и где останавливаются до вреда.