СРАВНЕНИЕ

Proof of Actor против API bot protection: keys говорят, кто платит, а контекст actor - кто действует

API gateway, правила WAF для ботов, API keys и rate limits помогают сохранять API доступным и подотчетным. Они не были созданы, чтобы определять, пришел ли запрос от человека в приложении, от человека, работающего с assistant, или от автономного agent. Ниже показано, как bot management для APIs соотносится с Proof of Actor и как эти два слоя дополняют друг друга.

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

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

Раньше у APIs была простая модель traffic. Developer регистрировался, получал key, писал integration, а затем эта integration вызывала ваши endpoints по расписанию или когда user нажимал что-то. Bot management для APIs вырос вокруг этой модели: аутентифицировать key, ограничивать объем, фильтровать очевидно вредоносный traffic и сохранять доступность service для всех остальных.

Эта модель по-прежнему работает, и инструменты, созданные под нее, по-прежнему важны. Изменилось то, кто стоит за вызовами. Один и тот же API key теперь может нести requests от человека, использующего app вашего customer, от человека, попросившего AI assistant выполнить работу, и от автономного agent, который всю ночь выполняет многошаговый task. Ваши существующие controls видят один key и одну rate of requests. Для решений о product, support и policy часто нужно знать больше.

Proof of Actor закрывает этот пробел. Он сообщает вашему API, кто или что действует в каждом request, указывает evidence, а затем оставляет decision вашему code. Эта страница сравнивает его с основными слоями API bot protection, чтобы было видно, где место каждого из них.

Кратко

	API bot protection	Proof of Actor
Основной вопрос	Этот request разрешен, аутентифицирован и укладывается в лимиты?	Кто или что действует, и каково evidence?
Типичные слои	API gateway, правила WAF для ботов, API keys, rate limits	Классификация actor внутри вашего API или MCP server
Определяет	Account или integration, которым принадлежит key	actor за каждым request: Human, Human + AI, Agent или Unknown
Выход	Allow, reject, throttle; иногда bot score	Класс плюс basis: verified, declared, inferred или unknown
Неопределенный traffic	Обычно разрешается, если key valid, или отклоняется по rule	Unknown, с fallback, который вы выбираете для каждого route
Кто решает response	Конфигурация gateway и WAF	Код вашего application
По умолчанию после установки	Enforcement	Observation; ничего не меняется, пока вы не добавите policy
Лучше всего подходит для	Availability, фильтрации abuse, quotas, accountability	Корректного обслуживания каждого actor и понимания API usage

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

Что хорошо делает API bot protection

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

API gateways

Gateway - это входная дверь для вашего API. Он завершает connections, аутентифицирует API keys или tokens, направляет requests в нужный service, применяет quotas и часто фиксирует usage для billing и analytics. Он быстро и одинаково для каждого endpoint отвечает на вопрос: "Разрешен ли этому caller вход и через какую дверь?"

Правила WAF для ботов

Web application firewall с правилами для bots анализирует traffic на известные шаблоны атак и вредоносной automation. Он может отфильтровывать попытки injection, блокировать traffic из источников с историей abuse и вызывать challenge или отбрасывать requests, которые выглядят как scraping или credential attacks. Это ваша лучшая защита от traffic, который вообще не должен доходить до вашего code.

API keys и tokens

Keys и tokens дают подотчетность. Каждый request сопоставляется с account, поэтому вы знаете, чья integration сделала вызов, можете отозвать access и привязать usage к источнику. Scoped tokens идут дальше и ограничивают, что именно может делать caller.

Rate limits

Rate limits защищают availability. Они не позволяют одной integration потреблять capacity, предназначенную для всех, и замедляют brute-force и enumeration attempts. Limits на уровне key и route - это стандартный, эффективный control.

Вместе эти слои очень хорошо отвечают на вопросы защиты и подотчетности. Сохраняйте их.

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

Ни один из этих слоев не предназначен для того, чтобы сообщать вам какой именно actor стоит за authenticated request. Действительный key говорит, какому account принадлежит integration. Но он не говорит:

