Referencie seus próprios segredos do AWS Secrets Manager no Amazon Bedrock AgentCore Identity

O desafio de credenciais em agentes de IA em produção

Agentes de IA são tão poderosos quanto as ferramentas que conseguem acessar. Para buscar dados em um CRM, publicar atualizações no Slack ou consultar um repositório no GitHub, esses agentes precisam chamar APIs externas — e isso significa passar credenciais com segurança em tempo de execução. Fazer isso corretamente, sem hardcodar segredos no código ou expô-los nos prompts do agente, é um dos grandes desafios de quem constrói sistemas agênticos prontos para produção.

O Amazon Bedrock AgentCore Identity já endereçava esse problema por meio de provedores de credenciais e um cofre de tokens que criavam e gerenciavam automaticamente um segredo no AWS Secrets Manager para cada recurso de provedor de credencial de saída (Outbound credential provider). Esse segredo armazenava a chave de API ou o client secret junto com outros metadados do provedor de identidade externo.

No entanto, havia uma limitação importante: os clientes não podiam configurar tags personalizadas, políticas de rotação ou criptografia com chaves gerenciadas pelo cliente via Serviço de Gerenciamento de Chaves da AWS (AWS KMS) no momento da criação desses segredos.

O que a AWS anunciou

A AWS anunciou a possibilidade de referenciar um segredo já existente no AWS Secrets Manager dentro do AgentCore Identity. Com isso, as equipes podem apontar para um segredo pré-configurado e manter controle total sobre como ele é gerenciado — sem precisar criar um novo segredo do zero gerenciado pelo serviço.

Na prática, isso significa que é possível fornecer um segredo existente no Secrets Manager para uso com seus recursos de provedor de credenciais. A equipe retém controle completo sobre a configuração de criptografia, rotação, replicação, tags e políticas de recurso — exatamente como gerencia qualquer outro segredo no Secrets Manager.

Outro ponto relevante: é possível referenciar um segredo de outra conta AWS dentro da mesma Região AWS, embora o compartilhamento entre Regiões diferentes não seja suportado. A funcionalidade também é compatível com segredos trazidos por meio de conectores externos do AWS Secrets Manager, permitindo integração com gerenciadores de segredos de terceiros.

Casos de uso práticos

A AWS apresentou alguns cenários concretos onde essa capacidade faz diferença:

• Reutilização de segredos existentes: Se o agente acessa uma API externa para a qual a equipe já tem um segredo configurado, basta fornecer o Nome de Recurso da Amazon (ARN) desse segredo ao recurso de provedor de credenciais, em vez de criar um novo. Segredos de outras contas AWS na mesma Região e segredos trazidos via conectores externos também são suportados.
• Rotação sem interrupção: Quando o valor do segredo é rotacionado seguindo boas práticas de segurança, o AgentCore Identity recupera automaticamente o valor atualizado na próxima leitura. Não é necessário atualizar ou recriar os recursos de provedor de credenciais.
• Controle granular de acesso: É possível configurar a política de recurso diretamente no AWS Secrets Manager, controlando quais entidades principais do Gerenciamento de Identidade e Acesso da AWS (IAM) podem acessar o segredo e definindo condições de acesso específicas.
• Ambientes regulados com criptografia própria: Para agentes que operam em ambientes regulados onde toda credencial precisa ser criptografada com chave gerenciada pelo cliente, basta criar o segredo com essa chave antes de fornecê-lo ao AgentCore Identity. Isso é especialmente útil para organizações que aplicam Políticas de Controle de Serviço (SCPs) e Políticas de Controle de Recursos (RCPs) para garantir que todos os dados sejam criptografados com chaves gerenciadas pelo cliente. Ao referenciar um segredo existente, a configuração de criptografia é preservada integralmente.
• Governança e rastreabilidade por tags: Organizações que exigem tags de recurso em segredos para alocação de custos, rastreamento de conformidade ou auditoria de governança podem criar e tagear o segredo conforme seus padrões antes de fornecê-lo ao AgentCore Identity.

Para saber mais sobre as opções de configuração de segredos disponíveis, a AWS disponibiliza o Guia do Usuário do AWS Secrets Manager.

Pré-requisitos

Para utilizar essa funcionalidade, são necessários:

• Um segredo existente no AWS Secrets Manager contendo a chave de API ou o client secret OAuth.
• Permissões de IAM para conceder ao service principal do AgentCore Identity acesso de secretsmanager:GetSecretValue ao segredo.
• Se estiver usando uma chave AWS KMS gerenciada pelo cliente, permissão de kms:Decrypt nessa chave para o service principal.
• Acesso ao console do Amazon Bedrock AgentCore Identity ou à Interface de Linha de Comando da AWS (AWS CLI).

