Amazon AWS Adiciona Private Key JWT ao AgentCore Identity, Trocando Segredos Compartilhados por Controle via KMS

A Amazon AWS adicionou autenticação Private Key JWT ao AgentCore Identity, oferecendo aos agentes automatizados uma nova alternativa aos segredos de cliente OAuth de longa duração. A mudança direciona a autenticação de clientes para assertions assinadas e de curta duração, respaldadas pelo AWS Key Management Service. Ela também cria um registro mais claro de cada solicitação de assinatura no AWS CloudTrail.

Essa combinação é importante porque um agente autônomo pode solicitar tokens com muito mais frequência do que uma aplicação convencional voltada a funcionários. Um segredo de cliente copiado pode continuar útil até que alguém o rotacione ou revogue. Uma assertion Private Key JWT expira rapidamente e exige acesso a uma chave de assinatura protegida a cada nova solicitação.

A questão central não se resume a chaves versus senhas. O Amazon Bedrock AgentCore Identity agora promete maior controle sem obrigar desenvolvedores a criar e operar seu próprio serviço de assinatura. Se essa promessa se sustenta depende da compatibilidade com o provedor de identidade, da configuração precisa das claims, das permissões do KMS e de uma cobertura de auditoria completa.

Amazon AWS Leva a Autenticação de Clientes OAuth para o KMS

A mudança importante é que o AgentCore Identity pode autenticar um cliente OAuth sem armazenar um segredo de cliente reutilizável.

No novo padrão descrito no anúncio de Private Key JWT, o AgentCore Identity cria um JSON Web Token e o assina por meio do AWS KMS. O provedor de identidade verifica essa assinatura usando a chave pública correspondente.

A chave privada permanece dentro do KMS. Um agente, processo de aplicação ou administrador não precisa exportar a chave para um arquivo de configuração, imagem de contêiner, variável de ambiente ou repositório de segredos separado.

O JWT assinado é uma client assertion, ou seja, comprova a identidade do cliente OAuth para um servidor de autorização. Ele não é o token de acesso posteriormente apresentado a uma API. O servidor de autorização valida a assertion antes de emitir esse token de acesso.

Essa distinção é fácil de passar despercebida. A autenticação de cliente OAuth responde se a aplicação que solicita um token é o cliente registrado. O grant OAuth determina qual autoridade o token resultante representa e quais permissões ele recebe.

Assim, Private Key JWT pode funcionar em mais de um fluxo de grant. O AgentCore Identity oferece suporte a acesso delegado pelo usuário por meio do authorization code grant e a acesso máquina a máquina por meio de client credentials. Seus padrões de autenticação mais amplos também abrangem configurações de troca de token on-behalf-of.

Em uma solicitação delegada pelo usuário, uma pessoa primeiro autoriza o acesso por meio do provedor de identidade. O AgentCore Identity então autentica o cliente OAuth ao trocar o código de autorização por tokens. A aprovação do usuário e a identidade do cliente permanecem controles separados.

Em uma solicitação máquina a máquina, nenhum usuário conclui uma tela interativa de consentimento. O agente solicita um token de acesso sob a própria autoridade da aplicação. Private Key JWT autentica essa aplicação durante a troca de client credentials.

Isso torna o recurso relevante além do login. Ele se destina ao acesso de saída de agentes a APIs empresariais, serviços de software e outros recursos protegidos. Essas são justamente as conexões nas quais uma credencial estática pode se tornar um passivo operacional.

O AgentCore Identity já atua como intermediário entre agentes, servidores de autorização e servidores de recursos. Ele recupera credenciais enquanto mantém segredos de longo prazo e refresh tokens afastados do código do agente. Private Key JWT estende essa fronteira ao material de autenticação do cliente OAuth.

O caminho da solicitação agora tem várias etapas explícitas. O agente pede ao AgentCore Identity acesso autorizado. O AgentCore Identity cria uma assertion com tempo limitado, chama o KMS para assiná-la e a envia ao endpoint de token do provedor de identidade.

O provedor de identidade verifica a assinatura em relação à chave pública registrada. Ele também avalia claims que identificam o cliente, a audiência, o horário de emissão e a expiração. Se essas verificações forem aprovadas, o provedor retorna um token de acesso por meio do AgentCore Identity.

Esse design não elimina a confiança. Ele a desloca para políticas do KMS, funções do IAM, configuração OAuth e o registro de chave pública do provedor de identidade. Esses controles são mais granulares do que uma string copiada, mas também introduzem mais pontos nos quais uma incompatibilidade pode interromper a autenticação.

