Pare de colar chaves de acesso da AWS em seus arquivos .env.

Todos nós já passamos por isso. É tarde da noite, você está depurando um erro de permissão do Lambda e seu assistente de IA continua inventando nomes de serviços ou ARNs com IDs de conta imaginários. Você quer que o modelo veja seus recursos reais para que ele pare de alucinar e comece a consertar. Por desespero, você pega uma chave de acesso, coloca em um arquivo de ambiente e a fornece ao agente. Funciona. Um alívio surge. Então a manhã chega, e você percebe que esse segredo está no seu histórico do shell, no scrollback do terminal ou, pior, em um commit que acabou de ser enviado para um repositório compartilhado.

Este é exatamente o tipo de confusão que o Model Context Protocol foi construído para evitar.

O MCP cria uma ponte padrão entre seu agente de IA e sistemas externos. Em vez de entregar credenciais brutas e torcer para que o agente não as vaze, você se conecta por meio de um servidor controlado que gerencia a autenticação, define escopos de permissão e mantém suas chaves totalmente fora da janela de chat.

Para a AWS, você tem atualmente dois servidores MCP oficiais para escolher. Escolher o errado deixa seu agente cego ou dá a ele acesso excessivo com pouca supervisão.

Saiba a Diferença: Conhecimento vs. Mãos

A primeira opção é o AWS Knowledge MCP Server. Pense nele como um engenheiro sênior que memorizou toda a biblioteca de documentação da AWS, mas não possui credenciais de login para sua conta. Ele é apenas de leitura por design, referenciando a documentação oficial da AWS para fundamentar o agente em sintaxes de API reais, nomes de serviços corretos e as melhores práticas atuais.

Você não precisa de uma conta AWS para usá-lo. Você não o conecta à sua infraestrutura. Você o ativa quando está esboçando um diagrama de arquitetura, aprendendo um novo serviço como ECS ou EventBridge, ou validando se uma chamada de API específica ainda se comporta da maneira que você lembra de dois anos atrás. Ele impede que o agente tente adivinhar. Se você pedir para ele escrever um Terraform para uma política de bucket S3, ele conhecerá os campos reais e os valores válidos porque está extraindo da fonte, não de dados de treinamento que foram interrompidos no ano passado.

A segunda opção é o AWS MCP Server (Managed). Este dá ao seu agente mãos, não apenas memória. Com a autenticação adequada, ele pode inspecionar seus logs do CloudWatch, listar seus buckets S3, ler os esquemas de suas tabelas DynamoDB, verificar políticas de IAM anexadas a uma função ou verificar quais grupos de segurança estão abertos para a internet. Ele opera em sua conta real, o que o torna poderoso para solucionar problemas de produção ou refatorar infraestruturas ativas.

O servidor Managed recusa chaves de longa duração. Ele autentica por meio de OAuth via login no navegador, ou através da AWS CLI usando a assinatura SigV4. Cada chamada de ferramenta acontece com tokens de curta duração, cada ação deixa um rastro no CloudTrail, e o agente opera estritamente dentro dos limites de IAM que você define. Ele não pode vagar fora de suas permissões porque está vinculado ao mesmo mecanismo de política que governa todos os outros usuários ou funções da AWS em sua organização.

Aqui está a regra de ouro para lembrar: um servidor dá conhecimento ao seu agente, o outro dá mãos. Use o servidor Knowledge quando estiver estudando ou projetando. Use o servidor Managed quando estiver operando ou reparando.

Por que a AWS Recomenda o Servidor Managed para a Maioria das Tarefas

A AWS agora direciona a maioria dos usuários para o único Managed MCP Server em vez de executar ambos em paralelo. O servidor Managed absorveu o contexto de documentação que o servidor Knowledge fornecia, portanto, ele lida tanto com material de referência quanto com ações de conta ao vivo sob um único endpoint.

Executar ambos os servidores simultaneamente pode, na verdade, degradar a experiência. O agente recebe definições de ferramentas sobrepostas e pode ficar confuso sobre se deve chamar uma consulta de documentação de apenas leitura ou uma API ao vivo contra sua conta. Essa hesitação produz respostas mais lentas e erros ocasionais de seleção de ferramenta. Consolidar no servidor Managed simplifica sua configuração e mantém o agente focado.

