На протяжении большей части истории web у автоматизированного трафика в стеке безопасности была одна задача: его нужно было идентифицировать и остановить. Вокруг этой задачи и выросло управление ботами. Оно находится на edge вашей инфраструктуры, оценивает запросы и блокирует или проверяет те, которые выглядят вредоносными. Оно очень хорошо справляется с этой задачей, и его следует сохранять.
AI agent изменили то, что приложения должны знать. Растущая доля автоматизированных запросов теперь исходит от agent, действующих от имени реальных клиентов: assistant сравнивает тарифы, agent отправляет support ticket, client обращается к вашему MCP server, чтобы завершить задачу. Одновременно многие люди используют ваш продукт вместе с AI assistant рядом. Это не атаки. Это пользователи, и они заслуживают правильного сценария, а не страницы блокировки.
Именно этот пробел и закрывает Proof of Actor. Эта страница прямо сравнивает две категории, чтобы вы могли увидеть, где каждой из них место.
Краткая версия
| Управление ботами | Proof of Actor | |
|---|---|---|
| Главный вопрос | Нужно ли останавливать этот запрос? | Кто или что действует, и какова evidence? |
| Где работает | На edge, перед вашим приложением | Внутри вашего приложения, API или MCP server |
| Типичный результат | Allow, block или challenge; часто score | Human, Human + AI, Agent или Unknown, плюс basis |
| Как относится к людям с поддержкой AI | Обычно неотличимо от других людей | Отдельный класс, Human + AI |
| Как относится к неясному трафику | Часто challenge или block | Unknown, с fallback, который вы выбираете для каждого route |
| Кто решает, как отвечать | Edge rule set | Код вашего приложения |
| Поведение по умолчанию после установки | Enforcement | Observation; ничего не меняется, пока вы не добавите policy |
| Лучше всего подходит для | Остановки credential stuffing, злоупотреблений скрейпингом и объемных атак | Product, analytics и policy-решений для каждого actor |
Дальше на этой странице каждый ряд разбирается отдельно.
Два разных вопроса
Управление ботами отвечает на вопрос защиты. Его цель - не допустить вредоносную автоматизацию к вашей инфраструктуре, учетным записям и инвентарю. Каждый сигнал, который оно собирает, служит этой цели, а результатом является решение: пропустить запрос, заблокировать его или поставить перед ним challenge.
Proof of Actor отвечает на вопрос понимания. Его цель - сообщить вашему приложению, кто или что стоит за каждой интеракцией, чтобы вы могли решить, как ее обслуживать. Его результат - не вердикт по запросу. Это классификация вместе с evidence:
- Human: наблюдаемые signals указывают на интеракцию, управляемую человеком.
- Human + AI: человек управлял интеракцией с помощью AI assistance, которая была declared или observed.
- Agent: автоматизированная или исходящая от agent интеракция, подтвержденная verifiable identity или qualified inference.
- Unknown: evidence не позволяет сделать надежное определение.
Каждый результат также указывает свою evidence basis: verified, declared, inferred или unknown. Это та информация, которая нужна для продуктового решения, и это не тот формат, под который проектировался protection score.
Где работает каждый из них
Управление ботами обычно работает на network edge или в reverse proxy, перед всем остальным. Это как раз правильное место для защиты. Оно рано видит трафик, поглощает атаки до того, как они вам что-то стоят, и удерживает origin servers в чистоте.
Proof of Actor работает там, где живет логика вашего приложения: server middleware, Next.js, edge layer, который вы контролируете, одобренная browser integration, generic HTTP API или ваш MCP server. Такое расположение дает ему доступ к тому, что знает ваше приложение: какой route вызывается, к какому workflow он относится, выполнял ли действие ваш собственный assistant и заявил ли о себе client. Полный список см. в integration paths.
Поскольку оба решения работают в разных местах, они не конкурируют за одну и ту же задачу. Запрос может пройти через управление ботами, дойти до вашего приложения и затем получить actor context, который определит ответ.
Score против evidence
Многие protection products выражают свое суждение как score. Score удобен для решения о block: задайте threshold и действуйте выше него. Но он гораздо менее полезен, когда вопрос звучит так: "какой сценарий следует дать этому actor?"
Score не сообщает, пришел ли низкорисковый запрос от человека, от человека, работающего с assistant, или от корректно ведущего себя agent. Он не говорит, какие части вывода были verified, а какие inferred. И он не может выразить "мы не знаем", не превратив это в число.
Proof of Actor сохраняет эти различия. Результат verified для agent означает, что request signature был проверен по опубликованному key, например через HTTP Message Signatures. Результат declared означает, что это заявил client или ваше собственное приложение. Результат inferred помечен как inference. А Unknown является полноценным ответом, а не скрытым default. Ваша команда может прочитать каждый результат и увидеть, на чем именно он основан.
Люди с поддержкой AI - не bots
Самая быстрорастущая группа в большинстве приложений - люди, работающие с AI. Они пишут сообщения с помощью assistant, заполняют формы с поддержкой, и проходят через ваш продукт, когда рядом находится AI tool. Инструменты защиты не создавались для того, чтобы отделять их от других людей, и в этом нет необходимости.
Часто ваш продукт в этом нуждается. Вам может понадобиться помечать support tickets, созданные с помощью AI, чтобы их обрабатывала нужная команда, измерять, как пользователи с поддержкой AI проходят onboarding, или предлагать им более плавный путь. Proof of Actor дает этой группе собственный класс, Human + AI, и сообщает его только тогда, когда помощь declared или observable через поддерживаемую integration. Подробнее см. в глоссарии AI-assisted interaction.
Unknown - это ответ, а не угроза
Каждый classifier сталкивается с трафиком, который не может объяснить. Системы защиты обычно склонны к осторожности, поэтому неясный трафик часто получает challenge. На edge это разумное решение.
Внутри вашего приложения один осторожный default часто оказывается неверным. Unknown request на публичную страницу документации и Unknown request на изменение пароля учетной записи требуют очень разного обращения. Proof of Actor возвращает Unknown как собственный результат и позволяет задавать fallback для каждого route: разрешить его на публичных страницах, оставить текущие проверки для изменений учетной записи, отправить его на review для операций с высоким влиянием. Руководство по handling Unknown traffic разбирает эти patterns.
Кто решает, как отвечать
В случае управления ботами решение принимает rule set на edge. Это эффективно и обеспечивает единообразие решений во всех ваших properties.
В случае Proof of Actor решение принимает ваше приложение. Продукт поставляет actor context, а ваш код применяет policy. Вы можете отдавать verified agent структурированный API вместо страниц, рассчитанных на людей, оставлять стандартный сценарий для human sessions, помечать submissions с поддержкой AI и запрашивать более сильные credentials для чувствительных действий, когда этого требуют ваши условия. Policies пишутся для каждого route, для каждого actor class и для каждой basis, и они живут рядом с остальной business logic.
Сначала наблюдение
Управление ботами обычно внедряют для enforcement, потому что его ценность заключается именно в остановке злоупотреблений.
Proof of Actor начинается в observation mode. Его установка ничего не меняет в поведении вашего приложения. Вы видите реальный состав actor по route, изучаете evidence, просматриваете эффект policy на реальном трафике и включаете enforcement только тогда, когда готовы, по одному route за раз. Процесс описан в руководстве rolling out actor-aware policies safely.
Как они работают вместе
Самая сильная схема использует оба решения, каждое на своем уровне:
- На edge управление ботами останавливает credential stuffing, злоупотребления скрейпингом и объемные атаки.
- В вашем приложении Proof of Actor классифицирует трафик, который прошел дальше, как Human, Human + AI, Agent или Unknown, вместе с его basis.
- В вашем коде policies используют этот контекст, чтобы выбрать сценарий: структурированный API для verified agent, обычный поток для человека, метка для submission с поддержкой AI, явный fallback для Unknown.
- В analytics ваша команда видит, какие routes и workflows использует каждый actor class, так что product и security работают с одной и той же картиной.
Запись решения edge рядом с результатом actor делает картину полной: что сделала защита и кто фактически действовал.
Когда выбирать что
Выбирайте управление ботами, когда ваша главная проблема - это злоупотребления: попытки захвата учетных записей, накопление инвентаря, агрессивный скрейпинг или потоки трафика.
Выбирайте Proof of Actor, когда ваш главный вопрос связан с пользователями: какую часть вашего продукта уже используют agent, какие agent обращаются к вашему API или MCP server, где людям с поддержкой AI тяжело и какие routes нуждаются в actor-aware policy.
Большинству команд, которые обслуживают production application, API или MCP server, нужны ответы на оба вопроса, поэтому оба решения должны находиться в одном стеке.
Начать работу
Proof of Actor находится в private beta. Отобранные founding developer teams могут получить до 12 months бесплатного доступа в рамках согласованных limits использования, с прямой поддержкой команды, которая его создает. Подайте заявку на early access и расскажите нам о приложении и взаимодействии, которое вы хотите понять.