Um agente rodando na AWS, ou contra ela, nunca deveria guardar uma credencial de longa duração. Nem um usuário IAM, nem uma access key em um gerenciador de segredos, nem uma service account "agents" compartilhada. Todo caminho sério de autenticação que a AWS oferece, instance profiles, IRSA, EKS Pod Identity, federação OIDC, IAM Roles Anywhere, AgentCore Identity, existe para fazer a mesma coisa: trocar uma prova verificável de identidade por credenciais temporárias que expiram sozinhas. Se a sua plataforma de agentes parte dessa regra, a maioria das perguntas difíceis se responde sozinha.

Ontem escrevi sobre a camada de protocolo desse problema no site irmão: SEP-1046 dando aos agentes MCP uma história real de client credentials, com asserções JWT assinadas substituindo segredos compartilhados. Este post é a camada de baixo: quando o alvo do agente é a própria AWS, ou o agente roda na AWS e precisa alcançar todo o resto, como é de fato a identidade dele? A resposta, em quase todos os casos, tem o mesmo formato que o SEP-1046 escolheu: um token assinado de curta duração entra, credenciais de curta duração saem. A AWS roda esse padrão em escala há anos. Você só precisa parar de brigar com ele usando chaves estáticas.

Um padrão embaixo de tudo: federação OIDC

Tire os nomes de produto e a autenticação de agentes na AWS é um mecanismo só. Um provedor de identidade assina um JWT sobre um workload. Você registra a issuer URL desse provedor no IAM como um provedor de identidade OIDC; o IAM busca as chaves públicas no jwks_uri do provedor via o documento de descoberta /.well-known/openid-configuration. O workload apresenta seu token ao sts:AssumeRoleWithWebIdentity e recebe credenciais de role que expiram em menos de uma hora. A trust policy da role define quem entra com condições sobre as claims aud e sub do token.

A versão disso que todo time de plataforma já conhece é o GitHub Actions: o runner recebe um token OIDC cuja claim sub codifica repositório e branch, a trust policy da role casa com repo:my-org/my-repo:ref:refs/heads/main, e nenhuma access key vive nos secrets do repositório. Isso não é um truque de CI. É o modelo para todo workload não assistido, agentes incluídos. Uma asserção assinada, vinculada a uma audiência e com vida de minutos substituindo um segredo armazenado é exatamente o que private_key_jwt faz na camada MCP; a indústria convergiu para uma resposta vindo de duas direções, o que costuma ser o sinal de que a resposta está certa.

Onde o agente roda decide o mecanismo

Você raramente constrói a federação por conta própria. Você escolhe o empacotamento que combina com o runtime:

  • Em EC2 ou ECS: instance profile ou task role. A cadeia de credenciais do SDK pega isso sozinha, nada para configurar no agente. Se o seu framework de agentes pede uma access key aqui, isso é um cheiro do framework, não um requisito da AWS.
  • Em EKS: duas opções. IRSA (IAM Roles for Service Accounts) é a mais antiga: o cluster expõe um issuer OIDC, você o registra no IAM e anota uma ServiceAccount com o ARN de uma role. EKS Pod Identity é a mais nova: sem registro de provedor OIDC por cluster, um add-on de agente no nó troca as credenciais, e a trust policy da role aponta para pods.eks.amazonaws.com uma vez só, em vez de issuer URLs por cluster. Para uma frota de clusters, Pod Identity elimina trabalho braçal de verdade; para um cluster só, qualquer uma serve. As duas terminam no mesmo lugar: uma role IAM por workload de agente, nenhuma chave no pod.
  • Fora da AWS, com um IdP: federação OIDC pura, como acima. O workload no seu datacenter, na sua outra nuvem ou no seu runner SaaS se autentica no próprio provedor de identidade e federa para dentro. É o padrão do GitHub Actions generalizado.
  • Fora da AWS, sem um IdP: IAM Roles Anywhere. O workload apresenta um certificado X.509 de uma CA que você registrou como trust anchor (AWS Private CA ou sua própria PKI) e o troca por credenciais temporárias de role via um profile. A ressalva honesta: você herda a gestão do ciclo de vida de certificados, emissão, rotação, revogação. Se você ainda não opera PKI, subir um provedor de identidade costuma pesar menos na operação do que adotar uma.

AgentCore Identity: a camada em formato de agente por cima