пришел ли этот конкретный call от человека, который нажал кнопку в app вашего customer,
попросил ли человек AI assistant выполнить действие,
сделал ли вызов autonomous agent как один шаг в более длинном task,
или вообще нельзя сказать.

Это различие становится важнее с каждым месяцем. API, который обслуживает CRM integration, scheduling tool или developer platform, все чаще получает agent traffic через те же keys, что обслуживают human-driven apps. Если вы хотите дать agents структурированный response, запрашивать confirmation для важных writes, инициированных agents, помечать AI-assisted submissions или просто измерять, какая часть вашего API usage обусловлена agents, вам нужен actor context.

Что Proof of Actor добавляет к API

Proof of Actor возвращает одну из четырех classes для каждого interaction:

Human: наблюдаемые signals указывают на interaction, управляемое человеком.
Human + AI: человек направлял interaction с помощью AI, о чем было заявлено или что было обнаружено через поддерживаемую integration.
Agent: automated или origin из agent.
Unknown: evidence не позволяет надежно определить.

Каждый result также указывает свой evidence basis:

Verified: например, HTTP Message Signature (RFC 9421), проверенная по published key.
Declared: client или ваше собственное application это заявили.
Inferred: behavioral или contextual signals, явно помеченные как inference.
Unknown: надежного basis нет.

Для APIs verified basis особенно полезен. Agents, которые подписывают свои requests, можно проверять по их published keys, и именно этот подход лежит в основе работы IETF Web Bot Auth. См. пояснение Web Bot Auth для product teams для общего контекста и guide по проверке подписанных requests от agents для реализации.

Здесь важен один предел. Действительная signature доказывает, какой key подписал request. Она не доказывает, что agent authorized выполнять action. Authorization остается там, где и должна быть, в собственном access control вашего API. Запись agent authorization объясняет различие.

Scores и keys против actor evidence

Некоторые products для bot protection присваивают каждому request score. Score удобен для решения о block. Он менее полезен для решений о product API, потому что не говорит, был ли legit request driven человеком или agent, и не отделяет verified facts от inference.

API keys имеют противоположное ограничение. Они точно описывают ownership и молчат об actor. Key одного customer может нести все четыре classes в течение одного часа.

Proof of Actor сохраняет оба различия видимыми. Ваш API видит account из key, actor class из Proof of Actor и basis, который его поддерживает. Каждый слой отвечает на тот вопрос, в котором он силен.

Где работает каждый из них

Gateway и WAF работают на edge вашей сети или перед вашими services. Это правильное место для protection и quotas.

Proof of Actor работает там, где живет логика вашего API. Команды Founding могут интегрироваться через Node.js middleware, Next.js, edge layer под вашим контролем, generic HTTP API или integration для MCP server. Полный список см. в integrations. Поскольку он работает внутри вашего application, он может использовать то, что знает ваш API: route, workflow, заявил ли client о себе и была ли signature проверена.

Решения по routing остаются в вашем code

Proof of Actor по умолчанию ничего не блокирует. Он начинается в режиме observation, поэтому его установка ничего не меняет в том, как ваш API отвечает. Вы видите состав actor по endpoint, просматриваете evidence по отдельным results и отслеживаете свой Unknown rate.

Когда вы готовы, вы пишете policies, заданные application, для каждого route, каждого actor class и каждого basis. Типичные outcomes:

Allow: обслужить request обычным образом.
Adapt: вернуть структурированный или сокращенный response для verified agent.
Challenge: потребовать дополнительный шаг confirmation, например подтверждение человеком для важного write.
Review: поставить action в очередь для проверки человеком.
Rate-limit: применить более строгий limit к конкретному class и basis на конкретном route.

Вы можете preview policy на реальном traffic до enforcement, а затем включать enforcement по одному route за раз. Guide по безопасному внедрению actor-aware policies описывает процесс, а защита sensitive actions без блокировки agents показывает распространенные patterns.

