4 августа 2026 года Апелляционный суд девятого округа США отменил предварительный запрет, который с марта не давал агентному браузеру Perplexity Comet ходить в аккаунты пользователей на Amazon. Формально это спор двух корпораций о покупках через ИИ. Фактически — первое апелляционное решение, которое отвечает на вопрос, важный далеко за пределами агентной коммерции: кто именно «получает доступ» к чужому серверу, когда запрос отправляет автоматизация. И ответ суда неожиданно упёрся не в право, а в сетевую архитектуру.
Что произошло: от иска до отмены запрета
Хронология спора выглядит так:
- Ноябрь 2025 — Amazon подаёт иск против Perplexity AI, ссылаясь на федеральный Computer Fraud and Abuse Act (CFAA) и его калифорнийский аналог. Претензия: агент Comet логинится в аккаунты пользователей, просматривает товары и инициирует покупки, то есть работает в защищённой паролем зоне без авторизации самой площадки.
- Предыстория — по версии Amazon, компания предупреждала Perplexity как минимум пять раз начиная с ноября 2024 года, в августе 2025 выставила технический барьер, а Perplexity выпустила обновление, обходящее его, в течение суток. Отдельный упрёк: агент маскировался под обычную сессию Google Chrome.
- 9 марта 2026 — судья Максин Чесни (Северный округ Калифорнии) выносит предварительный запрет и обязывает уничтожить полученные у Amazon данные. Её формула: доступ шёл с разрешения пользователя Amazon, но без авторизации со стороны Amazon.
- 4 августа 2026 — Девятый округ (дело № 26-1444) отменяет запрет: Amazon вряд ли выиграет по существу CFAA-претензии.
Amazon заявила, что с решением не согласна и продолжит спор. Perplexity ответила, что будет отстаивать право пользователей выбирать любой ИИ. Дело при этом никуда не делось: разбирательство в суде первой инстанции продолжается, а Amazon может просить пересмотра или пойти выше.
Ключевой ход: агент — это инструмент, а не лицо
CFAA наказывает за доступ к «защищённому компьютеру» без авторизации. Весь спор свёлся к одному глаголу: кто совершил акт доступа. Amazon говорила — Perplexity, потому что это её агент действовал на площадке. Perplexity отвечала — пользователь, который дал агенту команду.
Апелляционный суд встал на вторую позицию и сформулировал это прямо: каким бы продвинутым агент ни был, для целей закона «it is a tool, not a person» — инструмент, а не лицо. Когда пользователь поручает агенту что-то сделать на Amazon.com, доступ к компьютерам Amazon осуществляет именно пользователь.
Это логическое продолжение линии Верховного суда в деле Van Buren v. United States (2021), которое сузило CFAA: закон карает за проникновение туда, куда доступа нет вовсе, а не за использование легального доступа «не по назначению». У пользователя Amazon есть аккаунт и есть право в него зайти. Инструмент, которым он это делает, сам по себе субъектом взлома не становится.
Почему всё решила архитектура трафика
Самая интересная для практиков часть решения — техническая. Суд разобрал, как физически устроен Comet Assistant, и именно это определило исход.
Схема работы такая: агент делает скриншоты окна браузера на машине пользователя, отправляет их на серверы Perplexity, а оттуда приходят инструкции по навигации — обратно на компьютер пользователя, который и выполняет действия. Серверы Perplexity напрямую с серверами Amazon не разговаривают. Весь трафик, который Amazon видит у себя, приходит с устройства и IP-адреса самого пользователя.
Отсюда и вывод суда. Если запрос физически исходит от пользователя, то и «доступ» в смысле CFAA совершил он.
Чем это отличается от Power Ventures
До сих пор канонической историей про сторонний доступ с согласия пользователя было дело Facebook v. Power Ventures (2016). Там суд решил, что площадка может отозвать доступ у стороннего сервиса, даже если пользователи добровольно передали ему свои учётные данные. Именно на этот прецедент опиралась судья первой инстанции, распространяя его на ИИ-агентов.
Девятый округ развёл эти дела по одному признаку — и снова по архитектурному. В Power Ventures системы самого ответчика напрямую слали сообщения на платформу Facebook, минуя машину пользователя. У Perplexity такого канала нет. Разная топология трафика — разный ответ на вопрос «кто получил доступ».
Практический смысл этого разграничения трудно переоценить. Оно означает, что дизайн системы — клиентский агент на устройстве пользователя или серверный сервис, ходящий на площадку от себя — перестал быть чисто инженерным выбором и стал юридическим аргументом.
Чего решение НЕ сделало
Суд сам постарался максимально ограничить радиус поражения и прямо оговорил, что не создаёт новый правовой режим для агентного ИИ. Что осталось за скобками:
- Нарушение пользовательского соглашения. Претензии из договора, деликта и правил площадки решение не закрывает — их можно предъявлять отдельно.
- Иски к самим пользователям. Если доступ совершает пользователь, то и адресатом претензий площадка может выбрать его.
- Серверные архитектуры. Вывод сделан под конкретную схему. Облачный скрапер или SaaS-агент, который ходит на площадку со своей инфраструктуры, под эту логику не подпадает автоматически.
- Технические блокировки. Ни одно слово в решении не запрещает Amazon детектировать и резать автоматизацию. Право блокировать никуда не исчезло — исчезла возможность подпереть блокировку уголовной статьёй.
Это, кстати, разворот привычной картины: раньше юридический риск был у того, кто автоматизирует, а техническая защита считалась второй линией. Теперь для площадок техническая защита стала первой линией.
Что это меняет на практике
Для всех, кто собирает данные, автоматизирует аккаунты или строит агентов, из решения следуют три рабочих вывода.
1. Точка выхода трафика получила юридический вес
Раньше выбор между «гоняем всё через свой дата-центр» и «работаем с адресов, неотличимых от пользовательских» был вопросом проходимости и стоимости. Теперь это ещё и вопрос о том, чьим действием считается запрос. Архитектура, при которой обращение к площадке исходит с пользовательской стороны, оказалась защитимее в суде — и заодно она же исторически лучше проходит антибот-фильтры. Это редкий случай, когда юридический и технический стимул совпали и указывают в одну сторону: на резидентные прокси и пользовательские точки выхода вместо серверных подсетей. Для нейтральных задач вроде мониторинга публичных цен или проверки выдачи по регионам по-прежнему хватает датацентр-прокси — там нет ни залогиненной зоны, ни спора о чьём-либо аккаунте.
2. CFAA ослаб — договор и детект усилились
Не стоит читать решение как «теперь можно». Убрана самая тяжёлая дубина — федеральная статья с уголовным потенциалом. Остались пользовательское соглашение, блокировка аккаунта, гражданский иск и, главное, антибот-стек. Площадки, потеряв часть правового рычага, будут компенсировать это детектом: фингерпринтингом, поведенческим анализом и подписанными агентами. Про то, как индустрия пытается легализовать «хороших» ботов техническими средствами, мы разбирали в материале о Web Bot Auth и подписанных агентах.
3. Риск сместился к конечному пользователю
Обратная сторона победы Perplexity: если действует пользователь, то и отвечает пользователь. Для сервисов, которые дают клиентам автоматизацию как продукт, это повод честно проговаривать в документации, от чьего имени и с чьего IP выполняются действия и какие правила площадок при этом затрагиваются.
Что делать прямо сейчас
- Опишите свою топологию доступа. Ответьте на один вопрос: чей IP видит целевая площадка в логах — ваш серверный или пользовательский. От этого зависит и юридическая позиция, и профиль детекта.
- Разделите публичное и залогиненное. Сбор открытых страниц и действия внутри чужого аккаунта — принципиально разные истории по риску. Смешивать их в одном пайплайне не стоит.
- Не маскируйтесь агрессивно после прямого запрета. В этом деле именно обход выставленного барьера и подмена клиента под Chrome дали Amazon самые сильные факты. CFAA-претензия рассыпалась, но остальные основания живы.
- Выбирайте тип выхода под задачу. Практическую сторону — как поднять агента на Playwright или MCP и корректно завернуть его трафик — мы подробно разбирали в гайде по прокси для ИИ-агентов.
Вывод
Девятый округ не легализовал автоматизацию и не выдал агентам пропуск куда угодно. Он сделал более узкую, но более важную вещь: привязал понятие «доступа» к тому, откуда физически идёт запрос. Инструмент, работающий на машине пользователя, доступ не совершает — его совершает человек. Инфраструктура, которая ходит на площадку от себя, остаётся в зоне старых рисков.
Для рынка это означает смещение центра тяжести. Правовой спор о том, «можно ли», всё чаще будет упираться в инженерный вопрос «чей адрес в логе». А сама борьба за доступ окончательно переезжает туда, где и шла всё это время, — в антибот-детект, фингерпринтинг и качество точек выхода.