Como Private Key JWT Muda o Modelo de Segredos

Private Key JWT reduz a dependência de segredos compartilhados, mas sua segurança depende do controle sobre quem pode solicitar ao KMS que assine.

A autenticação tradicional de clientes OAuth costuma usar client_secret_basic ou client_secret_post. Ambos os métodos enviam um ID de cliente e um segredo compartilhado ao servidor de autorização. A diferença é se essas credenciais aparecem em um cabeçalho HTTP Basic ou no corpo da solicitação.

A documentação da AWS descreve HTTP Basic como o método padrão para provedores personalizados do AgentCore Identity. O segredo permanece reutilizável até sua rotação, expiração ou revogação. Todo sistema que mantém uma cópia passa a fazer parte da fronteira de segurança da credencial.

Private Key JWT substitui esse modelo simétrico por um par de chaves assimétricas. Uma parte controla a chave privada de assinatura, enquanto o provedor de identidade armazena apenas a chave pública de verificação. A exposição da chave pública não permite que um invasor gere assertions válidas.

A abordagem segue o perfil JWT do OAuth, que define JWTs para autenticação de clientes e grants de autorização. A solicitação de token inclui uma client assertion e a identifica como uma JWT bearer assertion.

Uma assertion típica contém uma claim de emissor que identifica o cliente, uma claim de assunto para esse cliente e uma claim de audiência que nomeia o endpoint de token. Ela também inclui horários de expiração e emissão. Um identificador JWT exclusivo pode ajudar um provedor de identidade a detectar tentativas de replay.

Esses campos não são metadados decorativos. Uma audiência incorreta pode tornar inválido um JWT corretamente assinado. Uma diferença de relógio pode levar o provedor a rejeitar uma assertion como prematura ou expirada.

Private Key JWT também não garante automaticamente proteção contra replay. A RFC 7523 deixa algumas defesas contra replay a cargo da política de implantação. Os provedores de identidade precisam de limites adequados de duração e, quando houver suporte, rastreamento de assertions exclusivas.

Janelas curtas de expiração reduzem a utilidade de uma assertion capturada. Elas não protegem um sistema em que um invasor tem permissão para invocar repetidamente a chave de assinatura. Por isso, a política de chaves do KMS e as permissões do IAM se tornam a camada central de aplicação.

O AWS KMS representa uma chave assimétrica como um par vinculado de chave pública e privada. Para chaves de assinatura, o componente privado permanece protegido dentro do serviço. O componente público pode ser baixado e registrado com um provedor de identidade externo.

O KMS oferece suporte a vários tipos de chave assimétrica, incluindo chaves RSA e de curva elíptica para assinatura e verificação. O tipo de chave e o algoritmo escolhidos devem corresponder ao que o provedor de identidade aceita.

O AgentCore Identity precisa de permissão para usar a chave configurada para assinatura. A AWS afirma que os chamadores da operação KMS Sign exigem autorização kms:Sign por meio da política de chaves. O serviço então usa o componente privado sem retorná-lo.

Essa é uma melhoria relevante de contenção. Um vazamento de configuração que exponha um ARN de chave não revela o material da chave privada. Um invasor ainda precisaria de credenciais da AWS e de autorização efetiva para invocar a chave.

No entanto, a permissão para assinar continua sensível. Uma função com acesso amplo a kms:Sign poderia potencialmente solicitar assinaturas fora do caminho de carga de trabalho pretendido. As equipes devem vincular permissões às funções de execução corretas do AgentCore e evitar acesso genérico com curingas.

A mudança também afeta a rotação. Com um segredo compartilhado, ambos os lados precisam substituir o mesmo valor confidencial. Com a autenticação assimétrica, as equipes podem introduzir uma nova chave pública no provedor de identidade enquanto mantêm o verificador antigo durante uma transição controlada.

Essa sobreposição pode reduzir o tempo de indisponibilidade, desde que o provedor de identidade ofereça suporte a várias chaves ativas. Se ele aceitar apenas uma chave pública, a rotação ainda exigirá coordenação de tempo. Private Key JWT muda o material que é rotacionado, não a necessidade de um processo de rotação testado.

Os Fluxos de Grant Compatíveis Atendem a Diferentes Identidades de Agentes

Private Key JWT autentica o cliente OAuth, enquanto o grant selecionado determina se um agente atua por si próprio ou por um usuário.

