Agent identity controlPlate 01

Решайте, каким AI-агентам разрешить действие

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

01

RFC 9421 HTTP Message Signatures

02

OAuth 2.1 + PKCE для пользователя

03

Replay protection для каждой подписи

04

Политики для API и MCP tools

Section 02

RFC 9421 verification path

От точных байтов запроса до финального allowed

AgentBouncer объединяет RFC 9421 HTTP Message Signature, RFC 9530 Content-Digest, Web Bot Auth-идентичность агента, OAuth 2.1-пользователя и правила конкретной API или MCP-операции.

01

raw request

Примите исходный HTTP-запрос

Сохраните точный внешний URL, HTTP-метод, исходные заголовки и байты тела до выполнения защищённой API или MCP-операции.

02

RFC 9421 · RFC 9530

Проверьте RFC 9421 и Content-Digest

Проверяются Signature-Input, Signature, временное окно, intent tag, подписанные компоненты и соответствие RFC 9530 Content-Digest фактическим байтам тела.

03

Web Bot Auth identity

Разрешите идентичность агента

AgentBouncer использует project signing key или публичный ключ зарегистрированного провайдера и проверяет, не была ли эта HTTP-подпись использована раньше.

04

OAuth 2.1 · PKCE

Проверьте OAuth 2.1-пользователя

Если правило требует пользователя, access token независимо проверяется по issuer, JWKS, audience, expiration и scopes. Authorization code flow использует PKCE.

05

policy decision

Примените политику к API или MCP tool

DENY и ALLOW правила учитывают агента, action, tool, trust-параметры и OAuth scopes, после чего возвращается финальное verification.allowed.

Verification sequencefinal output → allowed
Section 03Trust architecture

Web Bot Auth + OAuth 2.1

Агент, пользователь и проект — три независимых контура

AgentBouncer расширяет криптографическую идентичность автоматического клиента правилами для защищённых API и MCP tools. RFC 9421 идентифицирует агента, OAuth 2.1 представляет пользователя, а project API key выбирает политику защищённого сервера.

Архитектура независимой проверки RFC 9421-подписи агента, OAuth 2.1-пользователя и правил проекта

Private signing JWK остаётся у агента. Project API key остаётся на защищённом сервере. OAuth 2.1 access token представляет пользователя. Эти идентичности не взаимозаменяемы.

Agent · User · Project
01
agent

Криптографическая идентичность агента

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

RFC 9421Web Bot Auth identity
02
user

Независимая авторизация пользователя

OAuth-токен проверяется по issuer, JWKS, audience, expiration и scopes. Валидная подпись агента сама по себе не означает, что пользователь разрешил действие.

OAuth 2.1 + PKCEissuer · audience · scopes
03
authorization

Правила для конкретного действия

ALLOW и DENY правила учитывают тип агента, provider tier, project key, action, tool и OAuth-требования. DENY имеет приоритет.

CUSTOM policyaction и tool
04
request body

Целостность реального тела запроса

SDK сравнивает Content-Digest с точными входящими байтами до разбора JSON. Изменённое после подписания тело отклоняется локально.

RFC 9530Content-Digest
05
single use

Одна подпись — одна попытка

Успешно проверенная подпись потребляется replay protection. Повторная отправка, retry или запрос после OAuth требуют новой подписи.

single-use signaturenew request required
06
operations

События для расследований

Анализируйте verified, allowed, signer, risk, action, tool, OAuth status, policy result и replay-состояние. Данные можно экспортировать в CSV.

event logCSV export

Recommended rollout

Сначала наблюдайте. Затем включайте блокировку.

Запустите MONITOR_ONLY на реальном трафике, определите действия, инструменты, OAuth scopes и доверенные идентичности, после чего переходите к строгой политике.

Изучить политики
Раздел 04

OAuth 2.1 для MCP

OAuth-пользователь не заменяет RFC 9421-подпись агента

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-подписью.

Последовательность авторизацииRequest A ≠ Request B
01RFC 9421

AI-агент

Request A

Создаётся подписанный запрос без пользовательского access token.

02Проверка

AgentBouncer

Подпись действительна

Проверяются идентичность агента, Content-Digest и состояние защиты от повторных запросов.

Подпись A уже использована

03HTTP 401

Политика проекта

Требуется OAuth

Политика требует независимо авторизованную идентичность пользователя.

04OAuth 2.1

