Agent identity controlPlate 01

Decide a qué agentes de IA permitir actuar

System abstract

AgentBouncer verifica la identidad de un agente de IA mediante HTTP Message Signatures según RFC 9421, vincula la firma al cuerpo mediante Content-Digest según RFC 9530, valida de forma independiente al usuario de OAuth 2.1 y aplica las políticas del proyecto. La API protegida o la herramienta MCP recibe una única decisión final: 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 para el usuario

03

Protección contra repeticiones para cada firma

04

Políticas para API y herramientas MCP

Section 02

Ruta de verificación RFC 9421

Desde los bytes exactos de la solicitud hasta el allowed final

AgentBouncer combina HTTP Message Signatures de RFC 9421, Content-Digest de RFC 9530, identidad de agente mediante Web Bot Auth, un usuario de OAuth 2.1 y reglas para una operación concreta de API o MCP.

01

solicitud sin procesar

Recibe la solicitud HTTP sin procesar

Conserva la URL externa exacta, el método HTTP, los encabezados originales y los bytes del cuerpo antes de ejecutar la operación protegida de API o MCP.

02

RFC 9421 · RFC 9530

Verifica RFC 9421 y Content-Digest

Se verifican Signature-Input, Signature, la ventana temporal, la etiqueta de intención, los componentes firmados y la coincidencia del Content-Digest de RFC 9530 con los bytes reales del cuerpo.

03

Identidad Web Bot Auth

Resuelve la identidad del agente

AgentBouncer utiliza una clave de firma del proyecto o una clave pública de un proveedor registrado y verifica que la firma HTTP no se haya utilizado antes.

04

OAuth 2.1 · PKCE

Verifica al usuario de OAuth 2.1

Si la política requiere un usuario, el access token se verifica de forma independiente por issuer, JWKS, audience, expiración y scopes. El flujo de código de autorización utiliza PKCE.

05

decisión de política

Aplica la política a la API o herramienta MCP

Las reglas DENY y ALLOW tienen en cuenta el agente, la acción, la herramienta, los parámetros de confianza y los scopes de OAuth, y luego devuelven el verification.allowed final.

Verification sequencefinal output → allowed
Section 03Trust architecture

Web Bot Auth + OAuth 2.1

Agente, usuario y proyecto: tres capas independientes

AgentBouncer amplía la identidad criptográfica de un cliente automatizado con reglas para API protegidas y herramientas MCP. RFC 9421 identifica al agente, OAuth 2.1 representa al usuario y la clave API del proyecto selecciona la política del servidor protegido.

Arquitectura de verificación independiente de la firma de agente RFC 9421, el usuario OAuth 2.1 y la política del proyecto

El JWK de firma privado permanece en el agente. La clave API del proyecto permanece en el servidor protegido. El access token de OAuth 2.1 representa al usuario. Estas identidades no son intercambiables.

Agent · User · Project
01
agent

Identidad criptográfica del agente

Permite claves de firma del proyecto para tus propios agentes o claves públicas de proveedores registrados. La firma se vincula a la URL, el método y el cuerpo de solicitud exactos.

RFC 9421Identidad Web Bot Auth
02
user

Autorización independiente del usuario

El token OAuth se verifica por issuer, JWKS, audience, expiración y scopes. Una firma válida del agente por sí sola no significa que el usuario haya autorizado la acción.

OAuth 2.1 + PKCEissuer · audience · scopes
03
authorization

Reglas para una acción específica

Las reglas ALLOW y DENY tienen en cuenta el tipo de agente, el nivel del proveedor, la clave del proyecto, la acción, la herramienta y los requisitos de OAuth. DENY tiene prioridad.

Política PERSONALIZADAacción y herramienta
04
request body

Integridad del cuerpo real de la solicitud

El SDK compara Content-Digest con los bytes entrantes exactos antes de analizar JSON. Un cuerpo modificado después de la firma se rechaza localmente.

RFC 9530Content-Digest
05
single use

Una firma, un intento

Una firma verificada correctamente se consume mediante la protección contra repeticiones. Un reenvío, reintento o solicitud después de OAuth requiere una firma nueva.

firma de un solo usose requiere una nueva solicitud
06
operations

Eventos para investigaciones

Analiza verified, allowed, signer, risk, action, tool, estado de OAuth, resultado de la política y estado de repetición. Los datos se pueden exportar a CSV.

registro de eventosexportación CSV

Recommended rollout

Primero observa. Después activa el bloqueo.

Ejecuta MONITOR_ONLY con tráfico real, identifica acciones, herramientas, scopes de OAuth e identidades de confianza, y luego pasa a una política estricta.

