Agent identity controlPlate 01

Decide which AI agents to allow to take action

System abstract

AgentBouncer verifies an AI agent's identity using HTTP Message Signatures under RFC 9421, binds the signature to the body using Content-Digest under RFC 9530, independently validates the OAuth 2.1 user, and applies project policies. The protected API or MCP tool receives one final decision — 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 for the user

03

Replay protection for every signature

04

Policies for APIs and MCP tools

Section 02

RFC 9421 verification path

From exact request bytes to final allowed

AgentBouncer combines RFC 9421 HTTP Message Signatures, RFC 9530 Content-Digest, Web Bot Auth agent identity, an OAuth 2.1 user, and rules for a specific API or MCP operation.

01

raw request

Receive the raw HTTP request

Preserve the exact external URL, HTTP method, original headers, and body bytes before performing the protected API or MCP operation.

02

RFC 9421 · RFC 9530

Verify RFC 9421 and Content-Digest

Signature-Input, Signature, the time window, intent tag, signed components, and compliance of the RFC 9530 Content-Digest with the actual body bytes are verified.

03

Web Bot Auth identity

Resolve the agent identity

AgentBouncer uses a project signing key or a public key from a registered provider and verifies that the HTTP signature has not been used before.

04

OAuth 2.1 · PKCE

Verify the OAuth 2.1 user

If the policy requires a user, the access token is independently verified against the issuer, JWKS, audience, expiration, and scopes. The authorization code flow uses PKCE.

05

policy decision

Apply policy to the API or MCP tool

DENY and ALLOW rules consider the agent, action, tool, trust parameters, and OAuth scopes, then return the final verification.allowed.

Verification sequencefinal output → allowed
Section 03Trust architecture

Web Bot Auth + OAuth 2.1

Agent, user, and project — three independent layers

AgentBouncer extends the cryptographic identity of an automated client with rules for protected APIs and MCP tools. RFC 9421 identifies the agent, OAuth 2.1 represents the user, and the project API key selects the protected server's policy.

Architecture for independent verification of the RFC 9421 agent signature, OAuth 2.1 user, and project policy

The private signing JWK remains with the agent. The project API key remains on the protected server. The OAuth 2.1 access token represents the user. These identities are not interchangeable.

Agent · User · Project
01
agent

Cryptographic agent identity

Allow project signing keys for your own agents or public keys from registered providers. The signature is bound to the exact URL, method, and request body.

RFC 9421Web Bot Auth identity
02
user

Independent user authorization

The OAuth token is verified against the issuer, JWKS, audience, expiration, and scopes. A valid agent signature alone does not mean that the user authorized the action.

OAuth 2.1 + PKCEissuer · audience · scopes
03
authorization

Rules for a specific action

ALLOW and DENY rules consider the agent type, provider tier, project key, action, tool, and OAuth requirements. DENY takes precedence.

CUSTOM policyaction and tool
04
request body

Integrity of the actual request body

The SDK compares Content-Digest with the exact incoming bytes before parsing JSON. A body modified after signing is rejected locally.

RFC 9530Content-Digest
05
single use

One signature — one attempt

A successfully verified signature is consumed by replay protection. A resend, retry, or request after OAuth requires a new signature.

single-use signaturenew request required
06
operations

Events for investigations

Analyze verified, allowed, signer, risk, action, tool, OAuth status, policy result, and replay state. Data can be exported to CSV.

event logCSV export

Recommended rollout

Observe first. Then enable blocking.

Run MONITOR_ONLY on real traffic, identify actions, tools, OAuth scopes, and trusted identities, then move to a strict policy.

Explore policies
Section 04

OAuth 2.1 for MCP

The OAuth user does not replace the RFC 9421 agent signature

An RFC 9421 HTTP Message Signature answers the question, “Which automated client sent the request?” An OAuth 2.1 access token answers a different question: “Which user authorized that client to access the MCP resource?” Project policy may require both identities at the same time.

Critical integration rule

Request A may be cryptographically verified and consumed by replay protection before the oauth_token_required response is returned. After the OAuth 2.1 authorization code flow with PKCE, the agent must create Request B with an entirely new RFC 9421 signature.

Authorization sequenceRequest A ≠ Request B
01RFC 9421

AI agent

Request A

A signed request is created without a user access token.

02Verification

AgentBouncer

Signature is valid

The agent identity, Content-Digest, and replay-protection state are verified.

Signature A has already been consumed

03HTTP 401

Project policy

OAuth required

The policy requires an independently authorized user identity.

04OAuth 2.1

OAuth and user

PKCE

The user authorizes access, after which the client receives a short-lived token.

05New signature

AI agent

Request B

An entirely new request and HTTP signature are created.

The token is attached after signing

06Final verification

AgentBouncer

Allowed = true

The agent, user, scopes, and project policy are verified independently.

The OAuth access token represents the user. The RFC 9421 signature represents the agent. Project policy may require simultaneous verification of both identities.

OAuth 2.1 · PKCE · MCP
I

RFC 9421 request

The agent sends Request A

AgentBouncer verifies the HTTP Message Signature, Content-Digest, and agent identity. If the project policy requires a user, it returns HTTP 401 with the oauth_token_required reason.

II

OAuth 2.1 and PKCE

The user authorizes access

The MCP client starts the authorization code flow with PKCE, obtains user consent, and receives a short-lived access token for the required resource and scopes.

III

New RFC 9421 signature

The agent creates Request B

A new request and a new signature are created. The Authorization bearer token is attached after signing, while AgentBouncer independently verifies the agent, user, scopes, and project policy.

Section 05

Integration

One verification before executing protected code

The SDK verifies the RFC 9421 HTTP Message Signature, RFC 9530 Content-Digest, replay protection, OAuth 2.1 access token, and project policy, then returns the full decision structure.

01

Verify the raw Request before request.json() so that the RFC 9530 Content-Digest is compared with the actual incoming bytes.

02

Create a new RFC 9421 signature for every request, retry, and repeated attempt after OAuth 2.1.

03

Pass action and tool to apply project policy to a specific API or MCP operation.

04

Use verification.allowed as the only final 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

Start with a real protected action

Join the open beta or launch an Enterprise pilot

We are gradually opening access to projects that protect AI-agent APIs, MCP tools, and autonomous operations.

Free during beta

Open beta

Open beta

Tell us about your API, MCP server, or agent workflow. After reviewing your application, we'll send an invitation and help you choose your first integration scenario.

Access to AgentBouncer and the SDK during the open beta.

Verification of your first endpoint in MONITOR_ONLY mode.

Direct feedback to the product team.

On request

Enterprise

Enterprise pilot

For teams with multiple agents, custom MCP servers, OAuth infrastructure, or special access-policy requirements.

Review of the trust architecture and threat model.

Design of agent, user, and project policy integration.

A tailored pilot implementation plan.

An open beta application does not automatically create an account. Access is granted by invitation after your use case has been reviewed.

Application → Review → Invitation
Section 06Field notes

AgentBouncer Field Notes

Product updates, MCP security, and the evolving standards for AI agents.