Что такое Web Bot Auth: аутентификация AI-ботов

Обновлено 4 августа 2026 года

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

Web Bot Auth не решает все задачи безопасности. Успешная проверка подписи не означает, что агенту автоматически разрешено получить контент, оформить заказ, вызвать API, снять ограничение скорости или выполнить действие от имени пользователя.

Главная формула статьи:

Подтверждённая личность агента не равна разрешённому действию: verified ≠ allowed.

По данным Cloudflare Radar, на момент проверки 4 августа 2026 года автоматизированные клиенты генерировали около 58,7% HTTP-запросов к HTML-контенту, а люди — 41,3%. Показатель динамический, но он хорошо иллюстрирует масштаб задачи: автоматический веб-трафик уже нельзя считать второстепенным исключением.

Кратко о главном

• Web Bot Auth предназначен для криптографической аутентификации ботов и AI-агентов, обращающихся к веб-сайтам.
• В основе механизма лежат HTTP Message Signatures из RFC 9421.
• Агент подписывает выбранные компоненты HTTP-запроса приватным ключом.
• Signature-Input описывает покрытые компоненты и параметры подписи.
• Signature содержит криптографическую подпись.
• Signature-Agent помогает серверу обнаружить публичный ключ.
• created, expires и nonce ограничивают срок действия подписи и помогают защищаться от повторной отправки запросов.
• Публичные ключи могут публиковаться через каталог JWKS, jwks_uri или Signature Agent Card.
• IP-списки не исчезают: актуальный registry draft предусматривает ips_uri как дополнительный сигнал.
• Web Bot Auth не подтверждает репутацию, намерения, пользовательское согласие или право на использование контента.
• В IETF обсуждается и альтернативная модель — анонимная аутентификация ботов без раскрытия точной личности каждого клиента.
• По состоянию на 4 августа 2026 года основные документы Web Bot Auth остаются индивидуальными Internet-Draft, а не принятыми рабочей группой документами draft-ietf-webbotauth-* и не опубликованными RFC.

Мини-глоссарий

Содержание

1. Зачем нужен Web Bot Auth
2. Статус спецификации
3. Как работает Web Bot Auth
4. Заголовки Web Bot Auth
5. Signature Agent Card и обнаружение ключей
6. Как проверить подписанный запрос
7. Алгоритмы подписи
8. Что доказывает Web Bot Auth
9. Чего Web Bot Auth не доказывает
10. Аутентификация и авторизация
11. Replay-защита и синхронизация времени
12. POST-запросы и Content-Digest
13. Reverse proxy и многоуровневая подпись
14. Robots.txt и правила использования контента
15. Ответы на неподписанные и невалидные запросы
16. Сравнение с другими механизмами
17. Кто использует Web Bot Auth
18. Приватность, критика и альтернативы
19. Как протестировать Web Bot Auth
20. Как измерять внедрение
21. Как AgentBouncer дополняет Web Bot Auth
22. Чек-лист внедрения
23. Распространённые ошибки
24. Часто задаваемые вопросы
25. История обновлений

<a id="why-web-bot-auth"></a>

Зачем нужен Web Bot Auth

Исторически сайты распознавали автоматический трафик по трём основным сигналам:

Например, любой HTTP-клиент может отправить:

User-Agent: Googlebot

Само по себе это не доказывает, что запрос действительно принадлежит Google.

IP-списки надёжнее простого User-Agent, однако они тоже не дают универсальной идентичности:

• адреса меняются;
• облачные IP используются разными клиентами;
• агент может работать через браузерную платформу или прокси;
• репутация IP не всегда соответствует репутации конкретного приложения;
• публикация и синхронизация диапазонов усложняют эксплуатацию;
• компрометация разрешённой инфраструктуры превращает доверенный IP в источник риска.

Web Bot Auth добавляет криптографический сигнал. Агент создаёт подпись приватным ключом, а сайт проверяет её с помощью соответствующего открытого ключа.

При этом IP-адреса не объявляются устаревшими. Актуальный draft-meunier-webbotauth-registry-03 предусматривает поле ips_uri, с помощью которого оператор может опубликовать список адресов агента. Более точная модель выглядит так: подпись становится основным криптографическим доказательством, а IP, User-Agent, reverse DNS и поведение остаются дополнительными сигналами политики.

<a id="specification-status"></a>

Статус спецификации Web Bot Auth

По состоянию на 4 августа 2026 года рабочая группа IETF Web Bot Auth активна. Однако основные технические документы всё ещё имеют статус individual Internet-Draft.

Это означает, что они:

• не являются RFC;
• не представляют окончательный консенсус IETF;
• не имеют формального статуса стандарта;
• могут быть обновлены, заменены или отозваны;
• пока не были приняты рабочей группой как документы с именами draft-ietf-webbotauth-*.

Актуальные документы

draft-meunier-webbotauth-httpsig-protocol-00 заменил предыдущую архитектурную серию draft-meunier-web-bot-auth-architecture. Новый directory draft аналогично заменил прежний draft-meunier-http-message-signatures-directory.

Важно

Internet-Draft следует цитировать только как work in progress. Реализация должна фиксировать конкретную редакцию протокола и иметь план обновления при несовместимых изменениях.

План рабочей группы

В чартере Web Bot Auth перечислены следующие ориентиры:

• апрель 2026 года — отправка в IESG standards-track документов по методам аутентификации;
• апрель 2026 года — отправка документов по передаче дополнительной информации о ботах;
• август 2026 года — отправка operational BCP в IESG.

Эти даты являются плановыми milestones, а не подтверждением публикации стандарта. На 4 августа 2026 года основные рассматриваемые документы всё ещё отображаются в Datatracker как индивидуальные черновики.

