ПОЯСНЕНИЕ

Web Bot Auth для продуктовых команд: что означают подписанные запросы агентов для вашего роадмапа

Агентам на базе AI и краулерам все чаще нужен способ подтверждать, кто они такие, не полагаясь на строку User-Agent, которую может скопировать кто угодно. Работа IETF Web Bot Auth - ведущая попытка стандартизировать это. Ниже - простое объяснение для продакт-менеджеров и руководителей инженерии: как это работает, что оно доказывает, каков статус на ноябрь 2026 года и как к этому подготовиться.

Получить ранний доступ Изучить, как это работает

Автор Toshendra SharmaОснователь и CEO, AgentCredia · Updated November 13, 2026

Краткий ответ

Web Bot Auth - это работа IETF над тем, чтобы автоматизированные клиенты, включая AI-агентов, могли подписывать свои HTTP-запросы с помощью HTTP Message Signatures (RFC 9421) и публиковать ключи, чтобы сайты могли их проверять. Действительная подпись доказывает, какой ключ подписал запрос, но не то, что агенту разрешено действовать. На ноябрь 2026 года основная спецификация находится в виде Internet-Draft рабочей группы, поэтому продуктовым командам стоит готовиться использовать подписи как сильное доказательство, при этом продолжая обрабатывать неподписанный трафик.

Годами единственным способом, которым автоматизированный клиент мог сообщить сайту, кто он, была строка в заголовке User-Agent и, для нескольких крупных операторов, опубликованный список IP-адресов или обратная DNS-проверка. Имена легко копируются. Сетевые списки покрывают только тех операторов, которые их поддерживают. Когда AI-агенты начинают действовать от имени реальных людей в интернете, этот разрыв становится продуктовой проблемой, а не только проблемой безопасности.

Web Bot Auth - ведущая попытка закрыть этот разрыв. Она дает автоматизированным клиентам способ подписывать свои запросы ключом, которым они владеют и который публикуют, чтобы сайт мог проверять подпись вместо того, чтобы доверять имени. Это пояснение предназначено для продакт-менеджеров и руководителей инженерии, которым нужно понять, что это такое, что меняется и чего это не меняет, не читая спецификации от начала до конца.

Коротко

Что это: рабочая группа IETF, webbotauth, и подход, который она стандартизирует для аутентификации автоматизированных HTTP-клиентов.
Как это работает: клиент подписывает части каждого запроса с помощью HTTP Message Signatures (RFC 9421) и указывает каталог своих открытых ключей. Сайт получает ключ и проверяет подпись.
Что это доказывает: какой ключ подписал запрос и что подписанные части не были изменены в пути.
Что это не доказывает: что агенту разрешено делать то, о чем он просит, что он действует от имени конкретного пользователя или что он будет вести себя корректно.
Статус на ноябрь 2026 года: RFC 9421 - опубликованный Proposed Standard. Документ протокола Web Bot Auth - это Internet-Draft рабочей группы, пока еще не RFC.
Что делать: планируйте считать действительные подписи сильным доказательством, продолжайте обрабатывать неподписанный трафик и оставляйте решения об авторизации в своем коде.

Что такое работа IETF Web Bot Auth

IETF сформировала рабочую группу Web Bot Auth, чтобы стандартизировать методы криптографической аутентификации автоматизированных клиентов и дать веб-сайтам больше информации об операторах, стоящих за ними. В чартере особое внимание уделено сайтам, которые в основном обслуживают людей, и в область работы включен широкий набор клиентов: краулеры, веб-архиваторы, проверяющие ссылки, AI-краулеры для обучения и AI-агенты, действующие для конечных пользователей.

В чартере есть два исключения, важные для продуктовых команд. Аутентификация конечного пользователя не входит в область работы, поэтому это не способ входа человека в систему. Отслеживание репутации ботов тоже вне области работы, поэтому стандарт говорит, кто подписал запрос, а не заслуживает ли этот оператор доверия.

В чартере перечислены три типа результатов работы:

Документы стандартного трека о методах аутентификации автоматизированных клиентов для веб-сайтов, созданных для людей.
Документы стандартного трека о передаче дополнительной информации о запрашивающем боте с использованием существующего идентификатора, например доменного имени или URL.
Документы best current practice или информационные документы по операционным темам, таким как управление ключами, жизненный цикл и развертывание.

Состояние документов на ноябрь 2026 года