O IAM responde "como este workload chama a AWS". Agentes têm mais dois problemas: quem pode chamar o agente, e como o agente alcança serviços fora da AWS, Slack, GitHub, Google, em nome de um usuário. Essa é a fatia que o Amazon Bedrock AgentCore Identity cobre, e vale entender mesmo que você nunca rode AgentCore, porque é a AWS colocando no papel o que a identidade de agentes precisa além de uma role.

  • Identidades de workload para agentes. Cada agente ganha sua própria entrada no diretório, não um principal compartilhado. A mesma regra de uma identidade por workload das roles IAM, aplicada um nível acima.
  • Autenticação de entrada. Quem chama o agente usa SigV4 puro (IAM como sempre) ou passa por um JWT authorizer: você configura uma discovery URL e as audiências permitidas, e tokens do Cognito, do Okta ou do Entra ID controlam o acesso ao agente. O AgentCore Gateway expõe o mesmo authorizer CUSTOM_JWT para endpoints de ferramentas, que é como um gateway no estilo MCP na AWS valida os tokens que o post anterior tratava de emitir.
  • Autenticação de saída. Um cofre de tokens guarda os grants OAuth de serviços de terceiros, two-legged para serviço a serviço, three-legged quando um usuário consentiu uma vez e o agente age sobre esse consentimento depois. É o padrão de agir em nome de alguém, com o consentimento armazenado no servidor em vez de um refresh token colado numa variável de ambiente.
  • Nota de preço. Via AgentCore Runtime ou Gateway não custa nada a mais; o uso standalone cobra por token OAuth ou requisição de API key bem-sucedida. Barato de qualquer jeito; a parte cara sempre foi o incidente que você evita.

A camada de protocolo acima de tudo isso também segue em movimento. A fila de auth do repositório da spec MCP guarda propostas que o seu gateway vai encontrar dentro de um ano: securitySchemes nos metadados de ferramentas para servidores de auth mista (SEP-1488), erros de ferramenta padronizados que disparam um fluxo OAuth no meio da sessão (SEP-1489), e métodos de autenticação declarados para servidores remotos (SEP-2742). Se você opera um gateway MCP na AWS, acompanhe esse label como acompanha as release notes do EKS.

Atribuição é o que as auditorias de fato perguntam

Credenciais temporárias resolvem o roubo; elas não resolvem sozinhas o "qual agente fez isso". Três hábitos fecham essa lacuna. Uma role por agente, para que a sessão de role no CloudTrail já nomeie o workload. sts:SourceIdentity definido no momento da assunção, para que o humano ou o sistema que disparou o agente sobreviva em cada linha de log rio abaixo, mesmo através de role chaining. E session policies para reduzir uma role ampla ao escopo da tarefa em questão, para que o raio de dano de um agente vítima de prompt injection, ou simplesmente errado, seja as permissões da tarefa, não as da role. Mantenha as permissões permanentes em somente leitura e coloque um portão em cada ação que muda estado; já fiz esse argumento vezes suficientes para que leitores frequentes o recitem de cor.

O que fazer na segunda-feira

  • Rode aws iam list-users e trate todo usuário IAM com access keys ativas que pertença a uma automação como um achado de auditoria. Agentes são automações.
  • Mapeie cada agente para o seu runtime e adote o mecanismo correspondente: instance/task roles, IRSA ou Pod Identity, federação OIDC, Roles Anywhere. Nessa ordem de preferência.
  • Fixe toda trust policy OIDC em aud e no padrão de sub mais estreito que você conseguir escrever. Uma trust policy sem condição de sub é uma porta aberta com uma placa bonita.
  • Defina sts:SourceIdentity em toda chamada de assume-role dos agentes e faça suas queries do CloudTrail usarem isso. Encaixar atribuição depois de um incidente não funciona.
  • Se você está no AgentCore, coloque o JWT authorizer na frente dos agentes e mova os grants OAuth de terceiros para o cofre de tokens. Se não está, copie o formato: identidade por agente, tokens de entrada validados, consentimento armazenado no servidor.

O fio condutor com o texto sobre MCP é difícil de não ver. Protocolo a protocolo, plataforma a plataforma, a identidade de agentes está convergindo para asserções assinadas de curta duração, vínculo de audiência e principals por workload, e as peças agora existem nas duas camadas. Os times que ainda copiam access keys para configs de agentes não são early adopters de coisa nenhuma. Estão rodando postura de segurança de 2015 contra workloads de 2026.

Leia isto a seguir

Agent Toolkit for AWS: The Docs Have a New Reader mostra o que esses agentes autenticados fazem de fato com o acesso à AWS. No site irmão, Enterprise MCP Auth: Agents Finally Get Service Accounts é a metade desta conversa na camada de protocolo, e ercanermis.com mapeia todo o resto que escrevo.

Referências