O authorization code grant é adequado para agentes que acessam recursos em nome de uma pessoa. Um usuário faz login por meio de um provedor de identidade e aprova as permissões solicitadas. O servidor de autorização retorna um código que o cliente troca por tokens.

Durante essa troca, o AgentCore Identity usa a assertion Private Key JWT para comprovar que o cliente registrado está fazendo a solicitação. A assertion não substitui o consentimento do usuário. Ela fortalece a autenticação no endpoint de token.

Esse fluxo é apropriado para um agente que lê o calendário de um usuário, pesquisa registros autorizados de um funcionário ou atualiza um sistema de gestão de clientes dentro das permissões delegadas. O acesso resultante permanece vinculado ao usuário e aos escopos aprovados.

O grant de client credentials atende a um caso diferente. Aqui, a carga de trabalho atua por si mesma, sem um usuário interativo. Um agente programado pode chamar uma API interna de inventário, processar alertas de serviço ou recuperar dados operacionais aprovados.

Private Key JWT autentica esse cliente de máquina antes que o servidor de autorização emita um token de aplicação. Como nenhuma pessoa está presente, a identidade do cliente, os escopos do token e a política de autorização posterior carregam uma parcela maior da responsabilidade de segurança.

As organizações não devem tratar os dois grants como opções de implantação intercambiáveis. Usar client credentials para uma tarefa que deveria preservar a identidade do usuário pode obscurecer a responsabilização. Usar um fluxo delegado para trabalho de serviço em segundo plano pode criar dependências frágeis de contas individuais.

O acesso on-behalf-of introduz outra variação. Um agente recebe evidências de uma identidade de usuário existente e as troca por um token adequado a outro recurso. O fluxo precisa preservar a relação entre o usuário, o agente e o serviço de destino.

A documentação do AgentCore Identity descreve tanto a troca padrão de tokens quanto abordagens de authorization grant baseadas em JWT para esses casos. O suporte ainda depende do servidor de autorização externo e de suas regras de troca de tokens.

Private Key JWT pode autenticar o cliente que participa dessa troca. Ele não decide se o token de usuário recebido é válido nem se a delegação solicitada deve ser permitida. Essas decisões continuam com os sistemas de identidade e autorização relevantes.

Essa separação é um dos pontos arquiteturais mais fortes do recurso. As equipes podem escolher um grant com base na autoridade de que um agente precisa e, em seguida, escolher Private Key JWT com base em como o cliente deve comprovar sua identidade.

Ela também evidencia por que uma única “credencial de agente” é um modelo mental inseguro. Um agente pode ter uma identidade de carga de trabalho, atuar por um usuário, chamar vários servidores de recursos e usar tokens diferentes para cada destino.

O token de acesso da workload do AgentCore Identity acrescenta outra camada. A AWS afirma que esse token pode incluir a identidade do agente e a identidade do usuário final quando o agente solicita credenciais ao cofre. O AgentCore Runtime pode fornecê-lo automaticamente a agentes hospedados.

Esse token de workload autoriza o acesso ao AgentCore Identity. O token de acesso OAuth externo autoriza o acesso à API de destino. A asserção Private Key JWT autentica o cliente OAuth durante a emissão do token.

Portanto, três tokens podem aparecer em uma única transação de ponta a ponta, cada um com uma função diferente. Confundi-los pode levar a validações incorretas, registro excessivo em logs ou exposição acidental.

As revisões de segurança devem mapear cada token ao seu emissor, público, detentor, duração e destino. Também devem identificar qual componente pode renová-lo ou substituí-lo. Esse exercício detecta erros de projeto que diagramas no nível do produto podem ocultar.

A pressão competitiva mais ampla recai sobre integrações de agentes baseadas em segredos. Segredos de cliente estáticos são familiares e amplamente compatíveis, mas escalam mal quando muitas workloads autônomas precisam de permissões independentes e trilhas de auditoria.

Private Key JWT aumenta a complexidade de configuração ao mesmo tempo que reduz a duplicação de credenciais. Para equipes que já operam AWS IAM, KMS e CloudTrail, essa troca pode ser atraente. Em implantações menores, a superfície adicional de políticas pode superar o benefício imediato.

Configurar a Cadeia de Confiança Exige Mais do Que Selecionar um Método

A configuração só funciona quando KMS, IAM, AgentCore Identity e o provedor de identidade externo concordam nos mesmos detalhes criptográficos e de OAuth.

O primeiro requisito é uma chave KMS assimétrica configurada para assinatura e verificação. Chaves de criptografia não podem executar essa função. A especificação da chave e o algoritmo de assinatura devem corresponder a uma combinação aceita pelo provedor de identidade de destino.