На ноябрь 2026 года у рабочей группы есть один принятый документ рабочей группы: draft-ietf-webbotauth-httpsig-protocol, под названием "HTTP Message Signatures for automated traffic", редакция 01, датированная 29 октября 2026 года. Это Internet-Draft, то есть документ в работе, который еще может измениться. Это не RFC.

Несколько отдельных черновиков также связаны с группой и находятся на обсуждении, включая предложения о реестре и формате agent card, об анонимной аутентификации ботов, о формате JSON для публикации диапазонов IP автоматизированных клиентов и о заголовке для подписанных метаданных агента. Отдельные черновики - это предложения; ни один из них на эту дату не был принят группой.

В чартере были установлены вехи на 2026 год для передачи спецификаций в IESG на утверждение. На ноябрь 2026 года протокольный документ все еще остается черновиком рабочей группы. Текущее состояние можно отслеживать на странице IETF datatracker для рабочей группы и в черновике протокола.

Как работают HTTP Message Signatures

Web Bot Auth опирается на RFC 9421, HTTP Message Signatures, опубликованный в феврале 2024 года как Proposed Standard. RFC 9421 - это общий механизм: он определяет, как подписывать выбранные части HTTP-сообщения и как передавать подпись в заголовках. Web Bot Auth профилирует его для автоматизированных клиентов.

Если говорить просто, подписанный запрос агента работает так:

Оператор создает пару ключей. Он хранит закрытый ключ в секрете и публикует открытый ключ.
Клиент выбирает, что подписывать. Он выбирает компоненты запроса, например целевой хост или URI и время создания. Текущий черновик требует покрывать authority или целевой URI, чтобы подпись для одного сайта нельзя было просто воспроизвести для другого.
Клиент подписывает и отправляет. Запрос несет заголовок Signature-Input, описывающий, что было подписано и каким ключом, а также заголовок Signature со значением подписи. В черновике используется тег web-bot-auth и для каждой подписи ожидаются время создания и срок действия.
Сайт проверяет. Он находит открытый ключ, восстанавливает подписанные компоненты из полученного запроса и проверяет подпись. Если проверка проходит, запрос был подписан владельцем этого ключа и покрытые части не были изменены.

Черновик также позволяет сайту запросить подпись. Источник может отправить заголовок Accept-Signature, обычно вместе с отказом, чтобы сообщить, что он хочет получать подписанные запросы.

Идея каталога ключей

Подпись полезна только если сайт может найти правильный открытый ключ. Web Bot Auth решает это с помощью каталога ключей.

В текущем черновике рабочей группы клиент добавляет заголовок Signature-Agent, содержащий HTTPS URL. По этому URL доступен каталог открытых ключей оператора в виде JSON Web Key Set. Сайт получает каталог, выбирает ключ, который соответствует идентификатору ключа в подписи, и выполняет проверку. Черновик также определяет хорошо известный путь /.well-known/http-message-signatures-directory, по которому оператор может обслуживать свой каталог.

Полезная для продуктовых команд идея состоит в том, что URL становится идентификатором. Оператор агента определяется тем, где он публикует свои ключи, а это связывает подпись с доменом, которым оператор управляет. Ротация ключей работает так: публикуется новый ключ вместе со старым, а затем старый удаляется.

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

Что доказывает действительная подпись, а что нет

Это самый важный раздел для всех, кто пишет продуктовую политику.

Действительная подпись доказывает:

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

Действительная подпись не доказывает:

Что агент authorized выполнять действие. Идентифицируемость не равна разрешению. См. agent authorization.
Что агент действует от имени конкретного человека или в пределах полномочий, которые этот человек ему дал. См. delegated authority.
Что оператор заслуживает доверия или что агент будет вести себя правильно. Репутация прямо вне области работы рабочей группы.
Что-либо о неподписанных запросах. Неподписанный трафик по-прежнему нужно обрабатывать отдельно.

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

Что должны делать продуктовые команды

Вам не нужно ждать RFC, чтобы начать планировать. Подписанный трафик от агентов - это то, к чему можно готовиться уже сейчас, с учетом того, что некоторые детали черновика могут измениться.

1. Сначала измеряйте, потом решайте

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

2. Отделяйте доказательства от политики

Фиксируйте то, что говорит evidence, verified, declared, inferred или unknown, отдельно от того, что вы решаете делать. Так политики остаются читаемыми, и их можно ужесточать или ослаблять без повторной настройки инструментирования. Статья evidence basis объясняет четыре уровня.

3. Дайте verified-агентам лучший путь

