СРАВНЕНИЕ

Proof of Actor vs allowlist-ы user agent: имя - это утверждение, а не доказательство

Allowlisting по строке User-Agent быстро настраивается и легко понимается. Его также легко обмануть, потому что заголовок такой, каким его решает отправить клиент. Ниже показано, что на самом деле сообщает allowlist User-Agent, где помогают сетевые проверки и как Proof of Actor разделяет декларации и подтвержденные доказательства.

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

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

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

Allowlist User-Agent доверяет любому имени, которое клиент указывает в своем заголовке User-Agent, а любой клиент может ввести любое имя. Reverse DNS и опубликованные диапазоны IP добавляют реальные доказательства для некоторых операторов, но только для тех, кто их публикует. Proof of Actor рассматривает заголовок как декларацию, проверяет подписи там, где агенты подписывают свои запросы, и возвращает Unknown, когда доказательств мало, чтобы ваш код принимал решение с учетом фактов.

Allowlist User-Agent - один из самых старых шаблонов в вебе. Вы храните список имен краулеров и клиентов, которым доверяете. Когда приходит запрос со совпадающим заголовком User-Agent, вы пропускаете его, не показываете challenge или отдаете более легкую страницу. Настраивается это за минуты, и всем в команде это понятно.

Этот подход был логичнее, когда основными автоматическими посетителями были несколько поисковых краулеров и несколько инструментов мониторинга. Сегодня к приложениям все чаще обращаются AI agents, assistants и автоматизированные клиенты, и многие из них сообщают свое имя. Некоторые из этих имен настоящие. Некоторые скопированы. По заголовку нельзя понять, какие именно.

Proof of Actor использует другой подход. Он рассматривает строку User-Agent как то, чем она является, - как декларацию, - и показывает ее вместе с более сильными доказательствами, когда такие доказательства есть. На этой странице объясняется, в чем ограничения allowlisting по имени, где помогают проверки на сетевом уровне и как проверенные подписи и явный класс Unknown меняют картину.

Кратко

	allowlist User-Agent	Proof of Actor
Основное доказательство	Имя в заголовке User-Agent	Подписи, декларации и сигналы, каждый с указанной основой
Может ли клиент подделать это?	Да, отправив ту же строку	Declared basis можно заявить; для verified basis нужен signing key
Вывод	В списке или нет	Human, Human + AI, Agent или Unknown, плюс основа
Неясный трафик	Считается не включенным в allowlist, либо допускается по умолчанию	Unknown, с fallback, который вы выбираете для каждого route
Люди с AI-помощью	Невидимы; они используют обычные браузеры	Отдельный класс, Human + AI, когда это заявлено или обнаружено
Поддержка	Ручные обновления списка по мере смены имен	Keys публикуются операторами агентов; политики находятся в вашем коде
Поведение по умолчанию при установке	Все, что разрешает список	Наблюдение; ничего не меняется, пока вы не добавите policy
Лучше всего подходит для	Недорогой маршрутизации хорошо ведущих себя известных клиентов	Контекст действий с опорой на доказательства для продуктовых и policy-решений

Остальная часть страницы объясняет каждую строку.

Почему allowlisting по User-Agent можно подделать

Заголовок User-Agent задает клиент. Его задает браузер, скрипт и framework для агентов. В HTTP ничто не проверяет, что значение правдиво. Если ваш allowlist доверяет строке, любой, кто скопирует эту строку, получит такое же отношение.

Это называется user agent spoofing, и это распространено по простой причине: это ничего не стоит. Скрейперу, который хочет избежать challenge, достаточно заимствовать имя краулера, которому вы доверяете. Проблемный клиент может выдать себя за популярного ассистента. Даже легитимный инструмент может отправить общий браузерный строковый идентификатор, если так сделал default библиотеки.

В результате у allowlist User-Agent есть два режима отказа:

False trust: недоверенный клиент заявляет доверенное имя и проходит.
False doubt: легитимный клиент отправляет неожиданный или общий строковый идентификатор и не проходит.

Ни один из этих сбоев не виден только по заголовку. В этом и состоит основное ограничение, и никакое ведение списка его не убирает.

Для чего заголовок все еще полезен

Все это не значит, что строки User-Agent нужно игнорировать. Корректно работающие краулеры и агенты честно представляются, и имя - полезная подсказка для routing, analytics и debugging. Оно показывает, кем клиент себя называет.

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

Reverse DNS и списки IP: частичные меры

Многие команды усиливают allowlist сетевыми проверками. Они помогают, и их важно понимать точно.

Проверка reverse DNS

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

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

Опубликованные диапазоны IP

