Smetti di incollare le chiavi di accesso AWS nei tuoi file .env.
Ci siamo passati tutti. È tardi, stai effettuando il debugging di un errore di autorizzazione Lambda e il tuo assistente AI continua a inventare nomi di servizi o ARN con ID account immaginari. Vuoi che il modello veda le tue risorse reali in modo che smetta di allucinare e inizi a risolvere. Per disperazione, prendi una chiave di accesso, la inserisci in un file di ambiente e la passi all'agente. Funziona. Provi un senso di sollievo. Poi arriva il mattino e ti rendi conto che quel segreto si trova nella cronologia della shell, nello scrollback del terminale o, peggio, in un commit appena inviato a un repository condiviso.
Questo è esattamente il caos che il Model Context Protocol è stato creato per prevenire.
MCP crea un ponte standard tra il tuo agente AI e i sistemi esterni. Invece di consegnare credenziali grezze sperando che l'agente non le divulghi, ti connetti attraverso un server controllato che gestisce l'autenticazione, definisce gli scope dei permessi e mantiene le tue chiavi completamente fuori dalla finestra della chat.
Per AWS, hai attualmente due server MCP ufficiali tra cui scegliere. Scegliere quello sbagliato lascerà il tuo agente cieco oppure gli darà troppo accesso con troppo poco controllo.
Conosci la differenza: Conoscenza vs. Azione
La prima opzione è l'AWS Knowledge MCP Server. Immaginalo come un ingegnere senior che ha memorizzato l'intera libreria di documentazione AWS ma non ha credenziali di accesso per il tuo account. È di sola lettura per progettazione, facendo riferimento alla documentazione ufficiale di AWS per fornire all'agente una base solida su sintassi API reali, nomi di servizi corretti e best practice attuali.
Non hai bisogno di un account AWS per usarlo. Non lo colleghi alla tua infrastruttura. Lo attivi quando stai abbozzando un diagramma di architettura, imparando un nuovo servizio come ECS o EventBridge, o verificando se una particolare chiamata API si comporta ancora come ricordavi di due anni fa. Impedisce all'agente di tirare a indovinare. Se gli chiedi di scrivere Terraform per una policy di un bucket S3, conoscerà i campi reali e i valori validi perché sta attingendo dalla fonte, non dai dati di addestramento che si sono interrotti l'anno scorso.
La seconda opzione è l'AWS MCP Server (Managed). Questo dà al tuo agente la capacità di agire, non solo la memoria. Con l'autenticazione appropriata, può ispezionare i tuoi log CloudWatch, elencare i tuoi bucket S3, leggere gli schemi delle tabelle DynamoDB, controllare le policy IAM associate a un ruolo o verificare quali security group sono aperti su Internet. Opera sul tuo account reale, il che lo rende potente per la risoluzione di problemi di produzione o per il refactoring di infrastrutture live.
Il server Managed rifiuta le chiavi a lunga durata. Si autentica tramite OAuth tramite accesso via browser, o tramite AWS CLI utilizzando la firma SigV4. Ogni chiamata di tool avviene con token a breve durata, ogni azione lascia una traccia in CloudTrail e l'agente opera rigorosamente entro i confini IAM che definisci. Non può vagare al di fuori dei suoi permessi perché è vincolato dallo stesso motore di policy che governa ogni altro utente o ruolo AWS nella tua organizzazione.
Ecco la regola d'oro da ricordare: un server fornisce al tuo agente la conoscenza, l'altro gli fornisce la capacità di agire. Usa il server Knowledge quando studi o progetti. Usa il server Managed quando operi o ripari.
Perché AWS raccomanda il server Managed per la maggior parte dei compiti
AWS ora spinge la maggior parte degli utenti verso il singolo Managed MCP Server piuttosto che farli eseguire entrambi in parallelo. Il server Managed ha assorbito il contesto della documentazione che il server Knowledge forniva, quindi gestisce sia il materiale di riferimento che le azioni sull'account live sotto un unico endpoint.
Eseguire entrambi i server simultaneamente può effettivamente degradare l'esperienza. L'agente riceve definizioni di tool sovrapposte e può confondersi su se chiamare una ricerca di documentazione in sola lettura o un'API live sul tuo account. Questa esitazione produce risposte più lente ed occasionali errori di selezione del tool. Consolidare tutto nel server Managed semplifica la tua configurazione e mantiene l'agente concentrato.
Configurazione del server Managed con OAuth
Mettere in funzione il server Managed richiede circa cinque minuti, ma i passaggi sono importanti perché si tratta di una connessione live al tuo account.
Passaggio 1: Prepara la tua 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.