O AWS KMS expõe a parte pública de uma chave de assinatura assimétrica. As equipes registram essa chave pública no provedor de identidade, diretamente ou por meio de uma configuração compatível de JSON Web Key.

O provedor de identidade deve associar a chave ao cliente OAuth correto. Ele também precisa oferecer suporte a Private Key JWT em seu endpoint de token. As interfaces de registro e os algoritmos aceitos variam entre provedores, portanto esta etapa continua sendo específica de cada provedor.

Em seguida, os administradores criam ou atualizam um provedor de credenciais OAuth personalizado no console do Amazon Bedrock AgentCore. A configuração precisa das informações de descoberta do provedor, do identificador do cliente, do ARN da chave KMS e do algoritmo de assinatura.

A descoberta OAuth permite que o AgentCore Identity localize os endpoints de autorização e token a partir dos metadados do provedor. As equipes devem verificar se o endpoint de token descoberto corresponde ao valor de público esperado pelo provedor de identidade.

O AgentCore Identity também precisa de permissão para invocar o KMS. A operação de assinatura do KMS exige uma chave com uso SIGN_VERIFY e um algoritmo compatível com essa chave.

O KMS aceita uma mensagem bruta ou um resumo pré-calculado, dependendo do tipo de mensagem selecionado. Uma implementação de JWT deve evitar o hash duplo acidental, pois a verificação externa pressupõe o comportamento de hash especificado pelo algoritmo.

A configuração do cabeçalho JWT também é importante. O provedor de identidade pode usar um identificador de chave para selecionar a chave pública apropriada. Um identificador ausente ou incorreto se torna especialmente problemático durante a rotação, quando várias chaves públicas podem estar ativas.

As declarações da carga útil exigem o mesmo cuidado. O emissor e o assunto normalmente correspondem ao ID do cliente OAuth. O público normalmente identifica o endpoint de token do servidor de autorização, embora os requisitos do provedor devam determinar o valor exato.

A expiração deve permanecer curta. A hora de emissão deve refletir um relógio sincronizado. Um identificador de token exclusivo é valioso quando o provedor registra as asserções aceitas anteriormente.

Depois de salvar o provedor de credenciais, as equipes devem testar cada concessão pretendida de forma independente. Uma solicitação bem-sucedida de credenciais de cliente não comprova que a troca de código de autorização ou a troca de token esteja configurada corretamente.

Os testes devem começar com escopos mínimos. Se a autenticação for bem-sucedida, mas a autorização falhar, a distinção se torna mais fácil de diagnosticar. Adicionar permissões amplas para contornar um erro pode ocultar um problema de público ou de registro de cliente.

As equipes também devem testar caminhos negativos. Uma solicitação assinada com a chave errada deve falhar. Uma asserção expirada deve falhar. Um público incorreto e um chamador KMS não autorizado devem gerar evidências distinguíveis.

É aqui que a troca operacional se torna visível. Segredos compartilhados são simples o suficiente para que as equipes frequentemente validem apenas o caminho ideal. Private Key JWT oferece limites mais fortes, mas esses limites exigem testes explícitos.

A configuração também cria dependências entre equipes administrativas. Uma equipe de segurança em nuvem pode ser responsável pelas políticas de KMS e IAM. Uma equipe de identidade pode controlar o cliente OAuth e o registro da chave pública.

Os responsáveis pela aplicação configuram o AgentCore Identity e determinam os escopos de concessão. As equipes de auditoria decidem quais registros do CloudTrail devem ser retidos e gerar alertas. Nenhuma seleção em um único console resolve essas questões de responsabilidade.

Uma implementação útil começa com uma integração não crítica. As equipes podem documentar requisitos de declarações, respostas a falhas, etapas de rotação e responsabilidades de escalonamento antes de aplicar o método a muitos agentes.

A automação deve seguir essa primeira implantação validada. Modelos de infraestrutura podem padronizar políticas de chave e configurações de provedores de credenciais, mas não devem presumir o comportamento do provedor de identidade.

O resultado não é um sistema sem segredos. Os tokens ainda existem, os servidores de autorização ainda mantêm a confiança e as permissões da AWS continuam sendo credenciais. A afirmação mais restrita é mais defensável: o cliente OAuth não depende mais de um segredo compartilhado e reutilizável.

CloudTrail Transforma Cada Assinatura em um Sinal de Auditoria

A assinatura respaldada por KMS oferece aos defensores um evento no lado da AWS que eles podem correlacionar com solicitações de token e atividade de agentes.

