RFC 9421
Подписанный агент
Криптографическая идентичность автоматического клиента.
System abstract
AgentBouncer проверяет идентичность AI-агента через HTTP Message Signatures по RFC 9421, связывает подпись с телом через Content-Digest по RFC 9530, независимо валидирует OAuth 2.1-пользователя и применяет правила проекта. Защищённый API или MCP-инструмент получает одно финальное решение — allowed.
RFC 9421
HTTP Message Signatures
RFC 9530
Content-Digest
IETF DRAFT
Web Bot Auth
AUTHORIZATION
OAuth 2.1 + PKCE
RFC 9421
Криптографическая идентичность автоматического клиента.
OAuth 2.1
Независимая пользовательская идентичность и scopes.
Project policy
Action, tool, trust-параметры и OAuth-требования.
AgentBouncer
Только allowed является финальным решением
Protected operation
API или MCP tool выполняется только после положительного решения.
Идентичность агента, авторизация пользователя и правила проекта проверяются независимо и объединяются в одно финальное решение.
RFC 9421 · OAuth · PolicyRFC 9421 HTTP Message Signatures
OAuth 2.1 + PKCE для пользователя
Replay protection для каждой подписи
Политики для API и MCP tools
RFC 9421 verification path
AgentBouncer объединяет RFC 9421 HTTP Message Signature, RFC 9530 Content-Digest, Web Bot Auth-идентичность агента, OAuth 2.1-пользователя и правила конкретной API или MCP-операции.
raw request
Сохраните точный внешний URL, HTTP-метод, исходные заголовки и байты тела до выполнения защищённой API или MCP-операции.
RFC 9421 · RFC 9530
Проверяются Signature-Input, Signature, временное окно, intent tag, подписанные компоненты и соответствие RFC 9530 Content-Digest фактическим байтам тела.
Web Bot Auth identity
AgentBouncer использует project signing key или публичный ключ зарегистрированного провайдера и проверяет, не была ли эта HTTP-подпись использована раньше.
OAuth 2.1 · PKCE
Если правило требует пользователя, access token независимо проверяется по issuer, JWKS, audience, expiration и scopes. Authorization code flow использует PKCE.
policy decision
DENY и ALLOW правила учитывают агента, action, tool, trust-параметры и OAuth scopes, после чего возвращается финальное verification.allowed.
Web Bot Auth + OAuth 2.1
AgentBouncer расширяет криптографическую идентичность автоматического клиента правилами для защищённых API и MCP tools. RFC 9421 идентифицирует агента, OAuth 2.1 представляет пользователя, а project API key выбирает политику защищённого сервера.