Другие операторы публикуют диапазоны IP, которые используют их автоматизированные клиенты. Сопоставление запроса с этими диапазонами выполняется быстро и дает похожие доказательства, как и reverse DNS. В IETF идет обсуждение стандартного формата для публикации этих диапазонов, но по состоянию на November 2026 согласованного стандарта нет, и покрытие зависит от того, публикует ли оператор такие данные.

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

Что в сумме дают сетевые проверки

Reverse DNS и списки IP превращают некоторые декларации в нечто более сильное для части хорошо известных операторов. Они не покрывают длинный хвост агентов и инструментов и совсем не помогают с людьми, которые работают вместе с AI. Это частичные меры: их стоит использовать, но их недостаточно.

Подписи versus декларации

Более сильная форма доказательства - криптографическая подпись. С HTTP Message Signatures, определенными в RFC 9421, клиент подписывает выбранные части каждого запроса с помощью private key. Проверяющая сторона получает опубликованный public key оператора и проверяет подпись. Если проверка проходит, запрос подписал владелец этого ключа, а подписанные части не были изменены по пути.

Рабочая группа IETF Web Bot Auth стандартизирует то, как автоматизированные клиенты используют эти подписи и как публикуют свои keys. Наш материал Web Bot Auth для продуктовых команд описывает текущий статус.

Proof of Actor использует действительную подпись как доказательство Verified. Строка User-Agent, client hint или self-description в теле запроса считаются Declared. Поведенческие и контекстные сигналы считаются Inferred и так и маркируются. Каждый результат указывает, на какой основе он построен, чтобы ваша команда никогда не путала утверждение с проверкой. Полные определения см. в записи основа доказательства.

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

Как обрабатывать Unknown вместо догадок

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

Proof of Actor рассматривает Unknown как полноценный результат. Когда доказательства не позволяют сделать надежное заключение, он так и говорит, а не гадает. Затем ваши политики решают, что означает Unknown для каждого route:

На публичной документации или маркетинговых страницах - разрешить.
На search или listing endpoints - разрешить с обычными rate limits.
Для изменений аккаунта - сохранить текущие проверки.
Для действий с высоким влиянием - отправить на review или запросить более сильный сигнал.

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

А как насчет людей с AI-помощью?

Allowlist User-Agent ничего не говорит о человеке, который использует AI assistant в обычном браузере. Его User-Agent - это обычная строка браузера. Но многие продукты хотят распознавать такое взаимодействие, например чтобы помечать отправленные тексты, созданные с помощью AI, или понимать, как пользователи с AI-помощью проходят onboarding.

Proof of Actor относит такие взаимодействия к классу Human + AI, когда помощь заявлена или наблюдается через поддерживаемую интеграцию. Он не угадывает только по стилю письма. Подробнее см. в AI-assisted interaction.

Переход от allowlist к политикам, основанным на доказательствах

Вам не нужно удалять allowlist в первый же день. Безопасный путь выглядит так:

Установите в режиме наблюдения. Proof of Actor ничего не меняет. Ваш allowlist продолжает работать.
Сравните. Для каждого route посмотрите, какие разрешенные запросы имеют verified evidence, какие несут только декларацию, а какие оказываются Unknown.
Предварительно просмотрите политики. Составьте policy, которая по-разному обрабатывает verified agents, declared agents и Unknown, и посмотрите ее эффект на реальном трафике.
Включайте enforcement по route. Начните с тех route, где подделанное имя нанесло бы наибольший вред.
Сохраните allowlist как подсказку. Имена по-прежнему полезны для routing и analytics, но теперь вместе с видимой основой.

В руководстве безопасный вывод actor-aware policy описан каждый шаг, а подтвержденные автоматические запросы объясняют, как вписываются подписанные клиенты.

Когда allowlist достаточно

Для малорисковой маршрутизации, например чтобы отдать более легкую страницу известному краулеру на публичном контенте, allowlist User-Agent часто вполне подходит. Цена подделанного имени невелика.

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

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

Proof of Actor находится в private beta. Отобранные founding developer teams могут получить до 12 месяцев бесплатного доступа в рамках согласованных лимитов использования, без автоматического выставления счетов. Подайте заявку на ранний доступ и расскажите, каких клиентов вы сегодня добавляете в allowlist и какие 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

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

Allowlist User-Agent бесполезен?

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

Проверка reverse DNS устраняет подмену User-Agent?

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

Как Proof of Actor обрабатывает заголовок User-Agent?

Как декларацию. Он вносит вклад в результат как declared basis, но никогда не как verified basis. Для verified basis нужны доказательства, например HTTP Message Signature, проверенная по опубликованному ключу.

Что доказывает verified signature?

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

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

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

Изменит ли добавление Proof of Actor текущее поведение allowlist?

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

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

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

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

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