ИИ-агенты просматривают сайты от имени пользователя с настоящими учётными данными. Как сайты учатся классифицировать такой трафик, а не просто блокировать его.
Десять лет подряд «автоматизированное» и «нежелательное» были почти синонимами — настолько, что большинство систем обнаружения даже не пытались их разделять. Но когда ИИ-агенты начали ходить по сайтам от имени вошедшего в систему пользователя — заполнять формы, сравнивать цены, оформлять заявки, — используя сессию этого человека и его же согласие, старая модель «или человек, или бот» перестала работать. Теперь сайту нужно раскладывать трафик не на две, а на три категории: заявленные агенты, скрытая автоматизация и люди, — а не просто решать «бот или нет».
Главное
- У старого деления «бот/человек» появилась третья категория: ИИ-агент, действующий с реальными учётными данными и с согласия пользователя, — это автоматизация, но не та «нежелательная автоматизация», ради которой создавалось обнаружение ботов.
- В июне 2026 года Chrome выпустил инструменты для работы с агентами — категорию аудита Lighthouse «Agentic Browsing» (доступна начиная с Chrome M150) и предлагаемый стандарт WebMCP для предоставления агентам структурированных инструментов; всё это описано в посте разработчиков Chrome от 22 июня 2026 года. Цель — упростить агентам работу с сайтами, а не научить сервер распознавать агентский трафик.
- Клиентские сигналы из наших прежних гайдов по обнаружению ботов — утечки headless-режима, артефакты CDP — по-прежнему срабатывают, но сами по себе больше не означают «это бот»: агент вполне может управлять настоящим, не headless-браузером.
- Поведение остаётся тем слоем, который реально разделяет эти три категории, и это вероятностная оценка, а не таблица соответствий.
- Это задача классификации, а не блокировки — авторизованный агент, выполняющий то, о чём его попросил пользователь, не является тем, что обнаружение ботов должно останавливать.
От двух категорий к трём
Обнаружение ботов всегда строилось на простой предпосылке: трафик — это либо человек, либо нежелательная автоматизация, и задача сводится к тому, чтобы отличить одно от другого. Предпосылка работала, потому что автоматизация, действующая от имени конкретного человека, с его явного разрешения и в реальном времени, была редкостью. Скраперы собирали данные, краулеры обходили страницы, а боты для credential stuffing перебирали пароли — ничто из этого не подменяло собой конкретного залогиненного пользователя, выполняющего конкретное действие, о котором он попросил.
ИИ-агент в браузере ломает эту схему. Когда агент заходит в интернет-магазин с сохранёнными учётными данными пользователя и добавляет товары в корзину, потому что пользователь его об этом попросил, трафик автоматизирован, но называть его «нежелательным» неверно — пользователь хочет именно этого. Теперь сайту нужны три категории: агенты, которые заявляют о себе или иным образом выглядят как агенты и делают то, что авторизовал владелец аккаунта; автоматизация, скрывающая свою природу; и обычный человеческий трафик. Спутать первые две — в любую сторону — обходится дорого: заблокируешь легитимного агента, и задача платящего пользователя провалится; пропустишь скрытую автоматизацию только потому, что она похожа на «дружелюбного» агента, — и дверь, которую обнаружение ботов должно было закрыть, снова открыта.
Группа сигналов 1: что агент может заявить о себе
Самый новый слой сигнала — это не заголовок и не строка, которую легко подделать, а структурированный интерфейс, который сайт может предоставить по своему желанию. В посте разработчиков Chrome от 22 июня 2026 года описаны два компонента для этого: предлагаемый стандарт WebMCP, который там охарактеризован как работа над тем, чтобы «предоставить структурированные инструменты ИИ-агентам на существующих сайтах, ускоряя и упрощая взаимодействие с агентами», и категория аудита Lighthouse «Agentic Browsing», доступная начиная с Chrome M150. Последняя выполняет детерминированные проверки в трёх областях: есть ли у интерактивных элементов программно доступные имена в дереве доступности (той же машиночитаемой структуре, на которую опираются вспомогательные технологии), визуальная стабильность, измеряемая как Cumulative Layout Shift, и интеграция с WebMCP. В посте также описан Chrome DevTools для агентов: симуляция точных шагов, которые агент предпримет на странице, прямой вызов Lighthouse, а также запись экрана и подробные логи, показывающие, как агент «видит» страницу.
Ничто из этого не является механизмом обнаружения — скорее наоборот: это инфраструктура, позволяющая сайту самому решить стать понятнее для агентов, исходя из предположения, что хорошо структурированная страница с поддержкой WebMCP даёт более качественное и предсказуемое взаимодействие с агентом, чем страница, которую агенту приходится скрейпить и угадывать. Как описано в посте Chrome, ничто из этого не предназначено для аутентификации или пометки личности агента на стороне сервера: это инструментарий для создания дружелюбных к агентам страниц, а не протокол, по которому агент мог бы доказать, кто он. Появится ли устойчивый, кроссвендорный способ для агента заявить о себе на уровне запроса — явный заголовок, подписанный токен, — пока открытый вопрос, на который нынешний инструментарий ответа не даёт.
Группа сигналов 2: признаки, которые стали неоднозначными
Большая часть того, что сайт и раньше мог наблюдать в браузерной сессии, создавалась ради того, чтобы ловить автоматизацию, которая скрывает свою природу. Эти сигналы по-прежнему срабатывают — просто сами по себе они теперь значат меньше. ИИ-агент, выполняющий реальную задачу, часто управляет настоящим, полноценным, не headless-экземпляром браузера: настоящим движком рендеринга, настоящим WebGL-выводом на базе GPU, настоящим списком плагинов. Признаки headless-браузера — программный рендеринг через SwiftShader, пустой массив плагинов, противоречивые состояния разрешений — были надёжны потому, что легитимные человеческие сессии их попросту не порождали. Агент, управляющий настоящим окном Chrome с настоящей поверхностью отображения, ничего из этого не вызывает — и не должен: браузер действительно не headless.
Тот же сдвиг происходит уровнем ниже, на уровне протокола автоматизации. Обнаружение автоматизации через Chrome DevTools Protocol (CDP) — отслеживание побочного канала Runtime.enable и похожих артефактов управляющего слоя — технически по-прежнему работает: агентский фреймворк, управляющий браузером через CDP, всё так же оставляет эти следы. Меняется то, что означает положительный результат. Раньше это было почти прямым вердиктом «бот». Теперь это лишь доказательство того, что браузером кто-то управляет программно, — а это верно и для скрейпера, и для легитимного агента. Ослаб не сам сигнал, а вывод, который из него можно сделать.
Группа сигналов 3: поведение по-прежнему разделяет категории
Пока заявительные интерфейсы в зачаточном состоянии, а клиентские признаки автоматизации стали неоднозначными, основную работу по разделению трёх категорий выполняет поведенческая оценка. Сигналы те же, что описаны в нашем гайде по поведенческому обнаружению ботов, — физика движения указателя, тайминг нажатий клавиш, смена фокуса, состояние видимости страницы, — но оцениваются они непрерывно на протяжении сессии, а не разово. Агент, заполняющий форму, не делает тех микродвижений «промахнулся — поправился», которые производит живая рука; у него нет пауз и заминок человека, читающего страницу; и вкладка у него обычно не теряет и не возвращает фокус так, как это бывает в реальной многозадачной сессии.
Для выявления скрытой автоматизации это по-прежнему полезно, но именно в случае заявленного агента сигнал слабее, чем в классическом обнаружении ботов: агент и не пытается выглядеть человеком, поэтому поведенческая оценка, настроенная отмечать «слишком чисто для человека», отметит его — и будет права — как нечеловеческий трафик, но не скажет, авторизован ли он. Поведенческие данные отвечают на вопрос «автоматизировано ли это», а не «желательна ли эта автоматизация». На второй вопрос отвечает описанный выше слой заявительных интерфейсов либо внеполосный сигнал авторизации.
Вопрос согласия
Проблему нельзя решить простым улучшением обнаружения ботов потому, что объект обнаружения сам по себе не враждебен. Хорошо оснащённый скрытый скрейпер и собственный шопинг-агент пользователя могут статистически выглядеть похоже по физике указателя и таймингу, но с аккаунтом, от имени которого они действуют, у них противоположные отношения: один крадёт доступ, у другого он есть по праву. Формулировка «блокировать или нет» упускает главное: случай агента — это скорее вопрос авторизации и аккуратности использования. Действительно ли владелец аккаунта просил об этом действии и ведёт ли себя агент прилично, оказавшись внутри: соблюдает ли лимиты запросов, не долбит ли эндпоинты.
Именно поэтому речь идёт не только о технике, но и о живой дискуссии о правилах: по мере роста агентского трафика операторы сайтов, разработчики браузеров и правозащитники до сих пор выясняют, где «авторизованный агент, действующий от имени пользователя» должен находиться относительно существующих правил, написанных для краулеров и скрейперов, — и в каких случаях его не следует приравнивать к неавторизованной автоматизации только потому, что и то и другое автоматизировано. Этот вопрос лежит выше того, что способна решить сама по себе любая система обнаружения.
Что это значит для вашего собственного браузера
Если вы пользуетесь расширением браузера, работающим как агент, или фреймворком автоматизации, который управляет вашими же залогиненными сессиями, это меняет то, что система обнаружения сайта видит именно о вашем трафике, а не о ботах вообще. Инструмент обнаружения ботов от BrowserInsight показывает для вашей текущей сессии тот же клиентский слой сигналов, о котором шла речь выше: состояние navigator.webdriver, артефакты headless-режима и CDP, а также сигналы согласованности отпечатка. Если вы запускаете агента или инструмент автоматизации, загляните на эту страницу и посмотрите, что она сообщает, — прежде чем считать, что ваша сессия выглядит как обычный человеческий визит.
Часто задаваемые вопросы
С точки зрения обнаружения, ИИ-агент в браузере — это то же самое, что бот?
Технически это автоматизированный трафик, как и бот. Разница — в авторизации и намерении: заявленный агент, действующий по явному запросу залогиненного пользователя, не является той «нежелательной автоматизацией», ради остановки которой существует обнаружение ботов, хотя многие из тех же клиентских сигналов к нему применимы. Сайты пока учатся оценивать это различие, а не сводить всё обратно к «автоматизация = плохо».
Может ли сайт отличить ИИ-агента от человека только по используемому браузеру?
Уже не так надёжно, как раньше. Агент может управлять настоящим, не headless-браузером с реальным рендерингом на базе GPU, что сводит на нет классические headless-признаки. Поведенческие сигналы — тайминг, движение, согласованность на протяжении всей сессии — по-прежнему разделяют автоматизированные и человеческие сессии, но сами по себе не скажут, авторизована ли эта автоматизация.
Позволяет ли инструментарий Chrome для агентов обнаруживать агентский трафик?
Нет: как описано в июньском посте Chrome 2026 года, этот инструментарий (WebMCP, категория аудита Lighthouse Agentic Browsing и поддержка DevTools для симуляции шагов агента) нацелен на то, чтобы упростить агентам работу со страницами, а не дать серверам способ идентифицировать или аутентифицировать агентские запросы. Это инструментарий про доступность и структуру, а не механизм обнаружения.
Если проверки на headless и CDP больше не доказывают, что перед нами бот, полезны ли они всё ещё?
Да, просто вывод из них теперь более узкий. Они по-прежнему надёжно показывают, что браузерной сессией управляют программно. Чего они сами по себе больше не скажут — нежелательна ли такая автоматизация: и агент, действующий от имени своего пользователя, и скрейпер, работающий вопреки воле сайта, могут оставить одни и те же артефакты CDP.
