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

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

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

Полный набор инструментов для обеих сторон MCP-интеграции

Первая версия SDK была в основном клиентом проверки: MCP-сервер передавал подписанный запрос в AgentBouncer и получал итоговое решение.

В версии 0.2.0 SDK поддерживает обе стороны взаимодействия:

• AI-агенты могут создавать подписанные MCP-запросы;
• MCP-серверы могут проверять подписи и целостность тела запроса;
• пользовательский OAuth-токен может передаваться вместе с подтверждённой идентичностью агента.

Для исходящих запросов появились createAgentBouncerSigner(), AgentBouncerSigner, sign() и signJson(). При подписании запроса с телом SDK автоматически формирует Content-Digest и связывает подпись с HTTP-методом, публичным адресом, путём, содержимым запроса и заявленной идентичностью агента.

import {
  createAgentBouncerSigner,
} from "@agentbouncer/sdk";

const signer =
  createAgentBouncerSigner({
    privateJwk,
    keyId,
    signatureAgent:
      "https://agent.example.com",
  });

const request =
  await signer.signJson({
    url:
      "https://mcp.example.com/api/mcp/weather",
    method: "POST",
    json: {
      city: "Berlin",
    },
    accessToken:
      userOAuthAccessToken,
  });

const response = await fetch(request);

Проверка целостности тела запроса

Наличие подписанного Content-Digest имеет смысл только тогда, когда сервер сравнивает его с фактически полученным телом. Теперь AgentBouncer.verify() выполняет эту проверку локально до обращения к AgentBouncer Verify API.

Если тело было изменено после подписания, SDK возвращает:

{
  "verified": false,
  "allowed": false,
  "reason": "content_digest_mismatch"
}

При таком несоответствии удалённый API не вызывается. Это позволяет отклонить повреждённый запрос до того, как его подпись попадёт в хранилище защиты от повторного воспроизведения. Проверка Content-Digest включена по умолчанию.

Передача пользовательской OAuth-авторизации

Версия 0.2.0 добавляет поддержку сценариев, в которых необходимо проверить одновременно две стороны запроса:

1. AI-агента, подписавшего MCP-запрос;
2. пользователя, от имени которого агент выполняет действие.

SDK может извлечь bearer-токен из входящего заголовка Authorization и передать его в AgentBouncer отдельно от идентичности агента. Токен также можно предоставить явно через userToken, а автоматическую передачу — отключить с помощью forwardAuthorization: false.

Новые типы и функции isOAuthRequired(), isOAuthScopeDenied() и getRequiredOAuthScopes() помогают преобразовывать решения AgentBouncer в корректные OAuth-совместимые ответы 401 и 403. Сам OAuth-flow, включая редиректы, PKCE, callback-обработку и хранение токенов, остаётся ответственностью приложения.

Интерактивный мастер создания политик

Вместе с SDK мы обновили интерфейс управления политиками.

Новый пошаговый мастер помогает создавать правила доступа без необходимости начинать с большого JSON-документа или вручную собирать сложную конфигурацию. Он последовательно предлагает выбрать:

• кому разрешено или запрещено выполнять действие;
• к каким действиям применяется правило;
• какие MCP-инструменты оно охватывает;
• какой эффект должен использоваться — ALLOW или DENY;
• что должно происходить, если ни одно правило не совпало.

Это особенно полезно для MCP-серверов с большим количеством разных tools. Вместо одной общей политики для всего сервера разработчики могут быстрее создавать отдельные правила для поиска, чтения данных, отправки сообщений, работы с документами, платежей и других операций.

Более строгий профиль подписания

Новая версия усиливает целостность MCP-запросов. Рекомендуемый профиль подписи включает:

@method
@authority
@path
content-digest
signature-agent

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

Подписанный запрос также должен отправляться только один раз. Если сервер сообщает, что требуется OAuth-авторизация, после завершения OAuth-flow необходимо создать новую подпись, а не повторно использовать исходный запрос. Приватные JWK, ключи AgentBouncer и OAuth-токены должны храниться исключительно в серверной среде.

Обновление с версии 0.1.x

Существующие интеграции с verify() продолжают работать:

const verification =
  await agentBouncer.verify({
    request,
  });

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

• bearer-токен из Authorization автоматически передаётся как пользовательский OAuth-токен;
• если запрос содержит Content-Digest, SDK локально сравнивает его с фактическим телом.

Установить новую версию можно командой:

npm install @agentbouncer/sdk@0.2.0

AgentBouncer SDK 0.2.0 уже доступен в npm, а исходный код и полные release notes опубликованы в GitHub-репозитории.

Спасибо разработчикам MCP-серверов, которые продолжают делиться с нами своими сценариями и обратной связью. Мы будем и дальше развивать инструменты, помогающие проверять идентичность AI-агентов и управлять их доступом к отдельным действиям и MCP-инструментам.