Область применения

Чартер рабочей группы ориентирован на автоматических клиентов, которые обращаются к сайтам, предназначенным прежде всего для людей:

• поисковые краулеры;
• веб-архиваторы;
• link checkers и валидаторы;
• краулеры для AI training;
• AI-агенты, получающие или изменяющие веб-контент от имени пользователя.

Вне формального scope находятся:

• HTTP API, предназначенные только для машин;
• agent-to-agent interfaces;
• аутентификация конечного пользователя;
• протоколы, отличные от HTTP;
• неcryptографическая идентификация;
• присвоение репутации конкретным ботам;
• универсальная модель авторизации.

При этом draft-nottingham-webbotauth-use-cases-02 показывает, что границы и цели направления всё ещё обсуждаются. В документе отдельно рассматриваются спорные сценарии, потенциальная централизация и изменение баланса сил между сайтами и автоматическими клиентами. Поэтому scope нельзя считать окончательно закрытым до появления принятых документов рабочей группы.

<a id="how-web-bot-auth-works"></a>

Как работает Web Bot Auth

Упрощённый процесс состоит из семи этапов.

1. Оператор создаёт пару ключей

Агент получает:

• приватный ключ для подписания;
• публичный ключ для проверки.

Приватный ключ не должен покидать защищённое окружение агента. Его следует хранить в secret manager, KMS или HSM.

2. Публичный ключ публикуется

Оператор может использовать:

• HTTP Message Signatures Directory;
• прямой jwks_uri;
• Client ID Metadata Document;
• Signature Agent Card;
• предварительно согласованный каталог;
• другой поддерживаемый механизм обнаружения.

3. Агент создаёт HTTP-запрос

GET /products/coffee-machine HTTP/1.1
Host: shop.example.com
User-Agent: ExampleShoppingAgent/1.0

4. Агент выбирает покрытые компоненты

Редакция draft-meunier-webbotauth-httpsig-protocol-00 требует включить как минимум один из двух derived components:

• @authority;
• @target-uri.

Если запрос содержит Signature-Agent, соответствующий member этого словаря также должен быть подписан.

5. Агент создаёт подпись

В параметры подписи включаются:

• created;
• expires;
• keyid;
• tag="web-bot-auth";
• при необходимости nonce;
• список покрытых компонентов.

6. Сайт обнаруживает открытый ключ

Проверяющая сторона получает ключ, находит его по keyid и применяет правила кеширования, ротации и отзыва.

7. Сайт проверяет подпись и применяет политику

Криптографический результат может выглядеть так:

{
  "verified": true,
  "agent": "https://agent.example.com/bot",
  "keyId": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw"
}

Затем выполняется отдельная проверка политики:

{
  "allowed": false,
  "reason": "agent_not_allowed_for_checkout"
}

<a id="web-bot-auth-headers"></a>

Какие заголовки использует Web Bot Auth

Основными являются:

• Signature-Input;
• Signature;
• опциональный, но рекомендуемый Signature-Agent.

Отдельный развивающийся draft определяет Signature-Key как более общий composable-механизм обнаружения ключей. Текущий Web Bot Auth protocol использует Signature-Agent по умолчанию, но допускает другие deployment-модели.

Пример подписанного запроса:

GET /products/coffee-machine HTTP/1.1
Host: shop.example.com
User-Agent: ExampleShoppingAgent/1.0
Signature-Agent: sig1="https://agent.example.com"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1785859200;expires=1785859260;keyid="NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw";nonce="RANDOM_BASE64URL_VALUE";tag="web-bot-auth"
Signature: sig1=:BASE64_SIGNATURE:

В примерах статьи значения HTTP-заголовков иногда визуально сокращены. В реальном запросе каждое field value передаётся в допустимом HTTP-формате без устаревшего line folding.

Signature-Agent

В актуальном directory draft Signature-Agent является Structured Field Dictionary:

Signature-Agent: sig1="https://agent.example.com"

sig1 связывает запись с подписью того же label. Для разбора Structured Fields нужно использовать RFC 9651, который заменил RFC 8941.

Поддерживаются типизированные варианты обнаружения:

Signature-Agent: sig1="https://agent.example.com/jwks.json";type=jwks_uri

Signature-Agent: sig1="https://agent.example.com/bot";type=cimd

При отсутствии type значение интерпретируется как origin для стандартного directory-механизма.

Signature-Input

Signature-Input определяет:

• label подписи;
• покрытые компоненты;
• время создания;
• время истечения;
• идентификатор ключа;
• nonce;
• назначение подписи;
• при необходимости алгоритм.

Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1785859200;expires=1785859260;keyid="NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw";nonce="RANDOM_BASE64URL_VALUE";tag="web-bot-auth"

tag="web-bot-auth" связывает подпись с конкретным application profile. Он не доказывает репутацию агента, но предотвращает использование подписи из другого контекста без явного решения проверяющей стороны.

Signature

Signature содержит результат криптографической операции:

Signature: sig1=:BASE64_SIGNATURE:

Label sig1 должен соответствовать записи в Signature-Input.

Несовместимость редакций

Реальные внедрения могут поддерживать более ранние варианты draft. Например, документация Cloudflare на 1 июля 2026 года всё ещё описывает legacy string form:

Signature-Agent: "https://signature-agent.test"

и предупреждает, что dictionary form из более новых drafts может не пройти проверку в их текущей реализации. Поэтому интеграция должна фиксировать не только название «Web Bot Auth», но и поддерживаемую редакцию синтаксиса у конкретного CDN, WAF или origin verifier.

<a id="signature-agent-card"></a>

Signature Agent Card и обнаружение публичных ключей