Explorar políticas
Sección 04

OAuth 2.1 para MCP

El usuario de OAuth no sustituye la firma de agente RFC 9421

Una HTTP Message Signature de RFC 9421 responde a la pregunta «¿qué cliente automatizado envió la solicitud?». Un access token de OAuth 2.1 responde a otra pregunta: «¿qué usuario autorizó a ese cliente a acceder al recurso MCP?». La política del proyecto puede requerir ambas identidades simultáneamente.

Regla crítica de integración

La Request A puede verificarse criptográficamente y ser consumida por la protección contra repeticiones antes de devolver la respuesta oauth_token_required. Después del flujo de código de autorización OAuth 2.1 con PKCE, el agente debe crear la Request B con una firma RFC 9421 completamente nueva.

Secuencia de autorizaciónRequest A ≠ Request B
01RFC 9421

Agente de IA

Request A

Se crea una solicitud firmada sin un access token de usuario.

02Verificación

AgentBouncer

La firma es válida

Se verifican la identidad del agente, Content-Digest y el estado de la protección contra repeticiones.

La firma A ya se ha consumido

03HTTP 401

Política del proyecto

Se requiere OAuth

La política requiere una identidad de usuario autorizada de forma independiente.

04OAuth 2.1

OAuth y usuario

PKCE

El usuario autoriza el acceso, tras lo cual el cliente recibe un token de corta duración.

05Nueva firma

Agente de IA

Request B

Se crean una solicitud completamente nueva y una nueva firma HTTP.

El token se adjunta después de firmar

06Verificación final

AgentBouncer

Allowed = true

El agente, el usuario, los scopes y la política del proyecto se verifican de forma independiente.

El access token de OAuth representa al usuario. La firma RFC 9421 representa al agente. La política del proyecto puede requerir la verificación simultánea de ambas identidades.

OAuth 2.1 · PKCE · MCP
I

Solicitud RFC 9421

El agente envía la Request A

AgentBouncer verifica la HTTP Message Signature, el Content-Digest y la identidad del agente. Si la política del proyecto requiere un usuario, devuelve HTTP 401 con la razón oauth_token_required.

II

OAuth 2.1 y PKCE

El usuario autoriza el acceso

El cliente MCP inicia el flujo de código de autorización con PKCE, obtiene el consentimiento del usuario y recibe un access token de corta duración para el recurso y los scopes requeridos.

III

Nueva firma RFC 9421

El agente crea la Request B

Se crean una nueva solicitud y una nueva firma. El bearer token de Authorization se adjunta después de firmar, y AgentBouncer verifica de forma independiente el agente, el usuario, los scopes y la política del proyecto.

Section 05

Integración

Una verificación antes de ejecutar código protegido

El SDK verifica la HTTP Message Signature de RFC 9421, el Content-Digest de RFC 9530, la protección contra repeticiones, el access token de OAuth 2.1 y la política del proyecto, y después devuelve la estructura completa de la decisión.

01

Verifica el Request sin procesar antes de request.json() para que el Content-Digest de RFC 9530 se compare con los bytes entrantes reales.

02

Crea una nueva firma RFC 9421 para cada solicitud, reintento e intento repetido después de OAuth 2.1.

03

Transmite action y tool para aplicar la política del proyecto a una operación concreta de API o MCP.

04

Usa verification.allowed como el único control final de autorización.

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

Comienza con una acción protegida real

Únete a la beta abierta o inicia un piloto Enterprise

Estamos abriendo gradualmente el acceso a proyectos que protegen API de agentes de IA, herramientas MCP y operaciones autónomas.

Gratis durante la beta

Open beta

Beta abierta

Cuéntanos sobre tu API, servidor MCP o flujo de trabajo de agentes. Tras revisar tu solicitud, te enviaremos una invitación y te ayudaremos a elegir tu primer escenario de integración.

Acceso a AgentBouncer y al SDK durante la beta abierta.

Verificación del primer endpoint en modo MONITOR_ONLY.

Comentarios directos para el equipo de producto.

Bajo solicitud

Enterprise

Piloto Enterprise

Para equipos con varios agentes, servidores MCP propios, infraestructura OAuth o requisitos especiales de políticas de acceso.

Revisión de la arquitectura de confianza y del modelo de amenazas.

Diseño de la integración de políticas de agente, usuario y proyecto.

Plan personalizado de implementación del piloto.

La solicitud para la beta abierta no crea una cuenta automáticamente. El acceso se concede por invitación después de revisar el caso de uso.

Application → Review → Invitation