Una identidad X.509 permite verificar qué agente ha firmado una solicitud. En el ejemplo de referencia que AWS publicó el 20 de octubre de 2026, cada agente usa un certificado y sus peticiones pasan por controles de firma, delegación del usuario y revocación. MCP define por separado una autorización OAuth opcional para transportes HTTP.
La diferencia importa al conectar agentes con herramientas: autorizar el transporte no identifica por sí solo qué agente ha firmado una petición. AWS presenta una arquitectura de referencia, no un despliegue en producción.
Qué aporta X.509 a la identidad de los agentes
La arquitectura organiza la confianza en tres límites: usuario y sistema, agente y agente, y agente y servidor MCP. Para gestionarlos, AWS combina certificados X.509, solicitudes firmadas, una delegación firmada por el usuario, tokens con audiencia limitada y consultas OCSP, el protocolo que permite comprobar si un certificado se ha revocado.
Cada control atiende una parte distinta del recorrido. El certificado vincula la petición con la identidad criptográfica del agente; la delegación registra qué agentes ha autorizado el usuario; y el token limita el servicio al que puede dirigirse la sesión. El servidor de herramientas comprueba después esos elementos antes de aceptar la operación.
MCP autoriza el transporte; X.509 identifica al agente
La especificación de MCP contempla autorización OAuth opcional para transportes HTTP. Para las implementaciones que usan STDIO, recomienda obtener las credenciales del entorno en lugar de usar ese mecanismo. Esa autorización de transporte no reemplaza los certificados de agente, las solicitudes firmadas entre agentes ni la delegación del usuario del ejemplo de AWS. La especificación de autorización de MCP define el alcance de cada transporte.
| Mecanismo | Alcance | Qué controla | Transporte o límite de confianza |
| Autorización de MCP | Autorización OAuth opcional | Acceso al servidor mediante el flujo de autorización del transporte | HTTP; en STDIO se usan credenciales del entorno |
| Patrón X.509 de AWS | Identidad de agentes y autorización delegada | Certificados de agente, peticiones firmadas, delegación y validación de tokens | Usuario-sistema, agente-agente y agente-servidor MCP |
Cómo se valida una solicitud
AWS describe una cadena que empieza con el inicio de sesión del usuario en Keycloak. Después, el sistema intercambia el token mediante RFC 8693 para limitar su audiencia al servidor MCP; los agentes no reciben el token de sesión completo.
La aplicación genera localmente un par de claves RSA de 2048 bits o más y envía a EJBCA una solicitud de firma de certificado. La clave privada no se envía a EJBCA ni se comparte entre agentes. El usuario firma una declaración de delegación que identifica los certificados de agente mediante sus huellas SHA-256 e incluye el sujeto del usuario, la fecha de emisión y la caducidad.
Cuando un agente solicita una herramienta, firma con RSA-PSS-SHA256 la carga útil, el nombre de la herramienta, sus argumentos, la marca temporal y un valor aleatorio de un solo uso, llamado nonce. El servidor MCP comprueba el token y su audiencia, la firma y vigencia de la solicitud, la delegación, la cadena de certificados y la coherencia entre el usuario del token, el sujeto de la delegación y el nombre del certificado del agente.
Tres límites de confianza ordenan el flujo de AWS
En cada límite se comprueban credenciales distintas: la autorización del usuario para el sistema, la firma del agente que envía una petición y la identidad y delegación que valida el servidor MCP.
Nonces, certificados y revocación
El ejemplo fija en 60 segundos la antigüedad máxima predeterminada de una solicitud firmada. Cada sobre lleva un nonce aleatorio de 128 bits; una caché en memoria conserva los nonces durante el doble del límite de antigüedad, es decir, 120 segundos con ese valor predeterminado. Así, el servidor puede rechazar una solicitud repetida o demasiado antigua. El perfil de certificado de ejemplo tiene una validez de siete días.
AWS describe comprobaciones OCSP en cada solicitud y una validación que falla de forma cerrada si el respondedor OCSP no está disponible. También plantea la revocación de certificados de usuario y agentes como parte del flujo de cierre de sesión. La latencia efectiva de revocación no es una medición de este diseño.
Para ampliar o reforzar el patrón, AWS enumera opciones como una caché distribuida con Amazon ElastiCache, un respondedor OCSP de alta disponibilidad, claves de firma respaldadas por AWS CloudHSM o un HSM local, OCSP stapling y autoridades de certificación específicas por cliente. AWS diferencia además la PKI, usada para autenticar agentes entre sí, de los roles de IAM, que autorizan el acceso a servicios de AWS.
Requisitos y alcance del proyecto
El ejemplo requiere Keycloak 26.2 o posterior, Python 3.9 o posterior y EJBCA Enterprise con REST API V1 y un respondedor OCSP. También necesita acceso a Amazon Bedrock, Amazon RDS para MySQL, Amazon SES y AWS Secrets Manager. La arquitectura usa además AWS Strands Agents SDK y FastMCP.
El repositorio AWS Samples se define como una demostración para aprendizaje y desarrollo que necesita refuerzo de seguridad y revisión antes de utilizarse en producción. Su ruta de instalación automatizada despliega Keycloak y EJBCA localmente en Docker y aprovisiona recursos de AWS, entre ellos una base de datos RDS para MySQL. El README indica que hay que limpiar los recursos al terminar; en el modo sandbox de Amazon SES, el correo solo puede enviarse a destinatarios verificados.