RFC 9421 описывает создание и проверку HTTP Message Signatures, но не задаёт единую инфраструктуру доверия и обнаружения ключей.

Web Bot Auth дополняет эту модель каталогами и метаданными.

HTTP Message Signatures Directory

Типовой каталог размещается по well-known URL:

https://agent.example.com/.well-known/http-message-signatures-directory

Он возвращает JWK Set:

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
      "x": "PUBLIC_KEY_VALUE",
      "use": "sig",
      "nbf": 1785772800,
      "exp": 1788364800
    }
  ]
}

keyid в Signature-Input должен быть base64url-кодированным SHA-256 JWK Thumbprint. Для RSA и EC применяются правила RFC 7638, а для Ed25519 draft ссылается на представление OKP.

Signature Agent Card

draft-meunier-webbotauth-registry-03 определяет Signature Agent Card как JSON-документ метаданных. Он использует параметры из реестра OAuth Dynamic Client Registration и добавляет объект web_bot_auth.

Пример:

{
  "client_id": "https://agent.example.com/bot",
  "client_name": "Example Bot",
  "client_uri": "https://agent.example.com/about",
  "contacts": [
    "mailto:bot-support@example.com"
  ],
  "jwks_uri": "https://agent.example.com/.well-known/http-message-signatures-directory",
  "web_bot_auth": {
    "expected-user-agent": "ExampleBot/1.0",
    "rfc9309-product-token": "ExampleBot",
    "purpose": "search",
    "rate-expectation": "avg=10rps;max=100rps",
    "ips_uri": "https://agent.example.com/ips.json"
  }
}

Практически важные правила редакции registry-03:

• при разрешении карточки через client_id поле client_id обязательно;
• client_id должен быть HTTPS URL;
• ответ должен иметь статус 200 OK;
• verifier не должен автоматически переходить по redirect;
• возвращённый client_id должен точно совпадать с запрошенным URL;
• jwks и jwks_uri взаимоисключающие;
• jwks_uri должен использовать HTTPS;
• ресурс по jwks_uri рекомендуется подписывать HTTP Message Signatures;
• для JWK Set по jwks_uri не установлен обязательный media type;
• ips_uri позволяет опубликовать дополнительный список IP-адресов;
• Signature-Key рассматривается как потенциальный composable carrier, но соответствующая схема пока не определяется этим draft. (datatracker.ietf.org)

Карточка опирается на концепцию Client ID Metadata Document. Актуальной на 4 августа 2026 года является редакция draft-ietf-oauth-client-id-metadata-document-02 от 6 июля 2026 года, а не мартовская -01.

Безопасность загрузчика

Нельзя без ограничений загружать любой URL из входящего запроса. Иначе key discovery становится SSRF-вектором.

Production verifier должен:

• разрешать только HTTPS;
• запрещать loopback, link-local и private network addresses;
• не следовать redirect там, где draft их запрещает;
• повторно проверять DNS и IP перед соединением;
• применять короткие timeouts;
• ограничивать размер ответа;
• валидировать JSON и JWK;
• отклонять приватные JWK-параметры;
• применять allowlist алгоритмов;
• ограничивать число запросов к неизвестным каталогам;
• кешировать успешные результаты;
• аккуратно применять negative caching;
• не предоставлять доверенный доступ, пока обнаружение ключа не завершено.

Требование конкретного media type зависит от выбранного discovery-механизма и реализации. Для jwks_uri registry draft прямо отмечает, что RFC 7591 не требует определённого media type.

<a id="verify-signed-request"></a>

Как проверить подписанный запрос

Рекомендуемый pipeline:

1. Получить исходный HTTP-запрос.
2. Найти Signature и Signature-Input.
3. Выбрать поддерживаемый signature label.
4. Корректно разобрать Structured Fields.
5. Проверить tag="web-bot-auth".
6. Проверить обязательные покрытые компоненты.
7. Проверить created и expires.
8. Проверить допустимую продолжительность окна.
9. Проверить nonce, если он обязателен по локальной политике.
10. Определить механизм key discovery.
11. Безопасно получить и провалидировать публичный ключ.
12. Убедиться, что keyid соответствует JWK Thumbprint.
13. Восстановить signature base по RFC 9421.
14. Проверить криптографическую подпись.
15. Проверить replay cache.
16. Определить личность или класс агента.
17. Применить rate limits, правила контента и access policy.
18. Разрешить, ограничить, запросить дополнительное подтверждение или отклонить запрос.

Результаты криптографической проверки и политики должны храниться отдельно:

{
  "verified": true,
  "identity": "https://agent.example.com/bot",
  "keyId": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
  "signatureAgeMs": 412,
  "replay": "not_detected",
  "allowed": false,
  "reason": "path_not_allowed_for_agent"
}

<a id="signature-algorithms"></a>

Какие алгоритмы подписи использовать

RFC 9421 зарегистрировал несколько алгоритмов, включая:

• ed25519;
• ecdsa-p256-sha256;
• ecdsa-p384-sha384;
• rsa-pss-sha512;
• rsa-v1_5-sha256;
• hmac-sha256.

Для открытой Web Bot Auth-экосистемы shared-secret алгоритмы вроде HMAC обычно не подходят: сайтам пришлось бы заранее обмениваться секретом с каждым оператором.

Практический выбор для новых внедрений — Ed25519, если его поддерживают все участники цепочки:

• компактные ключи и подписи;
• удобная работа с JWK;
• хорошая производительность;
• поддержка в тестовых векторах protocol draft;
• текущая поддержка в Cloudflare Web Bot Auth.