Там, где это уместно, отдавайте verified-агентам структурированный контент или поток, удобный для агента, вместо страниц, сделанных для людей. В руководстве подача AI-агентам структурированного контента описаны соответствующие шаблоны.

4. Оставьте авторизацию в своем коде

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

5. Планируйте неподписанный и Unknown-трафик

Поддержка подписей у агентов и инструментов различается, поэтому некоторое время будет смесь подписанных и неподписанных запросов. Для каждого route отдельно решайте, что происходит с declared, inferred и Unknown-трафиком, вместо того чтобы выбирать одно общее правило для всего сайта. Руководство обработка Unknown-трафика показывает, как это делать.

Как Proof of Actor использует Web Bot Auth

Proof of Actor показывает вашему приложению, кто или что действует в каждой интеракции: Human, Human + AI, Agent или Unknown, и указывает основание evidence. Подписи Web Bot Auth - один из самых сильных источников доказательств.

Когда агент подписывает свой запрос с помощью HTTP Message Signatures, Proof of Actor проверяет подпись по опубликованному ключу оператора. Если проверка проходит, результат получает основание verified, а вместе с ним и evidence, который ваша команда может изучить. Если клиент лишь заявляет о себе в заголовке, результат - declared. Если вывод основан на поведенческих или контекстных сигналах, он помечается как inferred. Если доказательств недостаточно, результат - Unknown.

Ваше приложение само решает, что делать с этим контекстом. Политики задаются по route, по классу актера и по основанию, с такими результатами, как allow, adapt, challenge, review и rate-limit. По умолчанию ничего не enforced: вы сначала preview политики на реальном трафике, а затем enforce их по route, в своем коде.

Founding-команды могут собирать evidence через middleware для Node.js, Next.js, edge-интеграцию, browser collector на одобренных страницах, общий HTTP API или интеграцию с MCP server. См. интеграции, а также руководство проверка подписанных запросов агента для практических шагов.

Proof of Actor следует тому же ограничению, что и стандарт: verified-подпись говорит, какой ключ подписал запрос, но не означает, что агент authorized. Авторизация остается на вашей стороне. Страница evidence and limits точно описывает, что может и чего не может поддержать каждый результат.

Начать работу

Proof of Actor находится в private beta. Отобранные founding developer teams могут получить до 12 месяцев бесплатного доступа в рамках согласованных лимитов использования, без автоматического биллинга. Подать заявку на ранний доступ и расскажите, какие route, по вашему ожиданию, будут использовать подписанные агенты и что вы хотите с ними делать.

ДЛЯ РАЗРАБОТЧИКОВ

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent или Unknown.
basis: Насколько сильны evidence: verified, declared, inferred или unknown.
evidence: Signals, стоящие за result, чтобы ваша team видела, почему.

Начните в observation mode: записывайте results рядом с вашими logs и ничего не меняйте, пока не выберете policy. Прочитать guide по интеграции Node.js

Часто задаваемые вопросы

Что такое Web Bot Auth?

Web Bot Auth - это название рабочей группы IETF, webbotauth, и подхода, который она стандартизирует: автоматизированные клиенты подписывают HTTP-запросы с помощью HTTP Message Signatures (RFC 9421) и публикуют свои открытые ключи, чтобы веб-сайты могли проверить, какой оператор отправил запрос.

Web Bot Auth - это уже завершенный стандарт?

Пока нет. На ноябрь 2026 года основной протокольный документ, draft-ietf-webbotauth-httpsig-protocol, остается Internet-Draft рабочей группы в редакции 01. RFC 9421, формат подписи, на котором он основан, уже опубликован как Proposed Standard.

Означает ли действительная подпись Web Bot Auth, что агенту разрешено действовать?

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

Нужно ли продуктовым командам самим реализовывать Web Bot Auth?

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

Что делать с агентами, которые не подписывают свои запросы?

Обрабатывайте их в соответствии с доступными доказательствами: declared, inferred или Unknown. Ожидайте, что некоторое время будет смесь подписанного и неподписанного трафика, и задайте запасной вариант для каждого route, а не один общий правило для всего сайта.

Как Proof of Actor использует Web Bot Auth?

Он проверяет HTTP Message Signatures по опубликованному ключу и, если проверка проходит, показывает результат с основанием verified. Затем ваши политики могут относиться к verified-агентам иначе, чем к declared или Unknown-трафику.

Знайте, кто использует ваш app.

Private beta для небольшой группы founding developers.

Получить ранний доступ Просмотреть цены

Предпочитаете сначала поговорить? Свяжитесь с основателями