Как обрабатывать Unknown API callers

Каждый API получает traffic, который нельзя классифицировать уверенно. При традиционных controls действительный key обычно означает, что request проходит, а недействительный - что не проходит. Между ними ничего нет.

Proof of Actor дает вам явный result Unknown и позволяет выбрать fallback для каждого route. Read-only catalog endpoints могут оставаться открытыми. Изменения account могут сохранить ваши существующие более строгие checks. Массовые exports могут уходить на review. Подробности см. в обработке Unknown traffic и неизвестном automated traffic.

Как они работают вместе

Самая сильная конфигурация API использует каждый слой по его прямому назначению:

На edge WAF фильтрует вредоносный и malformed traffic.
На gateway keys аутентифицируются, quotas применяются, а usage записывается.
Внутри API Proof of Actor классифицирует каждый request, который прошел дальше, и указывает его basis.
В ваших handlers policies используют class и basis, чтобы выбрать response: обычная обработка для human-driven call, структурированный response для verified agent, шаг confirmation для agent-driven high-impact write, fallback для Unknown.
В analytics ваша team видит, какие endpoints и workflows использует каждый actor class, вместе с account data из gateway.

В этом stack нет дублирования. Gateway знает account, WAF знает threat patterns, а Proof of Actor знает actor.

Когда на чем сосредоточиться

Сначала сосредоточьтесь на API bot protection, если ваши основные проблемы - abuse, availability или неограниченное usage: credential attacks против auth endpoints, агрессивный scraping или одна integration, вытесняющая другие.

Сосредоточьтесь на Proof of Actor, если ваши основные вопросы касаются callers: какая часть вашего API traffic обусловлена agents, какие agents вызывают какие endpoints, где usage, driven человеком, отличается от usage, driven agent, и какие routes требуют policy с учетом actor. Записи use case APIs и identification AI agent для APIs раскрывают тему глубже.

Большинству teams, работающих с production API, нужны ответы на оба вопроса.

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

Proof of Actor находится в private beta. Отобранные founding developer teams могут получить до 12 months бесплатного access в рамках согласованных limits usage, без автоматического billing. Подайте заявку на early access и расскажите нам об API и о callers, которых вы хотите понимать.

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

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 мой API gateway или WAF?

Нет. Ваш gateway по-прежнему аутентифицирует keys и применяет quotas, а ваш WAF по-прежнему фильтрует вредоносный traffic. Proof of Actor работает внутри вашего API и добавляет actor context к запросам, которые проходят дальше. Сохраняйте существующие controls.

Если у каждого caller есть API key, зачем мне нужен actor context?

API key идентифицирует account, которому принадлежит integration. Он не говорит, был ли конкретный request вызван человеком, который нажал кнопку в приложении вашего customer, человеком, использующим AI assistant, или автономным agent, выполняющим task. Proof of Actor сообщает это вместе с basis.

Может ли Proof of Actor проверить, какой agent вызывает мой API?

Когда client подписывает свои requests с помощью HTTP Message Signatures (RFC 9421) и публикует свой key, Proof of Actor проверяет signature и сообщает verified basis. Действительная signature доказывает, какой key подписал request. Она не доказывает, что agent уполномочен действовать, поэтому authorization остается в вашем code.

Начнет ли Proof of Actor применять rate-limiting или блокировать мой API traffic?

Нет. Он запускается в режиме observation и по умолчанию ничего не блокирует. Rate-limit - это один из outcomes, который вы можете выбрать в policy для конкретного route, actor class и basis, а enforcement находится в вашем собственном code.

Как добавить Proof of Actor в API?

Команды Founding могут использовать Node.js middleware, Next.js, edge integration или generic HTTP API. У MCP servers есть собственная integration. Подробности см. на странице integrations.

Что происходит с callers, которых нельзя классифицировать?

Они сообщаются как Unknown, как результат первого класса. Вы выбираете fallback для каждого route, например allow для read-only endpoints и сохраняете более строгие checks для write endpoints.

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

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

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

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