ПОДТВЕРЖДЕННАЯ АВТОМАТИЗАЦИЯ

Распознавайте подтвержденные автоматизированные запросы

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

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

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

Не весь автоматизированный трафик одинаков

Автоматизированные клиенты обращаются к вашему приложению каждую минуту: поисковые краулеры, инструменты мониторинга, партнерские интеграции, AI-ассистенты, которые получают страницы для пользователя, и автономные агенты, выполняющие задачи. На протяжении многих лет единственным способом, которым большинство приложений могло различать их, был заголовок user-agent, строка, которую любой клиент может установить во что угодно.

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

Подтвержденные автоматизированные запросы меняют ситуацию. Когда автоматизированный клиент подписывает свои запросы ключом, который он опубликовал, ваше приложение может проверить подпись и криптографически понять, какой клиент подписал запрос. Proof of Actor делает эту проверку частью единого, согласованного результата по actor, на котором может работать ваш код. Чтобы подробнее понять, что именно эта проверка устанавливает, а что нет, прочитайте что доказывают подписанные запросы AI-агентов.

Как работает подпись запроса

Новый подход к автоматизированному трафику использует HTTP message signatures, стандартизованные в RFC 9421, который определяет, как создавать, кодировать и проверять подписи для компонентов HTTP сообщения. Клиент подписывает выбранные части каждого запроса закрытым ключом и включает подпись и ее параметры в заголовки. Соответствующий открытый ключ он публикует по адресу, связанному с контролируемым им идентификатором, обычно своим доменом.

Когда запрос приходит, получатель получает или находит опубликованный ключ, восстанавливает подписанное содержимое и проверяет подпись. Если она проходит проверку, значит запрос был подписан владельцем этого ключа. Работа над подписью автоматизированного трафика продолжается в рабочей группе IETF Web Bot Auth working group, мандат которой охватывает криптографическую аутентификацию автоматизированных клиентов, таких как краулеры и AI-агенты, действующие от имени конечных пользователей; статья глоссария Web Bot Auth кратко это описывает. Пост в блоге что доказывают подписанные запросы AI-агентов пошагово разбирает подтвержденный запрос, а вариант использования для APIs показывает, где проверка дает пользу в первую очередь.

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

Что подтверждает проверенная подпись, а что нет

Это различие - самая важная часть правильной обработки подтвержденных автоматизированных запросов.

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

Действительная подпись не подтверждает:

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

Это отдельные вопросы. Ваше приложение отвечает на них своими учетными данными, моделью авторизации и политикой. Proof of Actor намеренно разделяет их, а страница Detection & Limitations точно объясняет, что может установить каждый вид evidence.

Как Proof of Actor обрабатывает подтвержденные автоматизированные запросы

Detect

Ваша интеграция передает в Proof of Actor контекст запроса, включая любые заголовки подписи. Подписи проверяются по опубликованным ключам. Запросы, которые проходят проверку, записываются с базой verified. Клиенты, которые лишь заявляют о себе, записываются как declared. Поведенческие паттерны записываются как inferred. Если данных недостаточно, результат - Unknown. Ничто не повышается до verified, если не прошла криптографическая проверка.

Understand

Смотрите, какие подтвержденные операторы вызывают ваше приложение, какие маршруты они используют, как часто и чем это отличается от declared и unknown automation. Сводка evidence в каждом результате показывает, какой ключ и какой идентификатор были задействованы, чтобы ваша команда могла быстро разобраться в любом запросе.

Route

Используйте базу в своих политиках. Типичные варианты:

Давать подтвержденным агентам структурированный ответ на маршрутах только для чтения, например в API или в версии страницы в формате Markdown.
Поднимать лимиты запросов для подтвержденных операторов, которых вы знаете, и при этом оставлять стандартные лимиты для declared клиентов.
Сохранять вашу текущую авторизацию на каждом маршруте записи, независимо от того, что говорит подпись.
Определять явный fallback для неподписанных и Unknown вызывающих сторон на каждом маршруте.