RSA-PSS может потребоваться для совместимости с существующей PKI или инфраструктурой. ECDSA P-256 остаётся распространённым вариантом, однако проверяющая сторона должна убедиться, что используемая библиотека корректно обрабатывает формат подписи и не допускает алгоритмическую неоднозначность.

Verifier должен использовать явный allowlist:

ed25519
rsa-pss-sha512
ecdsa-p256-sha256

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

<a id="what-web-bot-auth-proves"></a>

Что доказывает Web Bot Auth

При корректной реализации валидная подпись подтверждает следующее.

Владение приватным ключом

Запрос подписан стороной, которая контролирует приватный ключ, соответствующий открытому ключу.

Целостность покрытых компонентов

Если компонент включён в signature base, его изменение приведёт к ошибке проверки.

Например:

• @authority привязывает подпись к HTTP authority;
• @target-uri защищает полный target URI;
• @method защищает метод;
• @path защищает путь;
• content-digest связывает подпись с байтами тела запроса.

Назначение подписи

tag="web-bot-auth" указывает, что подпись была создана для профиля Web Bot Auth.

Ограниченный срок действия

created и expires позволяют отвергать слишком старые, будущие или истёкшие подписи.

Связь с опубликованным идентификатором

Если обнаружение ключа и проверка каталога выполнены правильно, запрос можно связать с определённым client_id, origin или другим идентификатором агента.

Сила этой связи зависит не только от математики подписи, но и от способа обнаружения ключей, контроля домена, политики реестра и защищённости приватного ключа.

<a id="what-web-bot-auth-does-not-prove"></a>

Чего Web Bot Auth не доказывает

Web Bot Auth не подтверждает автоматически, что:

• агент безопасен или заслуживает доверия;
• оператор соблюдает robots.txt;
• запрос соответствует заявленной цели;
• пользователь аутентифицирован;
• пользователь разрешил конкретное действие;
• агент имеет право использовать контент для обучения;
• AI-модель не подверглась prompt injection;
• подписывающий ключ не был украден;
• запрос не является replay;
• сайту следует снять CAPTCHA или повысить rate limit;
• агенту разрешено работать с конкретным аккаунтом.

Более точная модель решения:

<a id="authentication-and-authorization"></a>

Аутентификация агента и авторизация доступа

Web Bot Auth отвечает прежде всего на вопрос:

Какой автоматический клиент контролирует ключ, подписавший этот запрос?

Он не отвечает на вопросы:

• какой пользователь управляет агентом;
• какие разрешения предоставил пользователь;
• можно ли выполнить операцию;
• требуется ли подтверждение;
• разрешены ли конкретные параметры.

Пример: просмотр каталога

Пример: чтение заказов

Пример: дорогая покупка

Для пользовательских операций могут дополнительно потребоваться:

• OAuth access token;
• cookie или session credential;
• passkey;
• consent record;
• transaction confirmation;
• spending limits;
• risk evaluation;
• policy engine.

Подробнее: «Аутентификация и авторизация AI-агентов: в чём разница».

<a id="replay-and-clock-skew"></a>

Replay-защита, nonce и синхронизация времени

Цифровая подпись не делает запрос одноразовым. Перехваченный валидный запрос можно попытаться отправить повторно.

Особенно опасны операции с побочным эффектом:

• отправка формы;
• создание заказа;
• изменение данных;
• бронирование;
• платёж;
• вызов инструмента;
• выдача временного секрета.

created и expires

Protocol draft требует created и expires и рекомендует срок действия не более 24 часов. Для чувствительных действий это слишком широкое окно: production-профиль обычно должен использовать минуты или секунды.

Signature-Input: sig1=("@authority");created=1785859200;expires=1785859260;keyid="...";tag="web-bot-auth"

В этом примере подпись действует 60 секунд.

nonce

Protocol draft рекомендует base64url-кодированный случайный массив длиной 64 байта. Клиент должен обеспечивать уникальность nonce в пределах окна подписи. Проверяющая сторона самостоятельно решает, насколько строгой будет серверная проверка.

Clock skew

Слишком короткое окно повышает чувствительность к рассинхронизации часов.

Рекомендуемая operational-модель:

• синхронизировать серверы и подписывающие узлы через NTP;
• отклонять created, находящийся заметно в будущем;
• определить небольшой допустимый clock skew;
• отдельно логировать future_created, expired и window_too_long;
• не расширять окно автоматически при ошибках синхронизации;
• использовать более строгие настройки для действий с побочным эффектом.

Например, сайт может разрешить до 30 секунд расхождения и окно подписи до 120 секунд. Это локальная политика, а не универсальное требование Web Bot Auth. Draft прямо отмечает компромисс: короткие сроки снижают replay-риск, но повышают чувствительность к clock skew.

Replay cache

Fingerprint может включать:

• keyid;
• label подписи;
• значение Signature;
• nonce;
• @authority;
• @target-uri;
• expires.

Повторное появление fingerprint отклоняется:

{
  "verified": false,
  "allowed": false,
  "reason": "replay_detected"
}

Rate limiting не заменяет replay protection. Он ограничивает объём трафика, но может пропустить повторную транзакцию внутри разрешённого лимита.

<a id="content-digest"></a>

Подпись POST-запросов и Content-Digest

Минимальный Web Bot Auth profile не требует всегда подписывать method, path или body. Для транзакционных запросов минимального набора недостаточно.

POST /checkout HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{
  "productId": "product-42",
  "quantity": 1
}

Если подпись покрывает только @authority, она не защищает:

• HTTP method;
• path;
• идентификатор продукта;
• количество;
• остальные поля JSON.

Для чувствительного запроса нужен более строгий application profile:

POST /checkout HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Content-Digest: sha-256=:BODY_DIGEST:
Signature-Agent: sig1="https://agent.example.com"
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest" "signature-agent";key="sig1");created=1785859200;expires=1785859260;keyid="NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw";nonce="RANDOM_BASE64URL_VALUE";tag="web-bot-auth"
Signature: sig1=:BASE64_SIGNATURE:

Content-Digest из RFC 9530 связывает запрос с точными байтами body.

Правильный порядок:

1. Получить raw body.
2. Вычислить digest.
3. Сравнить его с Content-Digest.
4. Проверить HTTP Message Signature.
5. Проверить replay cache.
6. Применить authorization policy.
7. Разобрать JSON.
8. Выполнить действие.

Если приложение сначала вызывает JSON.parse(), а затем повторно сериализует объект, полученные байты могут отличаться от подписанных.

Расширенный набор @method, @authority, @path и content-digest является безопасным application profile для транзакций, а не минимальным требованием текущего Web Bot Auth draft.

<a id="reverse-proxy"></a>

Web Bot Auth, reverse proxy и многоуровневая подпись

В production запрос часто проходит через несколько компонентов:

• CDN;
• WAF;
• load balancer;
• reverse proxy;
• application server.

Подпись можно проверять на edge. Это позволяет централизовать:

• key discovery;
• кеширование;
• replay protection;
• bot classification;
• rate limiting;
• базовую policy evaluation.

Изменение подписанных компонентов

Промежуточный узел может изменить:

• Host;
• scheme;
• path;
• query;
• формат заголовков;
• внешний URL.

Verifier должен восстанавливать именно тот request context, который подписал агент. Нельзя незаметно подменить внешний https://shop.example.com/path внутренним http://service:8080/path.

Доверие к результату edge-проверки

Нельзя доверять внешнему заголовку:

X-Agent-Verified: true

Edge должен:

1. удалить входящие assertion-заголовки;
2. проверить подпись;
3. добавить собственный внутренний assertion;
4. передать его по аутентифицированному каналу;
5. ограничить доступ к backend только доверенной инфраструктурой.

Многоуровневая подпись

Рассмотрим цепочку:

1. Пользователь запускает браузерного агента.
2. Агент работает через облачную browser platform.
3. Платформа отправляет запрос сайту.

Запрос может содержать:

• подпись агента;
• подпись платформы;
• подпись intermediary над уже существующей подписью.

Текущий protocol draft допускает несколько подписей и позволяет одной стороне покрыть selected members другой подписи. Это сохраняет доказательство участия нескольких сторон. Однако несколько подписей сами по себе не доказывают делегирование, пользовательское согласие или право выполнить действие. Эти значения должны передаваться отдельно и проверяться политикой.

<a id="robots-and-content-policy"></a>

Web Bot Auth, robots.txt и правила использования контента

Web Bot Auth отвечает на вопрос о криптографической аутентичности клиента. Он не предоставляет разрешение:

• индексировать страницу;
• использовать данные для обучения модели;
• создавать производные материалы;
• обходить paywall;
• игнорировать robots.txt;
• хранить персональные данные;
• использовать контент в коммерческих целях.

robots.txt стандартизирован RFC 9309 и остаётся отдельным механизмом объявления crawl policy.

Signature Agent Card может содержать дополнительные метаданные:

• rfc9309-product-token;
• заявленное соответствие правилам;
• purpose;
• ожидаемую скорость;
• описание целевого контента.

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

То же относится к AIPREF, Content Signals и другим развивающимся механизмам выражения предпочтений владельца контента. Они дополняют Web Bot Auth, но не заменяются им. Чартер Web Bot Auth прямо предусматривает взаимодействие с AIPREF, сохраняя разделение между authentication и content policy.

<a id="server-responses"></a>

Как отвечать на неподписанный или невалидный запрос

У Web Bot Auth пока нет одного универсального формата ошибок для всех реализаций. Ответ зависит от того, требует ли сервер подпись, смог ли он разобрать запрос и запрещено ли действие политикой.

Рекомендуемая матрица

Protocol draft рекомендует 403 вместе с механизмом Accept-Signature, когда origin запрашивает HTTP Message Signature. Для предполагаемого replay или запроса новой подписи draft допускает 429. Ошибки разбора могут возвращать 400. Пример:

HTTP/1.1 403 Forbidden
Accept-Signature: sig1=("@authority");tag="web-bot-auth"
Cache-Control: no-store
Content-Type: application/problem+json

{
  "type": "https://example.com/problems/web-bot-auth-required",
  "title": "Web Bot Auth signature required",
  "status": 403,
  "code": "web_bot_auth_required"
}

Для невалидной подписи:

{
  "type": "https://example.com/problems/invalid-agent-signature",
  "title": "Agent signature could not be verified",
  "status": 403,
  "code": "invalid_agent_signature"
}

Не следует раскрывать:

• внутренние URL key service;
• содержимое replay cache;
• приватные policy rules;
• подробности, упрощающие перебор ключей;
• различия, позволяющие исследовать внутреннюю сеть через SSRF.

Как не сломать поисковых краулеров

Переходить к обязательной подписи нужно постепенно:

1. Сначала собирать метрики.
2. Отделить known crawlers от неизвестных клиентов.
3. Проверить, кто реально поддерживает подписи.
4. Сохранить fallback для официально документированных IP и reverse DNS.
5. Вводить enforcement по отдельным путям.
6. Не блокировать весь сайт из-за отсутствия подписи без анализа SEO-последствий.

<a id="comparison"></a>

Web Bot Auth и другие механизмы

Web Bot Auth и OAuth

Web Bot Auth отвечает:

Кто подписал HTTP-запрос?

OAuth отвечает:

Какие полномочия были предоставлены клиенту?

