X.509 é um padrão de certificados digitais que associa uma chave criptográfica a uma identidade. Em um tutorial publicado em 20 de outubro de 2026, a AWS descreveu uma arquitetura de referência que usa esses certificados para identificar agentes de IA e validar solicitações; o exemplo também combina delegação assinada pelo usuário, tokens com audiência restrita e verificações de revogação via OCSP.
A ideia é vincular cada ação a um agente específico e à autorização concedida pelo usuário. Isso permite ao servidor de ferramentas conferir a identidade associada a uma solicitação antes de processá-la.
Autorização do MCP e identidade X.509 atuam em camadas diferentes
A especificação do Model Context Protocol (MCP) prevê autorização OAuth opcional para transportes HTTP. Para implementações que usam STDIO, recomenda obter as credenciais do ambiente, em vez de aplicar esse mecanismo. A especificação de autorização do MCP define o escopo dessa opção.
No exemplo da AWS, o certificado X.509 identifica o agente e permite verificar solicitações assinadas entre agentes. A autorização HTTP do MCP controla o acesso no nível do transporte; não substitui essa identidade individual nem a delegação do usuário.
| Mecanismo | Escopo | O que controla |
| Autorização OAuth do MCP | Opcional, para transportes HTTP | Autorização no transporte entre cliente e servidor MCP |
| Identidade X.509 do exemplo da AWS | Agentes e solicitações assinadas | Identidade criptográfica do agente, prova da solicitação e delegação do usuário |
Como as verificações se encadeiam até o servidor MCP
A arquitetura organiza os controles em três limites de confiança: usuário para sistema, agente para agente e agente para servidor MCP.
No primeiro limite, o usuário entra pelo Keycloak. O exemplo troca o token da sessão por outro com audiência restrita ao servidor MCP, sem entregar aos agentes o token da sessão completa. Em seguida, a aplicação gera localmente um par de chaves RSA, de pelo menos 2048 bits, e envia à EJBCA uma solicitação de assinatura de certificado. A chave privada não é enviada à EJBCA.
O certificado do agente e a chave privada são reunidos em um pacote PKCS#12 e guardados no AWS Secrets Manager. O usuário assina uma declaração de delegação que identifica os certificados dos agentes por suas impressões digitais SHA-256 e registra o usuário, a emissão e a validade da autorização.
Na comunicação entre agentes, o remetente assina o conteúdo, o nome da ferramenta, os argumentos, a data e hora e um nonce, um valor aleatório de uso único. A assinatura usa RSA-PSS-SHA256. O agente que recebe a solicitação confere a assinatura, o prazo, a unicidade do nonce, a cadeia de certificados, as permissões e o status de revogação.
Ao receber uma solicitação de ferramenta, o servidor MCP verifica o token e sua audiência, o envelope assinado, a delegação e a identidade do usuário e do agente. O exemplo usa Amazon Bedrock com o AWS Strands Agents SDK, Keycloak, EJBCA Enterprise, FastMCP e Amazon RDS for MySQL.
Nonces, validade dos certificados e revogação
No exemplo, cada envelope tem um nonce de 128 bits e um limite padrão de 60 segundos para sua atualidade. O cache de prevenção contra repetição retém o nonce por duas vezes esse limite, ou 120 segundos com a configuração padrão. Uma nova tentativa precisa usar outro envelope e outro nonce.
O perfil de certificado de exemplo tem validade de sete dias. A AWS descreve uma consulta OCSP a cada solicitação e informa que a validação falha de forma fechada se o serviço OCSP não estiver acessível. O fluxo prevê revogar os certificados do usuário e dos agentes, excluir os segredos do Secrets Manager sem período de recuperação e encerrar a sessão do Keycloak. Essa é a lógica descrita para a arquitetura, não uma medição de latência de revogação.
Requisitos e escopo da demonstração
O tutorial requer Keycloak 26.2 ou posterior, Python 3.9 ou posterior e EJBCA Enterprise com REST API V1 e um respondedor OCSP. Também pressupõe acesso a uma conta AWS com Amazon Bedrock, Amazon RDS for MySQL, Amazon SES e AWS Secrets Manager, além de familiaridade com X.509, OCSP, OAuth 2.0, assinaturas RSA e PKCS#12.
O README do repositório AWS Samples classifica o projeto como uma demonstração para aprendizado e desenvolvimento e pede reforço de segurança e revisão antes de qualquer uso em produção.