Configurando o Servidor Managed com OAuth

Colocar o servidor Managed para funcionar leva cerca de cinco minutos, mas as etapas importam porque esta é uma conexão ao vivo com sua conta.

Passo 1: Prepare sua identidade IAM

Crie ou selecione uma role ou usuário IAM dedicado. Não use sua conta Root. Anexe a política gerenciada chamada AWSMCPSignInOAuthAccessPolicy a ele. Esta política concede apenas as permissões necessárias para iniciar o fluxo de login OAuth para acesso ao MCP. Ela não concede direitos administrativos amplos por si só. As capacidades reais que seu agente terá são determinadas pelo restante das políticas IAM que você anexar a essa identidade. Se você quiser que o agente leia logs do CloudWatch, mas nunca toque em IAM ou faturamento, crie uma política personalizada que permita logs:DescribeLogGroups e logs:FilterLogEvents e nada mais.

Passo 2: Configure seu cliente

Adicione a URL oficial do servidor AWS MCP à configuração do seu cliente. Isso funciona com Claude Desktop, Claude Code e Kiro. No seu arquivo de configurações do MCP, registre o endpoint do servidor para que o cliente saiba para onde rotear as chamadas de ferramentas relacionadas à AWS.

Passo 3: Autentique-se através do seu navegador

Na primeira vez que o agente tentar invocar uma ferramenta da AWS, seu sistema operacional abrirá uma janela do navegador. Faça login com a mesma identidade IAM que você preparou no Passo 1. O fluxo OAuth retorna um token de curta duração para o servidor MCP. Você não verá uma chave secreta. Você não colará nada em um arquivo de configuração. O token é atualizado automaticamente e expira rapidamente.

Passo 4: Verifique o limite de confiança

Uma vez autenticado, abra o CloudTrail e confirme que as ações aparecem sob a identidade que você criou. Você deve ver eventos como ListBuckets ou DescribeInstances vinculados àquele usuário ou role IAM específico. Se você vir atividade da conta Root, você fez algo errado e deve revogar a sessão imediatamente.

Se o OAuth não se ajustar ao seu fluxo de trabalho, o servidor Managed também suporta autenticação SigV4 por meio de suas credenciais existentes da AWS CLI. Esse caminho pula o pop-up do navegador, mas você ainda se beneficia do servidor MCP gerenciando a assinatura e o gerenciamento de sessão, em vez de expor credenciais brutas ao agente.

Hábitos de Segurança que Realmente Importam

Um servidor MCP é tão seguro quanto a identidade IAM por trás dele.

Comece com o privilégio mínimo. Seu agente não precisa de AdministratorAccess para corrigir uma integração do API Gateway mal roteada. Dê a ele exatamente as permissões de leitura ou escrita necessárias para a tarefa atual e rotacione-as ou revogue-as quando o trabalho estiver concluído. Se estiver usando uma role, defina uma duração de sessão curta. Se estiver usando um usuário, habilite MFA onde quer que suas ferramentas permitam.

Nunca autorize como o usuário Root. O Root ignora as políticas de controle de serviço (SCPs) e desfruta de acesso irrestrito em toda a conta. Se o agente interpretar incorretamente um prompt e tentar excluir recursos, você vai querer que essa solicitação seja bloqueada por uma política de limite (boundary policy). O Root não possui tais proteções.

Por fim, trate o agente como um novo estagiário que segue instruções perfeitamente, mas carece de bom senso. Ele executará o que você pedir, de forma literal e imediata. Se você disser para "limpar grupos de segurança não utilizados", ele pode encerrar o que está anexado ao seu banco de dados de produção porque ele correspondeu aos critérios amplos que você forneceu. Revise qualquer comando destrutivo antes de confirmá-lo, especialmente quando o agente tiver acesso de escrita.

A Conclusão Real

Você não precisa trocar segurança por utilidade. O Managed AWS MCP Server permite que seu assistente de IA veja sua infraestrutura real, corrija suas próprias alucinações e opere dentro da mesma estrutura IAM que governa o restante de sua equipe. Você obtém contexto em tempo real sem expor segredos em arquivos de ambiente. Configure o fluxo OAuth, restrinja as permissões e deixe o agente trabalhar com os olhos abertos e as mãos presas às suas políticas.