Для действий от имени пользователя могут потребоваться оба механизма:

• agent identity;
• user authorization;
• action policy.

Web Bot Auth и mTLS

mTLS аутентифицирует клиента в рамках TLS-соединения. Web Bot Auth подписывает HTTP-сообщение и может использоваться в инфраструктуре, где TLS завершается на CDN или reverse proxy.

mTLS особенно удобен в закрытых системах с заранее управляемыми клиентами. Web Bot Auth ориентирован на более открытую веб-экосистему.

<a id="adoption"></a>

Кто уже использует Web Bot Auth

Ниже перечислены только внедрения, которые удалось подтвердить первичной документацией на 4 августа 2026 года.

Google

Google экспериментирует с Web Bot Auth для части запросов Google-Agent. Подписанные запросы связываются с:

https://agent.bot.goog

Google прямо предупреждает, что подписывается не каждый запрос. Основной Googlebot в документации по-прежнему проверяется через User-Agent, IP-адрес и reverse DNS. Поэтому нельзя говорить, что весь Googlebot-трафик уже перешёл на Web Bot Auth.

Проверено: 4 августа 2026 года.

Cloudflare

Cloudflare использует Web Bot Auth как один из способов проверки Verified Bots. Другими способами остаются опубликованный IP-список со стабильным User-Agent и reverse DNS.