O AWS KMS se integra ao CloudTrail, que registra chamadas feitas por usuários, funções e serviços da AWS. Seu registro de auditoria do KMS inclui operações criptográficas, além de ações de gerenciamento de chaves.

Portanto, uma transação Private Key JWT deve gerar evidências em torno da solicitação de assinatura do KMS. O evento pode identificar a operação, região, horário, chave relevante e o principal da AWS ou contexto de serviço envolvidos.

Esse registro não contém toda a história por si só. O CloudTrail mostra que uma identidade AWS autorizada solicitou uma assinatura. Os logs do provedor de identidade externo mostram se ele aceitou a asserção e emitiu um token.

Os logs de auditoria do serviço de destino mostram o que o token de acesso resultante fez. Uma investigação eficaz correlaciona as três camadas, em vez de tratar o evento do KMS como prova de acesso bem-sucedido ao recurso.

O CloudTrail ainda pode responder a questões importantes. Investigadores podem procurar volume inesperado de assinaturas, solicitações da função errada, chamadas em uma região não aprovada ou atividade envolvendo uma chave fora de sua programação normal.

Os seletores de eventos configurados são importantes. A AWS classifica eventos do KMS como eventos de gerenciamento, e as trilhas do CloudTrail normalmente registram atividade de gerenciamento. No entanto, administradores podem excluir explicitamente eventos do KMS.

A AWS alerta que operações do KMS podem gerar grandes volumes de eventos. Algumas organizações as filtram para controlar o volume de registros. Isso pode remover justamente a evidência de assinatura que torna esse padrão de autenticação mais fácil de auditar.

As equipes que adotarem Private Key JWT devem revisar suas configurações de eventos de gerenciamento. Elas devem confirmar que a atividade relevante do KMS chega à trilha ou ao armazenamento de dados de eventos pretendido.

A retenção e a capacidade de pesquisa também importam. O histórico de eventos é útil para investigações recentes, enquanto uma trilha ou um armazenamento de dados de eventos do CloudTrail Lake oferece suporte a análises mais longas. Registros exportados também podem alimentar sistemas de monitoramento de segurança.

Uma linha de base deve distinguir o comportamento esperado de renovação de token de anomalias. Um agente de máquina em execução contínua pode assinar asserções em uma cadência regular. Um fluxo de trabalho delegado pelo usuário pode criar picos durante sessões ativas.

Desvios significativos podem indicar um loop de tentativas, falha de configuração ou uso indevido de credenciais. Assinaturas repetidas seguidas de rejeição pelo endpoint de token podem indicar um público incorreto, chave pública expirada ou problema de relógio.

A atividade de assinatura sem solicitações correspondentes ao AgentCore merece uma inspeção mais detalhada. O mesmo vale para a emissão bem-sucedida de tokens sem as chamadas downstream esperadas. Cada padrão identifica uma ruptura diferente na cadeia de confiança.

Eventos do ciclo de vida da chave devem receber alertas separados. Desativar uma chave de assinatura pode interromper todas as integrações dependentes. Alterações de política podem ampliar silenciosamente quem tem permissão para invocá-la.

O CloudTrail também ajuda durante a rotação. As equipes podem observar se a chave antiga continua recebendo solicitações de assinatura depois que uma nova chave se torna ativa. A atividade contínua pode revelar um provedor de credenciais esquecido ou uma implantação atrasada.

No entanto, a visibilidade de auditoria continua condicional. Os logs precisam estar habilitados, retidos, protegidos e revisados. Um evento registrado, mas nunca consultado, oferece pouca defesa prática.

Os eventos do CloudTrail também não validam o motivo de negócio de uma solicitação. Um agente devidamente autorizado ainda pode pedir um token de acesso no momento errado ou usá-lo em uma tarefa excessivamente ampla.

Essa limitação desloca a atenção para o projeto de autorização. Private Key JWT pode provar que o cliente controla o acesso a uma chave de assinatura. Ele não pode determinar se o objetivo do agente, a ferramenta selecionada ou a operação solicitada é apropriada.

As organizações precisam de restrições de escopo, políticas de servidor de recursos, controles de workload e monitoramento comportamental em torno da prova criptográfica. A assinatura é um sinal de alta qualidade, não um sistema completo de governança de agentes.

O Que as Empresas Devem Observar Após o Lançamento do Private Key JWT

O próximo teste é saber se Private Key JWT se torna um padrão operacional ou permanece uma opção avançada para implantações rigorosamente gerenciadas.

