Stop met het plakken van AWS-toegangssleutels in je .env-bestanden.

We zijn er allemaal wel eens geweest. Het is laat, je bent een Lambda-permissiefout aan het debuggen, en je AI-assistent blijft servicenamen of ARNs met verzonnen account-ID's verzinnen. Je wilt dat het model je werkelijke resources ziet, zodat het stopt met hallucineren en begint met het oplossen. Uit wanhoop pak je een toegangssleutel, zet je die in een omgevingsbestand en voer je deze aan de agent. Het werkt. Er valt een last van je schouders. Maar dan komt de ochtend, en je realiseert je dat dat geheim in je shell-geschiedenis, terminal-scrollback, of erger nog, in een commit staat die zojuist naar een gedeelde repository is gepusht.

Dit is precies de puinhoop die het Model Context Protocol bedoeld was te voorkomen.

MCP creëert een standaardbrug tussen je AI-agent en externe systemen. In plaats van ruwe inloggegevens over te dragen en te hopen dat de agent ze niet lekt, maak je verbinding via een gecontroleerde server die de authenticatie afhandelt, permissies afkadert en je sleutels volledig buiten het chatvenster houdt.

Voor AWS heb je momenteel twee officiële MCP-servers om uit te kiezen. De verkeerde keuze maakt je agent ofwel blind, of geeft hem juist te veel toegang met te weinig toezicht.

Ken het verschil: Kennis versus Handen

De eerste optie is de AWS Knowledge MCP Server. Zie het als een senior engineer die de volledige AWS-documentatielibrary uit zijn hoofd kent, maar geen inloggegevens heeft voor jouw account. Het is ontworpen als 'read-only' en verwijst naar officiële AWS-documentatie om de agent te voorzien van de juiste API-syntax, correcte servicenamen en de huidige best practices.

Je hebt geen AWS-account nodig om het te gebruiken. Je verbindt het niet met je infrastructuur. Je start het op wanneer je een architectuurdiagram schetst, een nieuwe service zoals ECS of EventBridge leert kennen, of wilt controleren of een specifieke API-aanroep nog steeds werkt zoals je je dat twee jaar geleden herinnert. Het voorkomt dat de agent gaat gokken. Als je vraagt om Terraform te schrijven voor een S3-bucketpolicy, weet het model de echte velden en geldige waarden omdat het informatie haalt uit de bron, en niet uit trainingsdata die vorig jaar is gestopt.

De tweede optie is de AWS MCP Server (Managed). Deze geeft je agent handen, niet alleen een geheugen. Met de juiste authenticatie kan het je CloudWatch-logs inspecteren, je S3-buckets opsommen, de schema's van je DynamoDB-tabellen lezen, IAM-policies controleren die aan een rol zijn gekoppeld, of verifiëren welke security groups openstaan voor het internet. Het werkt op je echte account, wat het krachtig maakt voor het oplossen van problemen in productie of het refactoren van live infrastructuur.

De Managed server weigert langdurige sleutels (long-lived keys). Het authenticeert via OAuth via een browser-login, of via de AWS CLI met behulp van SigV4-signing. Elke tool-aanroep vindt plaats met kortstondige tokens, elke actie laat een spoor achter in CloudTrail, en de agent opereert strikt binnen de IAM-grenzen die jij definieert. Het kan niet buiten zijn permissies treden omdat het gebonden is aan dezelfde policy-engine die elke andere AWS-gebruiker of rol in jouw organisatie beheert.

Dit is de gouden regel om te onthouden: de ene server geeft je agent kennis, de andere geeft hem handen. Gebruik de Knowledge server wanneer je aan het studeren of ontwerpen bent. Gebruik de Managed server wanneer je aan het opereren of repareren bent.

Waarom AWS de Managed Server aanbeveelt voor de meeste taken

AWS stuurt de meeste gebruikers nu richting de enkele Managed MCP Server in plaats van beide parallel te draaien. De Managed server heeft de documentatiecontext die de Knowledge server bood geabsorbeerd, waardoor het zowel referentiemateriaal als live accountacties onder één endpoint afhandelt.

Het tegelijkertijd draaien van beide servers kan de ervaring zelfs verslechteren. De agent ontvangt overlappende tool-definities en kan in de war raken over de vraag of hij een read-only documentatie-opzoeking moet doen of een live API-aanroep tegen jouw account. Die aarzeling zorgt voor tragere reacties en incidentele fouten bij het selecteren van tools. Het consolideren naar de Managed server vereenvoudigt je configuratie en houdt de agent gefocust.

Het instellen van de Managed Server met OAuth

Het draaiend krijgen van de Managed server duurt ongeveer vijf minuten, maar de stappen zijn belangrijk omdat dit een live verbinding met je account is.

Stap 1: Bereid je IAM-identiteit voor

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.