С 1 июля 2026 года signed agents включены в общую модель Verified Bots, а direct и intermediary access отражаются отдельными метаданными. Проверенный статус доступен для правил WAF и rate limiting через поля Cloudflare. (

Проверено: 4 августа 2026 года.

AWS WAF

AWS WAF Bot Control поддерживает проверку Web Bot Auth для CloudFront distributions начиная с AWSManagedRulesBotControlRuleSet версии 4.0.

Результат отражается в labels:

• web_bot_auth:verified;
• web_bot_auth:invalid;
• web_bot_auth:expired;
• web_bot_auth:unknown_bot.

Labels позволяют отдельно разрешать, блокировать или ограничивать определённые категории и имена агентов.

Проверено: 4 августа 2026 года.

Amazon Bedrock AgentCore Browser

Web Bot Auth в Amazon Bedrock AgentCore Browser всё ещё обозначен как Preview. При включении browser signing сервис добавляет Signature, Signature-Input и Signature-Agent.

AWS перечисляет Cloudflare, HUMAN Security, Akamai Technologies и DataDome среди поддерживаемых bot control vendors. При этом владелец сайта сохраняет полный контроль над доступом и может заблокировать или ограничить даже подписанного агента.

Проверено: 4 августа 2026 года.

Shopify

7 мая 2026 года Shopify объявила более строгие ограничения для автоматического трафика к Storefront API и Shopify-hosted storefront pages.

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

Проверено: 4 августа 2026 года.

Что показывают эти внедрения

Web Bot Auth уже используется для:

• защиты от подделки известных ботов;
• классификации AI-agent traffic;
• настройки отдельных rate limits;
• уменьшения зависимости от статических IP;
• снижения числа CAPTCHA для известных агентов;
• создания политик по оператору, категории или типу доступа.

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

<a id="privacy-and-alternatives"></a>

Приватность, риски для открытого веба и альтернативы

Прямая криптографическая идентификация даёт сайту мощный инструмент контроля. Она позволяет:

• отслеживать поведение конкретного агента;
• назначать ему персональный rate limit;
• строить историю нарушений;
• применять allowlist или denylist;
• отличать одного оператора от другого.

Та же точность создаёт риски для открытого веба.

draft-rescorla-anonymous-webbotauth-01 отмечает, что точная идентификация позволяет сайтам избирательно дискриминировать определённых ботов, включая действующих в общественных интересах. В качестве примеров документ приводит инструменты мониторинга государственных органов, проверки дискриминации в объявлениях и сравнения цен. (datatracker.ietf.org)

Anonymous Bot Authentication

Предлагаемая альтернатива использует анонимные credentials.

Сайт узнаёт не точную личность бота, а то, что клиент:

• получил credential от допустимого anchor или attester;
• относится к разрешённому классу;
• может участвовать в заданной rate-limiting схеме.

При этом сайт не обязательно узнаёт, какой конкретно оператор отправил запрос.

Такой подход полезен, когда нужно подтвердить:

• принадлежность к группе compliant bots;
• право на определённый объём трафика;
• участие в сертификационной или платёжной программе;
• отсутствие необходимости раскрывать индивидуальную identity.

Цена приватности — менее точный аудит. Anonymous Bot Authentication хуже подходит для персональных denylist, расследования поведения конкретного агента и аутентификации site services. Сам draft остаётся ранней индивидуальной работой и не прошёл полноценный security analysis. (datatracker.ietf.org)

Поведенческий триггер вместо тотальной идентификации

Ещё одна модель — не требовать identity от каждого клиента заранее.

Сайт может:

1. анализировать скорость и поведение;
2. пропускать обычный трафик;
3. запрашивать аутентификацию при признаках автоматизации или злоупотребления;
4. применять rate limit после предъявления credential.

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

Плата за доступ вместо блокировки

Экономическая альтернатива — платный доступ к контенту.

Cloudflare Pay Per Crawl использует HTTP 402 Payment Required: AI crawler либо передаёт платёжное намерение, либо получает цену доступа. Cloudflare выступает merchant of record. В этой модели Web Bot Auth используется вместе с оплатой, чтобы связать платёж и правила доступа с проверенным агентом.

Отдельно Cloudflare публикует x402-шаблоны для payment-gated HTTP resources. Но оплата, как и подпись, не означает автоматическую авторизацию:

Платёж подтверждает выполнение экономического условия. Политика всё равно должна решить, можно ли предоставить ресурс именно этому клиенту.

<a id="testing"></a>

Как протестировать Web Bot Auth

1. Создайте Ed25519-ключ

openssl genpkey -algorithm ed25519 -out private-key.pem
openssl pkey -in private-key.pem -pubout -out public-key.pem

Затем преобразуйте публичный ключ в JWK и вычислите SHA-256 JWK Thumbprint.

2. Опубликуйте key directory

https://agent.example.com/.well-known/http-message-signatures-directory

Не публикуйте параметр d или другие приватные компоненты JWK.

3. Подпишите тестовый запрос

Начните с безопасного GET и короткого срока действия:

GET /test HTTP/1.1
Host: example.com
Signature-Agent: sig1="https://agent.example.com"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1785859200;expires=1785859260;keyid="JWK_THUMBPRINT";nonce="RANDOM_VALUE";tag="web-bot-auth"
Signature: sig1=:BASE64_SIGNATURE:

4. Используйте официальные тестовые материалы

Cloudflare публикует библиотеки и примеры в репозитории cloudflare/web-bot-auth. Для проверки текущей реализации Cloudflare доступен тестовый endpoint crawltest.com/cdn-cgi/web-bot-auth.

На момент проверки endpoint возвращает:

• 200, если известный ключ и подпись успешно проверены;
• 401, если формат корректен, но ключ неизвестен, либо известный ключ не прошёл проверку;
• 400 при ошибке формата.

Важно учитывать, что тестовое окружение Cloudflare может поддерживать более раннюю форму Signature-Agent, чем текущий IETF draft.

5. Добавьте негативные тесты

Обязательно проверить:

• неверную подпись;
• неизвестный keyid;
• истёкший expires;
• created в будущем;
• повторный nonce;
• подменённый @authority;
• изменённый path;
• изменённый body;
• неправильный Content-Digest;
• небезопасный URL каталога;
• redirect на private IP;
• слишком большой JWKS;
• неподдерживаемый алгоритм;
• несовпадающие labels.

<a id="monitoring-and-rollout"></a>

Как измерять внедрение: monitor mode → enforcement

Начинать с немедленной блокировки всего неподписанного трафика рискованно.

Что логировать

Рекомендуемые поля:

• timestamp;
• request ID;
• source IP;
• User-Agent;
• signature label;
• keyid;
• алгоритм;
• Signature-Agent;
• discovery type;
• обнаруженная identity;
• signature result;
• signature age;
• validity window;
• replay result;
• directory cache status;
• verification latency;
• заявленный purpose;
• path и method;
• rate-limit tier;
• policy result;
• denial reason.

Не следует логировать приватные ключи, пользовательские токены, чувствительное содержимое body или полные платёжные credentials.

Этап 1. Наблюдение

• Проверять подписи без блокировки.
• Измерять долю signed и unsigned traffic.
• Определять vendor compatibility.
• Сравнивать User-Agent, IP и cryptographic identity.
• Выявлять ошибки clock skew и ротации ключей.

Этап 2. Мягкая политика

• Повышать rate limit проверенным агентам.
• Ограничивать неизвестный автоматический трафик.
• Не менять доступ к критическим операциям.
• Добавлять предупреждения в dashboard.

Этап 3. Enforcement по отдельным маршрутам

• Требовать подпись для дорогих ресурсов.
• Использовать fallback для известных SEO crawlers.
• Отдельно защищать checkout, forms и account pages.
• Не разрешать действия только по verified: true.

Этап 4. Полноценная policy model

• agent allowlist и denylist;
• правила по purpose;
• отдельные лимиты direct и intermediary access;
• пользовательская авторизация;
• Content-Digest;
• replay cache;
• risk-based confirmation;
• аудит и incident response.

<a id="agentbouncer"></a>

Как AgentBouncer дополняет Web Bot Auth

Web Bot Auth фокусируется на криптографической аутентификации автоматического HTTP-клиента.

AgentBouncer использует этот результат как один из входов более широкой модели:

• проверка RFC 9421 HTTP Message Signatures;
• обнаружение открытого ключа;
• проверка Signature-Agent;
• Content-Digest;
• replay protection;
• идентификация агента;
• OAuth-авторизация пользователя;
• политика конкретного действия;
• правила для API endpoints и MCP tools.

Концептуальный результат:

{
  "verified": true,
  "userAuthorized": true,
  "allowed": false,
  "reason": "tool_not_allowed_for_agent"
}

Критически важная проверка:

if (!verification.allowed) {
  deny();
}

Небезопасный вариант:

if (verification.verified) {
  executeSensitiveAction();
}

Формальный scope Web Bot Auth ориентирован на сайты для людей. AgentBouncer применяет связанные криптографические механизмы также к API и MCP-серверам, где дополнительно нужны tool-level authorization и проверка параметров.

<a id="implementation-checklist"></a>

Чек-лист внедрения Web Bot Auth

Для оператора агента

• Создать отдельную асимметричную пару ключей.
• Предпочитать Ed25519 при поддержке всеми участниками.
• Хранить приватный ключ в KMS, HSM или secret manager.
• Не публиковать приватные JWK-поля.
• Использовать HTTPS для метаданных и ключей.
• Вычислять keyid как SHA-256 JWK Thumbprint.
• Добавлять created и expires.
• Использовать короткое validity window.
• Добавлять уникальный nonce.
• Указывать tag="web-bot-auth".
• Подписывать соответствующий member Signature-Agent.
• Для транзакций подписывать method, authority, path и Content-Digest.
• Создавать новую подпись для каждой попытки.
• Поддерживать ротацию и отзыв ключей.
• Не использовать один ключ для независимых security contexts.
• Публиковать ips_uri только как дополнительный сигнал.
• Проверять совместимость с конкретной редакцией vendor implementation.

Для сайта или verifier

• Использовать корректный RFC 9651 parser.
• Проверять labels во всех связанных заголовках.
• Проверять tag.
• Проверять обязательные covered components.
• Проверять created, expires и clock skew.
• Ограничивать максимальное validity window.
• Находить ключ строго по keyid.
• Сверять keyid с JWK Thumbprint.
• Применять allowlist алгоритмов.
• Защищать key discovery от SSRF.
• Учитывать запрет redirect для CIMD discovery.
• Проверять взаимоисключение jwks и jwks_uri.
• Проверять подпись по RFC 9421.
• Проверять Content-Digest по raw body.
• Хранить использованные nonce или signature fingerprints.
• Отделять verified от allowed.
• Не превращать сбой verification service в fail-open.
• Внедрять enforcement после monitor mode.
• Логировать причины отказа без утечки чувствительных данных.

<a id="common-mistakes"></a>

Распространённые ошибки

1. Доверять одному Signature-Agent

Заголовок можно подделать. Он получает смысл только после проверки подписи и безопасного обнаружения ключа.

2. Считать tag доказательством личности

tag="web-bot-auth" определяет контекст подписи, но не подтверждает владельца ключа.

3. Автоматически разрешать любой verified запрос

Подпись — входной сигнал политики, а не итоговое решение.

4. Использовать долгоживущие подписи

Чем больше validity window, тем выше риск replay.

5. Не проверять nonce

Валидная подпись не обязательно является новым запросом.

6. Подписывать только @authority для транзакций

Для изменения данных нужно защитить method, path и body.

7. Разбирать JSON до проверки digest

Digest должен вычисляться по исходным байтам.

8. Загружать произвольные URL без SSRF-защиты

Discovery-механизм не должен получать доступ к localhost, cloud metadata и внутренним сервисам.

9. Требовать media type там, где draft его не устанавливает

Для jwks_uri registry draft не требует определённого media type. Проверка должна учитывать выбранный discovery profile.

10. Игнорировать несовместимость drafts

Поддержка legacy string form и Structured Field Dictionary у разных vendors может отличаться.

11. Считать подпись согласием пользователя

Ключ платформы может использоваться большим количеством пользователей. User authorization должна проверяться отдельно.

12. Не предусматривать ротацию

Verifier должен обновлять кеш и удалять ключи, отсутствующие в актуальном каталоге.

<a id="faq"></a>

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

Что такое Web Bot Auth простыми словами?

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

Является ли Web Bot Auth готовым RFC?

Нет. По состоянию на 4 августа 2026 года основные документы остаются индивидуальными Internet-Draft и могут измениться.

Заменяет ли Web Bot Auth OAuth?

Нет. Web Bot Auth аутентифицирует автоматического клиента, а OAuth описывает предоставленные клиенту полномочия. Для действий от имени пользователя могут потребоваться оба механизма.

Нужен ли Content-Digest?

Для обычного GET без body — не всегда. Для POST, PUT и PATCH с важными параметрами Content-Digest следует вычислять и включать в подпись.

Предотвращает ли Web Bot Auth replay-атаки?

Не автоматически. Нужны короткий срок действия, уникальный nonce и серверный replay cache.

Должен ли сайт разрешить проверенного агента?

Нет. Сайт может разрешить, ограничить, rate-limit, монетизировать или заблокировать правильно подписанный запрос.

Отменяет ли Web Bot Auth IP-списки?

Нет. Актуальный registry draft предусматривает ips_uri. IP становится дополнительным сигналом, а не единственным доказательством личности.

Можно ли использовать HTTP Message Signatures для MCP?

Да, технические механизмы RFC 9421 и RFC 9530 можно применять к MCP over HTTP. Но MCP и machine-only API находятся за пределами формального scope Web Bot Auth Working Group и требуют собственной модели OAuth и tool authorization.

Заключение

Web Bot Auth решает важную проблему современного веба: User-Agent, IP-адрес и reverse DNS больше не дают достаточно точной идентификации растущего числа AI crawlers, browser agents и автоматических клиентов.

Криптографическая подпись позволяет доказать владение ключом и защитить выбранные компоненты HTTP-запроса.

Но production-модель всегда шире:

• криптографическая identity;
• безопасное обнаружение ключей;
• целостность body;
• replay protection;
• репутация и поведение;
• правила использования контента;
• пользовательская авторизация;
• action-level policy.

Web Bot Auth помогает ответить:

Кто подписал этот запрос?

Политика сайта должна ответить:

Что этому агенту разрешено сделать?

Защитите API или MCP-сервер с AgentBouncer — начните с monitor mode, изучите реальный agent traffic и только затем включайте блокирующие политики.

Предыдущие материалы:

• «Аутентификация AI-агентов»
• «Аутентификация и авторизация AI-агентов: в чём разница»

<a id="changelog"></a>

История обновлений

4 августа 2026 года

• Добавлены актуальные protocol-00, directory-00 и registry-03.
• Уточнено, что основные Web Bot Auth drafts остаются individual submissions.
• RFC 8941 заменён на RFC 9651.
• Добавлен draft-nottingham-webbotauth-use-cases-02.
• Добавлен раздел об Anonymous Bot Authentication.
• Обновлены jwks, jwks_uri, client_id, ips_uri и Signature-Key.
• Добавлены AWS WAF, актуальный статус AgentCore, Cloudflare и Shopify.
• Добавлены ответы сервера, алгоритмы, clock skew, тестирование и monitor-mode roadmap.
• Обновлена ссылка на Client ID Metadata Document до редакции -02.