RFC 9421
Agente firmado
Identidad criptográfica de un cliente automatizado.
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
RFC 9421
Identidad criptográfica de un cliente automatizado.
OAuth 2.1
Identidad y ámbitos de acceso independientes del usuario.
Política del proyecto
Acción, herramienta, parámetros de confianza y requisitos de OAuth.
AgentBouncer
Solo allowed es la decisión final
Operación protegida
La API o herramienta MCP se ejecuta solo después de una decisión positiva.
La identidad del agente, la autorización del usuario y la política del proyecto se verifican de forma independiente y se combinan en una única decisión final.
RFC 9421 · OAuth · PolicyRFC 9421 HTTP Message Signatures
OAuth 2.1 + PKCE para el usuario
Protección contra repeticiones para cada firma
Políticas para API y herramientas MCP
Ruta de verificación RFC 9421
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.
solicitud 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.
RFC 9421 · RFC 9530
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.
Identidad Web Bot Auth
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.
OAuth 2.1 · PKCE
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.
decisión de política
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.
Web Bot Auth + OAuth 2.1
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.

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 · ProjectPermite 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.
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.
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.
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.
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.
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.
Recommended rollout
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.
OAuth 2.1 para MCP
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.
Agente de IA
Se crea una solicitud firmada sin un access token de usuario.
AgentBouncer
Se verifican la identidad del agente, Content-Digest y el estado de la protección contra repeticiones.
La firma A ya se ha consumido
Política del proyecto
La política requiere una identidad de usuario autorizada de forma independiente.
OAuth y usuario
El usuario autoriza el acceso, tras lo cual el cliente recibe un token de corta duración.
Agente de IA
Se crean una solicitud completamente nueva y una nueva firma HTTP.
El token se adjunta después de firmar
AgentBouncer
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 · MCPSolicitud RFC 9421
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.
OAuth 2.1 y PKCE
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.
Nueva firma RFC 9421
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.
Integración
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.
Verifica el Request sin procesar antes de request.json() para que el Content-Digest de RFC 9530 se compare con los bytes entrantes reales.
Crea una nueva firma RFC 9421 para cada solicitud, reintento e intento repetido después de OAuth 2.1.
Transmite action y tool para aplicar la política del proyecto a una operación concreta de API o MCP.
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,
});
}Comienza con una acción protegida real
Estamos abriendo gradualmente el acceso a proyectos que protegen API de agentes de IA, herramientas MCP y operaciones autónomas.
Open beta
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.
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