Arrêtez de coller vos clés d'accès AWS dans vos fichiers .env.
Nous sommes tous passés par là. Il est tard, vous déboguez une erreur de permission Lambda, et votre assistant IA n'arrête pas d'inventer des noms de services ou des ARNs avec des identifiants de compte imaginaires. Vous voulez que le modèle voie vos ressources réelles pour qu'il arrête d'halluciner et commence à réparer. Par désespoir, vous saisissez une clé d'accès, la déposez dans un fichier d'environnement et la transmettez à l'agent. Ça fonctionne. Un sentiment de soulagement vous envahit. Puis le matin arrive, et vous réalisez que ce secret se trouve dans votre historique de shell, dans le défilement de votre terminal ou, pire encore, dans un commit qui vient d'être poussé vers un dépôt partagé.
C'est précisément le genre de désordre que le Model Context Protocol a été conçu pour éviter.
Le MCP crée un pont standard entre votre agent IA et les systèmes externes. Au lieu de remettre des identifiants bruts en espérant que l'agent ne les divulgue pas, vous vous connectez via un serveur contrôlé qui gère l'authentification, définit les périmètres de permissions et garde vos clés totalement hors de la fenêtre de chat.
Pour AWS, vous avez actuellement deux serveurs MCP officiels au choix. Choisir le mauvais laissera votre agent aveugle ou lui donnera trop d'accès avec trop peu de surveillance.
Connaître la différence : Connaissance vs Action
La première option est l'AWS Knowledge MCP Server. Considérez-le comme un ingénieur senior qui a mémorisé toute la bibliothèque de documentation AWS mais qui ne possède aucun identifiant de connexion pour votre compte. Il est conçu en lecture seule, se référant à la documentation officielle d'AWS pour ancrer l'agent dans la syntaxe réelle des API, les noms de services corrects et les meilleures pratiques actuelles.
Vous n'avez pas besoin de compte AWS pour l'utiliser. Vous ne le connectez pas à votre infrastructure. Vous le lancez lorsque vous esquissez un diagramme d'architecture, apprenez un nouveau service comme ECS ou EventBridge, ou validez si un appel API particulier se comporte toujours comme vous vous en souvenez d'il y a deux ans. Cela empêche l'agent de deviner. Si vous lui demandez d'écrire du Terraform pour une politique de compartiment S3, il connaît les champs réels et les valeurs valides car il extrait les informations de la source, et non de données d'entraînement qui datent de l'année dernière.
La deuxième option est l'AWS MCP Server (Managed). Celui-ci donne des mains à votre agent, pas seulement de la mémoire. Avec une authentification appropriée, il peut inspecter vos journaux CloudWatch, lister vos compartiments S3, lire les schémas de vos tables DynamoDB, vérifier les politiques IAM attachées à un rôle ou vérifier quels groupes de sécurité sont ouverts sur Internet. Il opère sur votre compte réel, ce qui le rend puissant pour le dépannage de problèmes de production ou la refactorisation d'une infrastructure en direct.
Le serveur Managed refuse les clés à longue durée de vie. Il s'authentifie via OAuth par une connexion via navigateur, ou via l'AWS CLI en utilisant la signature SigV4. Chaque appel d'outil s'effectue avec des jetons à courte durée de vie, chaque action laisse une trace dans CloudTrail, et l'agent opère strictement dans les limites IAM que vous définissez. Il ne peut pas s'aventurer en dehors de ses permissions car il est lié par le même moteur de politique qui régit tous les autres utilisateurs ou rôles AWS de votre organisation.
Voici la règle d'or à retenir : un serveur donne la connaissance à votre agent, l'autre lui donne la capacité d'agir. Utilisez le serveur Knowledge lorsque vous étudiez ou concevez. Utilisez le serveur Managed lorsque vous exploitez ou réparez.
Pourquoi AWS recommande le serveur Managed pour la plupart des tâches
AWS pousse désormais la plupart des utilisateurs vers le serveur MCP Managed unique plutôt que de faire fonctionner les deux en parallèle. Le serveur Managed a absorbé le contexte de documentation que le serveur Knowledge fournissait, il gère donc à la fois le matériel de référence et les actions sur le compte en direct via un seul point de terminaison.
L'exécution simultanée des deux serveurs peut en réalité dégrader l'expérience. L'agent reçoit des définitions d'outils redondantes et peut hésiter entre une recherche dans la documentation en lecture seule ou un appel API en direct sur votre compte. Cette hésitation produit des réponses plus lentes et des erreurs occasionnelles de sélection d'outils. Consolider l'utilisation sur le serveur Managed simplifie votre configuration et permet à l'agent de rester concentré.
Configuration du serveur Managed avec OAuth
Mettre en marche le serveur Managed prend environ cinq minutes, mais les étapes sont cruciales car il s'agit d'une connexion en direct à votre compte.
Étape 1 : Préparez votre identité IAM
Create or select a dedicated IAM role or user. Do not use your Root account. Attach the managed policy named AWSMCPSignInOAuthAccessPolicy to it. This policy grants only the permissions required to initiate the OAuth sign-in flow for MCP access. It does not grant broad administrative rights by itself. The actual capabilities your agent will have are determined by the rest of the IAM policies you attach to that identity. If you want the agent to read CloudWatch logs but never touch IAM or billing, build a custom policy that allows logs:DescribeLogGroups and logs:FilterLogEvents and nothing else.
Step 2: Configure your client
Add the official AWS MCP server URL to your client configuration. This works with Claude Desktop, Claude Code, and Kiro. In your MCP settings file, register the server endpoint so the client knows where to route AWS-related tool calls.
Step 3: Authenticate through your browser
The first time the agent tries to invoke an AWS tool, your operating system opens a browser window. Sign in with the same IAM identity you prepared in Step 1. The OAuth flow returns a short-lived token to the MCP server. You will not see a secret key. You will not paste anything into a configuration file. The token refreshes automatically and expires quickly.
Step 4: Verify the trust boundary
Once authenticated, open CloudTrail and confirm that actions appear under the identity you created. You should see events like ListBuckets or DescribeInstances tied to that specific IAM user or role. If you see Root account activity, you did something wrong and should revoke the session immediately.
If OAuth does not fit your workflow, the Managed server also supports SigV4 authentication through your existing AWS CLI credentials. That path skips the browser pop-up, but you still benefit from the MCP server handling the signing and session management rather than exposing raw credentials to the agent.
Security Habits That Actually Matter
An MCP server is only as safe as the IAM identity behind it.
Start with least privilege. Your agent does not need AdministratorAccess to fix a misrouted API Gateway integration. Give it exactly the read or write permissions required for the current task, and rotate or revoke them when the job is done. If you are using a role, set a short session duration. If you are using a user, enable MFA wherever your tooling allows it.
Never authorize as the Root user. Root bypasses service control policies and enjoys unrestricted access across the entire account. If the agent misinterprets a prompt and attempts to delete resources, you want that request blocked by a boundary policy. Root has no such guardrails.
Finally, treat the agent like a new intern who follows instructions perfectly but lacks common sense. It will execute what you ask, literally and immediately. If you tell it to "clean up unused security groups," it might terminate the one attached to your production database because it matched the broad criteria you gave it. Review any destructive commands before confirming them, especially when the agent has write access.
The Real Takeaway
You do not need to trade security for usefulness. The Managed AWS MCP Server lets your AI assistant see your real infrastructure, correct its own hallucinations, and operate within the same IAM framework that governs the rest of your team. You get live context without dropping secrets into environment files. Set up the OAuth flow, lock down the permissions, and let the agent work with its eyes open and its hands tied to your policies.