Private signing JWK остаётся у агента. Project API key остаётся на защищённом сервере. OAuth 2.1 access token представляет пользователя. Эти идентичности не взаимозаменяемы.
Agent · User · ProjectРазрешайте project signing keys для собственных агентов или публичные ключи зарегистрированных провайдеров. Подпись связывается с точным URL, методом и телом запроса.
OAuth-токен проверяется по issuer, JWKS, audience, expiration и scopes. Валидная подпись агента сама по себе не означает, что пользователь разрешил действие.
ALLOW и DENY правила учитывают тип агента, provider tier, project key, action, tool и OAuth-требования. DENY имеет приоритет.
SDK сравнивает Content-Digest с точными входящими байтами до разбора JSON. Изменённое после подписания тело отклоняется локально.
Успешно проверенная подпись потребляется replay protection. Повторная отправка, retry или запрос после OAuth требуют новой подписи.
Анализируйте verified, allowed, signer, risk, action, tool, OAuth status, policy result и replay-состояние. Данные можно экспортировать в CSV.
Recommended rollout
Запустите MONITOR_ONLY на реальном трафике, определите действия, инструменты, OAuth scopes и доверенные идентичности, после чего переходите к строгой политике.
OAuth 2.1 для MCP
HTTP Message Signature по RFC 9421 отвечает на вопрос «какой автоматический клиент отправил запрос». OAuth 2.1 access token отвечает на другой вопрос — «какой пользователь разрешил этому клиенту доступ к MCP-ресурсу». Политика проекта может потребовать обе идентичности одновременно.
Критическое правило интеграции
Request A может быть криптографически проверен и учтён системой защиты от повторных запросов ещё до ответа oauth_token_required. После OAuth 2.1 authorization code flow с PKCE агент обязан создать Request B с совершенно новой RFC 9421-подписью.
AI-агент
Создаётся подписанный запрос без пользовательского access token.
AgentBouncer
Проверяются идентичность агента, Content-Digest и состояние защиты от повторных запросов.
Подпись A уже использована
Политика проекта
Политика требует независимо авторизованную идентичность пользователя.
OAuth и пользователь
Пользователь разрешает доступ, после чего клиент получает короткоживущий токен.
AI-агент
Создаются совершенно новый запрос и новая HTTP-подпись.
Токен прикладывается после подписания
AgentBouncer
Агент, пользователь, области доступа и политика проекта проверяются независимо.
OAuth access token представляет пользователя. Подпись RFC 9421 представляет агента. Политика проекта может требовать одновременной проверки обеих идентичностей.
OAuth 2.1 · PKCE · MCPЗапрос RFC 9421
AgentBouncer проверяет HTTP Message Signature, Content-Digest и идентичность агента. Если политика проекта требует пользователя, возвращается HTTP 401 с причиной oauth_token_required.
OAuth 2.1 и PKCE
MCP-клиент запускает authorization code flow с PKCE, получает согласие пользователя и короткоживущий access token для нужного ресурса и областей доступа.
Новая подпись RFC 9421
Создаются новый запрос и новая подпись. Authorization bearer token прикладывается после подписания, а AgentBouncer независимо проверяет агента, пользователя, области доступа и политику проекта.
Интеграция
SDK проверяет RFC 9421 HTTP Message Signature, RFC 9530 Content-Digest, replay protection, OAuth 2.1 access token и project policy, после чего возвращает полную структуру решения.
Проверяйте исходный Request до request.json(), чтобы RFC 9530 Content-Digest сравнивался с фактическими входящими байтами.
Создавайте новую RFC 9421-подпись для каждого запроса, retry и повторной попытки после OAuth 2.1.
Передавайте action и tool, чтобы применять project policy к конкретной API или MCP-операции.
Используйте verification.allowed как единственный финальный authorization gate.
import {
createAgentBouncer,
getRequiredOAuthScopes,
isOAuthRequired,
isOAuthScopeDenied,
} from "@agentbouncer/sdk";
const agentBouncer = createAgentBouncer({
apiKey: process.env.AGENTBOUNCER_API_KEY!,
publicOrigin:
process.env.AGENTBOUNCER_PUBLIC_ORIGIN,
validateContentDigest: true,
});
export async function POST(request: Request) {
// Verify before reading the body.
const verification =
await agentBouncer.verify({
request,
expectedTag: "web-bot-auth",
action: "tools:call",
tool: "weather",
forwardAuthorization: true,
});
if (!verification.allowed) {
const oauthRequired =
isOAuthRequired(verification);
const scopeDenied =
isOAuthScopeDenied(verification);
return Response.json(
{
error: oauthRequired
? "oauth_required"
: scopeDenied
? "insufficient_scope"
: "agent_access_denied",
requiredScopes: oauthRequired
? getRequiredOAuthScopes(verification)
: undefined,
},
{
status: oauthRequired ? 401 : 403,
headers: {
"Cache-Control": "no-store",
},
}
);
}
const body = await request.json();
return Response.json({
ok: true,
city: body.city,
agent: verification.agent,
user: verification.oauth,
});
}Начните с реального защищённого действия
Мы постепенно открываем доступ проектам, которые защищают AI-agent API, MCP tools и автономные операции.
Open beta
Расскажите о вашем API, MCP server или agent workflow. После рассмотрения заявки мы отправим приглашение и поможем выбрать первый сценарий интеграции.
Доступ к AgentBouncer и SDK во время открытой беты.
Проверка первого endpoint в режиме MONITOR_ONLY.
Обратная связь напрямую команде продукта.
Enterprise
Для команд с несколькими агентами, собственными MCP-серверами, OAuth-инфраструктурой или особыми требованиями к политикам доступа.
Разбор trust architecture и модели угроз.
Проектирование agent, user и project policy integration.
Индивидуальный план пилотного внедрения.
Заявка на открытую бету не создаёт аккаунт автоматически. Доступ предоставляется по приглашению после рассмотрения сценария.
Application → Review → InvitationОбновления сервиса, безопасность MCP и развитие стандартов для AI-агентов.

Agent2Agent Protocol, или A2A, — открытый протокол для взаимодействия независимых AI-агентов. Он определяет, как клиент обнаруживает возможности удалённого агента, выбирает совместимый интерфейс, передаёт сообщение, отслеживает выполнение задачи и получает результат. A2A не требует, чтобы участники…

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

Обновлено 1 августа 2026 года Аутентификация AI-агента подтверждает, кто отправил запрос и каким приватным ключом владеет отправитель. Авторизация определяет, что этому агенту разрешено делать от имени пользователя, с конкретным ресурсом, инструментом и параметрами операции. Валидная подпись или…

Коротко Аутентификация AI-агента подтверждает, каким криптографическим ключом подписан запрос. Затем сервер связывает этот ключ с агентом, провайдером или конкретным развёртыванием. OAuth-токен не заменяет identity агента: он передаёт полномочия пользователя, но обычный bearer-токен может…

21 июля 2026 года мы выпустили @agentbouncer/sdk версии 0.2.0 и обновили инструменты управления политиками AgentBouncer. SDK теперь поддерживает не только проверку входящих запросов, но и их серверное подписание, контроль целостности тела и передачу пользовательских OAuth-токенов. С момента запуска…

AgentBouncer запускает публичную бету Мы открываем публичное бета-тестирование AgentBouncer — сервиса для проверки подписанных запросов от AI-агентов и управления доступом к API и MCP-инструментам. Вместе с запуском беты мы выпускаем первую версию JavaScript/TypeScript SDK, публикуем документацию и…