Como configurar na prática

Para referenciar um segredo no AWS Secrets Manager, basta fornecer o ARN do segredo e a chave JSON ao criar os recursos de provedor de credenciais pela API do AgentCore Identity. O serviço recupera o valor da credencial a partir da chave JSON especificada no segredo em tempo de execução.

Pelo console

É possível configurar um segredo referenciado ao criar novos recursos de provedor de credenciais diretamente pelo console do Amazon Bedrock AgentCore. A funcionalidade suporta tanto chaves de API quanto credenciais de cliente OAuth.

Para adicionar uma chave de API com segredo referenciado:

• Abra o console do Amazon Bedrock AgentCore.
• No painel de navegação esquerdo, escolha Identity.
• Na seção Outbound Auth, escolha Add Outbound Auth.
• Escolha Add API key.
• Insira um nome para o recurso Outbound Auth.
• Em API key selection method, escolha Provide API key via Secrets Manager.
• No campo Secrets Manager ARN, insira ou selecione o ARN do segredo existente. A lista exibe os segredos disponíveis na conta. Por exemplo: arn:aws:secretsmanager:us-east-1:123456789012:secret:myApiKeySecret-AbCdEf.
• No campo JSON key, especifique a chave dentro do segredo que contém o valor da chave de API.
• Escolha Add e verifique se o provedor de credenciais aparece na lista de Outbound Auth.

Para adicionar um client secret OAuth com segredo referenciado:

• Na página Identity, escolha Add Outbound Auth.
• Escolha Add OAuth client.
• Insira um nome para o cliente OAuth (por exemplo, google-oauth-client-v5fz5).
• Em Provider, escolha o provedor desejado (incluído ou personalizado).
• Insira o Client ID fornecido pelo provedor de identidade.
• Em Client secret, escolha Provide Client secret via Secrets Manager.
• No campo Secrets Manager ARN, insira o ARN do segredo que contém o client secret OAuth.
• No campo JSON key, especifique a chave dentro do segredo que contém o valor do client secret.
• Escolha Add OAuth Client e verifique se o provedor aparece na lista.

Pela AWS CLI

Também é possível configurar um segredo referenciado ao criar um novo recurso Outbound Auth para um client secret OAuth diretamente pela AWS CLI:

aws bedrock-agentcore-control create-oauth2-credential-provider \
--name "google-oauth-client-v5fz5" \
--credential-provider-vendor "GoogleOauth2" \
--oauth2-provider-config-input '{
  "googleOauth2ProviderConfig": {
    "clientId": "",
    "clientSecretSource": "EXTERNAL",
    "clientSecretConfig": {
      "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:myGoogleKeySecret-AbCdEf",
      "jsonKey": "key"
    }
  }
}'

Por meio de um agente de IA

Se a equipe utiliza um agente de codificação por IA (como o Kiro ou similar), é possível instruí-lo a configurar um segredo referenciado diretamente com um prompt como:

“I have an existing secret in AWS Secrets Manager at ARN arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key. Create an OAuth2 credential provider in Amazon Bedrock AgentCore Identity named <client-name>, using GoogleOauth2 as the vendor. The client ID is <clientId>, the client secret source is EXTERNAL, and the secret JSON key is key.”

Substitua <client-name> e <clientId> pelos valores correspondentes.

Atenção: É necessário conceder ao AgentCore Identity permissão para ler o segredo, adicionando uma política de recurso ao segredo que permita ao service principal chamar secretsmanager:GetSecretValue. Se o segredo estiver criptografado com uma chave KMS gerenciada pelo cliente, também é necessário conceder ao service principal a permissão kms:Decrypt nessa chave.

Conclusão

Com a capacidade de referenciar segredos existentes no AWS Secrets Manager, o AgentCore Identity passa a oferecer maior flexibilidade para equipes que já possuem processos de gestão de segredos consolidados. É possível manter controle total sobre como as credenciais são criptografadas, rotacionadas e acessadas, enquanto o AgentCore Identity cuida de recuperá-las em tempo de execução.

Para começar, a AWS disponibiliza a documentação do Amazon Bedrock AgentCore Identity. Para mais informações sobre gestão de segredos, consulte o Guia do Usuário do AWS Secrets Manager.

Fonte

Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity (https://aws.amazon.com/blogs/machine-learning/reference-your-own-aws-secrets-manager-secrets-in-amazon-bedrock-agentcore-identity/)