Решают ваши политики; Proof of Actor предоставляет evidence.

Почему заголовка user-agent недостаточно

Строки user-agent - это декларации. Любой клиент может отправить любое значение, а подмена user-agent не требует никакого мастерства. Поэтому операторы краулеров публикуют собственные проверки: Google документирует обратный и прямой DNS lookup и опубликованные диапазоны IP для проверки Googlebot, Bing документирует DNS-проверку для проверки Bingbot, а OpenAI публикует файлы диапазонов IP для каждого из своих краулеров и user agents. Proof of Actor рассматривает утверждение user-agent как declared evidence, никогда как verification. Это означает, что клиент, который выдает себя за известный краулер без действительной подписи, будет отмечен с базой declared или inferred, а ваша политика сможет обрабатывать его иначе, чем клиента, который подтвердил свою идентичность.

Именно поэтому подтвержденные автоматизированные запросы ценны: они дают надежный способ распространять доверие на тех клиентов, которые его заслужили, не распространяя его на всех, кто копирует их заголовок.

Доказательства идентичности, учетные данные и авторизация

В любом приложении, которое обслуживает автоматизированных клиентов, вместе работают три слоя:

Доказательства идентичности: какой клиент подписал этот запрос? На это отвечает проверенная подпись.
Учетные данные: какой аккаунт несет ответственность? На это отвечает ваш API key, token или session.
Авторизация: может ли эта вызывающая сторона делать это? На это отвечает ваша модель разрешений.

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

Где это используется

Proof of Actor работает рядом с вашим gateway, authentication и rate limiting. Интеграции работают как server-side middleware, на edge, в вашем MCP server или через generic HTTP integration, с практической поддержкой для каждой founding team. Если ваш трафик в основном состоит из APIs и инструментов, варианты использования для APIs и MCP Servers показывают самые важные паттерны.

Начните в режиме наблюдения

Каждая интеграция начинается в режиме наблюдения. Результаты записываются без изменения того, как ваше приложение отвечает, чтобы вы могли увидеть, какая часть вашего автоматизированного трафика подтверждена, какие операторы подписывают запросы и где доля Unknown самая высокая. Политики появляются позже, маршрут за маршрутом, когда evidence их поддерживает. Как это работает проводит через весь поток.

Практические детали, которые делают проверку надежной

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

Проверяйте свежесть

RFC 9421 определяет параметры подписи created и expires, и подписанные запросы обычно их содержат. Отклоняйте подписи за пределами короткого окна, чтобы перехваченный запрос нельзя было воспроизвести позже.

Разумно кэшируйте ключи

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

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

Подпись, которая охватывает только временную метку, доказывает очень мало. Проверяйте, что в подписанные компоненты входят method, path и host, чтобы подпись была связана с тем запросом, который ваше приложение действительно получило.

Записывайте evidence

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

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

Присоединяйтесь к программе founding developer

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

Если автоматизированные клиенты обращаются к вашему приложению, и вы хотите обрабатывать подтвержденные запросы иначе, подайте заявку на ранний доступ. Расскажите нам о вашем приложении и о тех автоматизированных вызывающих сторонах, которых вы видите, и мы покажем, как Proof of Actor подходит под ваш сценарий.

Источники

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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

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

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

Что такое подтвержденный автоматизированный запрос?

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

Означает ли подтвержденная подпись, что агент авторизован?

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

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

Proof of Actor все равно классифицирует их, используя declared и inferred evidence там, где это возможно, и сообщает Unknown, когда доказательств недостаточно. У каждого результата указана его база.

Может ли строка user-agent подтвердить клиента?

Нет. Строки user-agent легко подделать, поэтому они считаются декларацией, а не подтверждением. Именно криптографические подписи делают запрос проверяемым.

Как начать?

Подайте заявку на ранний доступ. Команды-основатели начинают в режиме наблюдения, а отобранные команды могут получить до 12 месяцев бесплатно в рамках согласованных лимитов использования.

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

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

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

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