OAuth и пользователь

PKCE

Пользователь разрешает доступ, после чего клиент получает короткоживущий токен.

05Новая подпись

AI-агент

Request B

Создаются совершенно новый запрос и новая HTTP-подпись.

Токен прикладывается после подписания

06Финальная проверка

AgentBouncer

Allowed = true

Агент, пользователь, области доступа и политика проекта проверяются независимо.

OAuth access token представляет пользователя. Подпись RFC 9421 представляет агента. Политика проекта может требовать одновременной проверки обеих идентичностей.

OAuth 2.1 · PKCE · MCP
I

Запрос RFC 9421

Агент отправляет Request A

AgentBouncer проверяет HTTP Message Signature, Content-Digest и идентичность агента. Если политика проекта требует пользователя, возвращается HTTP 401 с причиной oauth_token_required.

II

OAuth 2.1 и PKCE

Пользователь разрешает доступ

MCP-клиент запускает authorization code flow с PKCE, получает согласие пользователя и короткоживущий access token для нужного ресурса и областей доступа.

III

Новая подпись RFC 9421

Агент создаёт Request B

Создаются новый запрос и новая подпись. Authorization bearer token прикладывается после подписания, а AgentBouncer независимо проверяет агента, пользователя, области доступа и политику проекта.

Section 05

Интеграция

Одна проверка перед выполнением защищённого кода

SDK проверяет RFC 9421 HTTP Message Signature, RFC 9530 Content-Digest, replay protection, OAuth 2.1 access token и project policy, после чего возвращает полную структуру решения.

01

Проверяйте исходный Request до request.json(), чтобы RFC 9530 Content-Digest сравнивался с фактическими входящими байтами.

02

Создавайте новую RFC 9421-подпись для каждого запроса, retry и повторной попытки после OAuth 2.1.

03

Передавайте action и tool, чтобы применять project policy к конкретной API или MCP-операции.

04

Используйте 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,
        });
      }
npm install @agentbouncer/sdk@0.2.0RFC 9421 · RFC 9530 · OAuth 2.1
decision → verification.allowed
Section 06Access program

Начните с реального защищённого действия

Присоединитесь к открытой бете или запустите Enterprise-пилот

Мы постепенно открываем доступ проектам, которые защищают AI-agent API, MCP tools и автономные операции.

Бесплатно во время беты

Open beta

Открытая бета

Расскажите о вашем API, MCP server или agent workflow. После рассмотрения заявки мы отправим приглашение и поможем выбрать первый сценарий интеграции.

Доступ к AgentBouncer и SDK во время открытой беты.

Проверка первого endpoint в режиме MONITOR_ONLY.

Обратная связь напрямую команде продукта.

По запросу

Enterprise

Enterprise-пилот

Для команд с несколькими агентами, собственными MCP-серверами, OAuth-инфраструктурой или особыми требованиями к политикам доступа.

Разбор trust architecture и модели угроз.

Проектирование agent, user и project policy integration.

Индивидуальный план пилотного внедрения.

Заявка на открытую бету не создаёт аккаунт автоматически. Доступ предоставляется по приглашению после рассмотрения сценария.

Application → Review → Invitation
Section 06Field notes

Заметки AgentBouncer

Обновления сервиса, безопасность MCP и развитие стандартов для AI-агентов.

01
A2A и межагентное взаимодействие: как AI-агенты находят друг друга и делегируют задачи
Знания

A2A и межагентное взаимодействие: как AI-агенты находят друг друга и делегируют задачи

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

02
Что такое Web Bot Auth: аутентификация AI-ботов
Знания

Что такое Web Bot Auth: аутентификация AI-ботов

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

03
Аутентификация и авторизация AI-агентов: в чём разница
Знания

Аутентификация и авторизация AI-агентов: в чём разница

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

04
Аутентификация AI-агентов: identity, OAuth и контроль доступа
Знания

Аутентификация AI-агентов: identity, OAuth и контроль доступа

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

05
AgentBouncer SDK 0.2.0: подписание MCP-запросов, поддержка OAuth и новый мастер политик
Новости

AgentBouncer SDK 0.2.0: подписание MCP-запросов, поддержка OAuth и новый мастер политик

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

06
AgentBouncer запускает публичную бету и SDK для проверки запросов AI-агентов
Новости

AgentBouncer запускает публичную бету и SDK для проверки запросов AI-агентов

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