O primeiro sinal é a interoperabilidade com provedores de identidade. A adoção bem-sucedida exige que os provedores aceitem os algoritmos de assinatura selecionados, as declarações, o formato de público e o método de registro da chave pública.

A AWS pode simplificar seu lado da troca, mas não pode padronizar o fluxo administrativo de todos os provedores. Exemplos claros e específicos de cada provedor reduziriam implantações malsucedidas e soluções alternativas inseguras.

O segundo sinal é o comportamento de rotação. As empresas precisam saber se podem registrar chaves públicas sobrepostas, atualizar provedores do AgentCore sem interrupção e confirmar a migração por meio de registros de auditoria.

Um recurso que funciona apenas durante a configuração inicial resolve metade do problema. A autenticação de produção também precisa de recuperação previsível quando uma chave é desativada, substituída ou comprometida.

O terceiro sinal é a adoção da auditoria. O CloudTrail oferece às equipes acesso a registros de assinatura, mas as organizações precisam reter eventos do KMS e conectá-los aos logs do provedor de identidade e do servidor de recursos.

Orientações de detecção tornariam o recurso mais útil. Altas taxas de assinatura, principais desconhecidos, erros repetidos e atividade regional inesperada são candidatos práticos para alertas.

As equipes de segurança também devem observar os limites do modelo de permissões do AgentCore Identity. A política ideal permite que uma workload use uma chave de assinatura para um provedor aprovado, sem conceder acesso de assinatura não relacionado.

Chaves entre contas adicionam flexibilidade, mas exigem políticas de recursos cuidadosas. O AWS KMS oferece suporte ao uso entre contas para assinatura quando os chamadores especificam o ARN da chave e recebem as permissões necessárias.

Esse recurso pode apoiar uma gestão centralizada da segurança. Também pode criar dependências entre contas de aplicações e uma conta de identidade central. Interrupções ou erros de política na conta central podem afetar muitos agentes.

As empresas devem medir os resultados operacionais em vez de presumir que o desenho criptográfico garante o sucesso. Indicadores úteis incluem a carga de trabalho de rotação de segredos, falhas em solicitações de token, tentativas não autorizadas de assinatura e o tempo de recuperação após alterações de chave.

Elas também devem comparar o Private Key JWT com a autenticação JWT assinada pelo AWS IAM. A documentação do AgentCore Identity descreve um método AWS_IAM_ID_TOKEN_JWT que usa uma declaração emitida pelo IAM e exige que o servidor de autorização confie no AWS IAM.

As duas abordagens se afastam de segredos de cliente compartilhados, mas estabelecem confiança de maneiras diferentes. O Private Key JWT exige que o provedor de identidade confie em uma chave pública gerenciada pelo cliente. O método IAM exige que ele confie no AWS IAM como emissor.

O suporte dos provedores frequentemente determinará qual caminho é viável. Alguns sistemas de identidade já oferecem suporte ao Private Key JWT para clientes OAuth confidenciais. Menos deles podem estar configurados para aceitar diretamente um emissor do AWS IAM.

Por isso, o Private Key JWT ocupa um meio-termo útil. Ele aplica um método padrão de autenticação OAuth, mantendo o material de assinatura privado sob o controle do KMS.

A importância mais ampla do recurso está na forma como ele trata um agente. Em vez de fornecer ao agente uma credencial reutilizável, a plataforma executa uma operação criptográfica estritamente autorizada quando o acesso é necessário.

Esse padrão reduz o valor de dados de configuração copiados. Também cria um ponto de controle aplicável para cada solicitação de token. São melhorias concretas para cargas de trabalho autônomas que operam com frequência e supervisão limitada.

A contrapartida é uma maior precisão na configuração. As equipes precisam alinhar algoritmos, chaves públicas, declarações JWT, políticas IAM, concessões OAuth, escopos de token e controles de registro.

A Amazon AWS tornou essa complexidade mais gerenciável ao incorporar a assinatura ao AgentCore Identity. No entanto, ela não eliminou as decisões de confiança ao redor desse processo.

Antes de adotar amplamente o método, escolha um agente representativo e rastreie todo o seu caminho de acesso. Identifique cada principal, token, concessão, escopo, fonte de log e mecanismo de revogação envolvidos.

Em seguida, teste a rotação e as falhas, não apenas a autenticação bem-sucedida. Se sua equipe conseguir explicar quem solicitou cada assinatura e o que aconteceu depois, o Private Key JWT estará fazendo mais do que substituir um segredo.