Что такое Web Bot Auth
Web Bot Auth - это название рабочей группы IETF и ее работы в формате Internet-Draft по аутентификации автоматизированного веб-трафика. Идея проста: краулеры, AI-ассистенты и автономные агенты подписывают свои HTTP-запросы с помощью HTTP Message Signatures (RFC 9421), а затем публикуют публичные ключи, которые проверяют эти подписи, под контролируемым ими идентификатором. После этого сайт может подтвердить, что запрос действительно пришел от указанного оператора, а не полагаться на строку user-agent, которую может скопировать любой. О том, что это означает для продуктовой команды, см. Web Bot Auth для продуктовых команд; о шагах реализации см. руководство как проверять подписанные запросы AI-агентов.
По состоянию на ноябрь 2026 года основной документ рабочей группы - это draft-ietf-webbotauth-httpsig-protocol, который определяет заголовок Signature-Agent для обнаружения ключа в потоке запроса, формат каталога ключей на основе JSON Web Key Sets и well-known URI, по которому этот каталог доступен. На странице документов рабочей группы он перечислен вместе с связанными индивидуальными draft'ами. Это Internet-Draft'ы, то есть документы в работе. Такие детали, как способ обнаружения ключей, компоненты запроса, которые обязательно должны быть подписаны, и заголовки, передающие информацию об операторе, могут меняться от версии к версии. Реализаторам следует ориентироваться на текущие draft'ы, а не на какой-либо отдельный снимок.
Почему это важно
Сайты и API давно определяют ботов по строкам user-agent и диапазонам IP-адресов. У обоих подходов есть ограничения: строки user-agent подделать тривиально просто (см. подделку user-agent), а диапазоны IP-адресов меняются и используются совместно через облачных провайдеров. По мере того как AI-агенты начинают просматривать сайты, вызывать API и использовать MCP servers от имени людей, приложениям нужен более надежный способ отличать согласованно действующих автоматизированных клиентов от анонимных.
Подписанные запросы дают такую более надежную основу. Проверенная подпись позволяет приложению последовательно распознавать известного оператора, давать ему структурированный путь вместо интерфейса, ориентированного на человека, и точно измерять его активность.
Как это работает на высоком уровне
- Оператор генерирует пару ключей и публикует публичный ключ в месте, связанном с его идентичностью, обычно по well-known пути
http-message-signatures-directoryв своем домене. - Каждый запрос включает заголовки
Signature-InputиSignature, которые охватывают выбранные компоненты запроса, а также идентификатор ключа и заголовокSignature-Agent, указывающий на каталог ключей. - Принимающий сайт получает опубликованные ключи оператора или берет их из кэша, восстанавливает базу подписи и проверяет подпись.
- При успешной проверке сайт знает, что запрос был создан владельцем этого ключа, связанным с опубликованным идентификатором.
Что это подтверждает, а что нет
Подпись Web Bot Auth аутентифицирует автоматизированного клиента. Она не отвечает на вопросы:
- разрешено ли оператору делать то, что он запрашивает (agent authorization),
- дал ли человек указание или одобрил действие (delegated authority),
- безопасно ли действие или будет ли корректно использован возвращаемый контент.
Все это остается решением собственной аутентификации, авторизации и политики принимающего приложения. Наш пост в блоге что доказывают подписанные запросы AI-агентов и чего они не доказывают подробнее разбирает эту границу.
Распространенные заблуждения
- "Скоро каждый бот будет подписывать запросы." Распространение идет клиент за клиентом. Приложения долго будут видеть смесь подписанного, объявленного и анонимного трафика, поэтому им нужен понятный способ обработки каждого из них.
- "Подпись делает бота хорошим." Она делает бота известным. Известность - это отправная точка для политики, а не сама политика.
- "Draft уже окончательный." Это развивающийся Internet-Draft. Стройте решение на основе текущего текста и ожидайте изменений.
Как Proof of Actor связан с этим
Proof of Actor рассматривает проверенную подпись как доказательство с основанием Verified, ограниченное ключом и идентификатором, которые она подтверждает. Он отделяет это от объявленных имен и выводимых сигналов и никогда не превращает идентичность в разрешение. Proof of Actor предназначен для проверки подписанных запросов по мере развития этих стандартов; ваши собственные политики в Route определяют, что может делать проверенный агент.
Посмотрите, как это вписывается в APIs и MCP servers, или подайте заявку на ранний доступ.
Источники
- рабочая группа IETF Web Bot Auth: устав, сопредседатели и статус
- документы рабочей группы Web Bot Auth: текущие документы рабочей группы и связанные draft'ы
- draft-ietf-webbotauth-httpsig-protocol:
Signature-Agent, каталог ключей JWKS и его well-known URI (в работе по состоянию на ноябрь 2026 года) - RFC 9421: HTTP Message Signatures: стандарт подписи, на котором строится Web Bot Auth