Hör auf, AWS-Access-Keys in deine Dateien zu kopieren.

Stop pasting AWS access keys into your .env files.

We have all been there. It is late, you are debugging a Lambda permission error, and your AI assistant keeps inventing service names or ARNs with imaginary account IDs. You want the model to see your actual resources so it stops hallucinating and starts fixing. Out of desperation, you grab an access key, drop it into an environment file, and feed it to the agent. It works. Relief floods in. Then morning arrives, and you realize that secret is sitting in your shell history, terminal scrollback, or worse, a commit that just pushed to a shared repository.

This is the exact mess the Model Context Protocol was built to prevent.

MCP creates a standard bridge between your AI agent and external systems. Instead of handing over raw credentials and hoping the agent does not leak them, you connect through a controlled server that handles authentication, scopes permissions, and keeps your keys out of the chat window entirely.

For AWS, you currently have two official MCP servers to pick from. Choosing the wrong one either leaves your agent blind or gives it too much access with too little oversight.

Know the Difference: Knowledge vs. Hands

The first option is the AWS Knowledge MCP Server. Think of it as a senior engineer who has memorized the entire AWS documentation library but has no login credentials for your account. It is read-only by design, referencing official AWS docs to ground the agent in real API syntax, correct service names, and current best practices.

You do not need an AWS account to use it. You do not connect it to your infrastructure. You spin it up when you are sketching an architecture diagram, learning a new service like ECS or EventBridge, or validating whether a particular API call still behaves the way you remember from two years ago. It stops the agent from guessing. If you ask it to write Terraform for an S3 bucket policy, it knows the real fields and valid values because it is pulling from the source, not from training data that cut off last year.

The second option is the AWS MCP Server (Managed). This one gives your agent hands, not just memory. With proper authentication, it can inspect your CloudWatch logs, list your S3 buckets, read your DynamoDB table schemas, check IAM policies attached to a role, or verify which security groups are open to the internet. It operates on your real account, which makes it powerful for troubleshooting production issues or refactoring live infrastructure.

The Managed server refuses long-lived keys. It authenticates through OAuth via a browser sign-in, or through AWS CLI using SigV4 signing. Every tool call happens with short-lived tokens, every action leaves a trail in CloudTrail, and the agent operates strictly within the IAM boundaries you define. It cannot wander outside its permissions because it is bound by the same policy engine that governs every other AWS user or role in your organization.

Here is the golden rule to remember: one server gives your agent knowledge, the other gives it hands. Use the Knowledge server when you are studying or designing. Use the Managed server when you are operating or repairing.

Why AWS Recommends the Managed Server for Most Tasks

AWS now pushes most users toward the single Managed MCP Server rather than running both in parallel. The Managed server has absorbed the documentation context that the Knowledge server provided, so it handles both reference material and live account actions under one endpoint.

Running both servers simultaneously can actually degrade the experience. The agent receives overlapping tool definitions and can get confused about whether to call a read-only documentation lookup or a live API against your account. That hesitation produces slower responses and occasional tool-selection errors. Consolidating down to the Managed server simplifies your configuration and keeps the agent focused.

Setting Up the Managed Server with OAuth

Getting the Managed server running takes about five minutes, but the steps matter because this is a live connection to your account.

Step 1: Prepare your IAM identity

Erstellen oder wählen Sie eine dedizierte IAM-Rolle oder einen IAM-Benutzer aus. Verwenden Sie nicht Ihr Root-Konto. Verknüpfen Sie die verwaltete Richtlinie namens AWSMCPSignInOAuthAccessPolicy damit. Diese Richtlinie gewährt nur die Berechtigungen, die erforderlich sind, um den OAuth-Anmeldevorgang für den MCP-Zugriff zu initiieren. Sie gewährt für sich genommen keine weitreichenden Administratorrechte. Die tatsächlichen Fähigkeiten Ihres Agenten werden durch die restlichen IAM-Richtlinien bestimmt, die Sie dieser Identität zuweisen. Wenn der Agent CloudWatch-Logs lesen, aber niemals auf IAM oder die Abrechnung zugreifen soll, erstellen Sie eine benutzerdefinierte Richtlinie, die nur logs:DescribeLogGroups und logs:FilterLogEvents erlaubt und sonst nichts.

Schritt 2: Konfigurieren Sie Ihren Client

Fügen Sie die offizielle AWS MCP-Server-URL zu Ihrer Client-Konfiguration hinzu. Dies funktioniert mit Claude Desktop, Claude Code und Kiro. Registrieren Sie den Server-Endpunkt in Ihrer MCP-Einstellungsdatei, damit der Client weiß, wohin er AWS-bezogene Tool-Aufrufe leiten muss.

Schritt 3: Authentifizierung über Ihren Browser

Wenn der Agent das erste Mal versucht, ein AWS-Tool aufzurufen, öffnet Ihr Betriebssystem ein Browserfenster. Melden Sie sich mit derselben IAM-Identität an, die Sie in Schritt 1 vorbereitet haben. Der OAuth-Flow gibt einen kurzlebigen Token an den MCP-Server zurück. Sie werden keinen Secret Key sehen. Sie müssen nichts in eine Konfigurationsdatei kopieren. Der Token wird automatisch aktualisiert und läuft schnell ab.

Schritt 4: Überprüfen Sie die Vertrauensgrenze (Trust Boundary)

Öffnen Sie nach der Authentifizierung CloudTrail und bestätigen Sie, dass die Aktionen unter der von Ihnen erstellten Identität erscheinen. Sie sollten Ereignisse wie ListBuckets oder DescribeInstances sehen, die mit diesem spezifischen IAM-Benutzer oder dieser Rolle verknüpft sind. Wenn Sie Aktivitäten des Root-Kontos sehen, haben Sie etwas falsch gemacht und sollten die Sitzung sofort widerrufen.

Falls OAuth nicht zu Ihrem Workflow passt, unterstützt der Managed Server auch die SigV4-Authentifizierung über Ihre bestehenden AWS CLI-Anmeldedaten. Dieser Weg umgeht das Browser-Pop-up, aber Sie profitieren dennoch davon, dass der MCP-Server die Signierung und das Sitzungsmanagement übernimmt, anstatt dem Agenten rohe Anmeldedaten (Credentials) preiszugeben.

Sicherheitsgewohnheiten, die wirklich zählen

Ein MCP-Server ist nur so sicher wie die IAM-Identität, die dahintersteht.

Beginnen Sie mit dem Prinzip der geringsten Berechtigung (Least Privilege). Ihr Agent benötigt keinen AdministratorAccess, um eine falsch geroutete API Gateway-Integration zu beheben. Geben Sie ihm genau die Lese- oder Schreibberechtigungen, die für die aktuelle Aufgabe erforderlich sind, und rotieren oder widerrufen Sie diese, wenn die Aufgabe erledigt ist. Wenn Sie eine Rolle verwenden, legen Sie eine kurze Sitzungsdauer fest. Wenn Sie einen Benutzer verwenden, aktivieren Sie MFA, wo immer Ihre Tools dies zulassen.

Autorisieren Sie niemals als Root-Benutzer. Root umgeht Service Control Policies und genießt uneingeschränkten Zugriff auf das gesamte Konto. Wenn der Agent einen Prompt missversteht und versucht, Ressourcen zu löschen, möchten Sie, dass diese Anfrage durch eine Boundary Policy blockiert wird. Root verfügt über keine solchen Schutzmechanismen (Guardrails).

Behandeln Sie den Agenten schließlich wie einen neuen Praktikanten, der Anweisungen perfekt befolgt, aber keinen gesunden Menschenverstand hat. Er wird das ausführen, was Sie verlangen – buchstäblich und sofort. Wenn Sie ihm sagen, er solle „unbenutzte Security Groups aufräumen“, könnte er diejenige beenden, die an Ihre Produktionsdatenbank angeschlossen ist, weil sie den weit gefassten Kriterien entsprach, die Sie ihm gegeben haben. Überprüfen Sie alle destruktiven Befehle, bevor Sie diese bestätigen, insbesondere wenn der Agent Schreibzugriff hat.

Das eigentliche Fazit

Sie müssen keine Sicherheit gegen Nützlichkeit eintauschen. Der Managed AWS MCP Server ermöglicht es Ihrem KI-Assistenten, Ihre echte Infrastruktur zu sehen, seine eigenen Halluzinationen zu korrigieren und innerhalb desselben IAM-Frameworks zu arbeiten, das auch für den Rest Ihres Teams gilt. Sie erhalten Live-Kontext, ohne Secrets in Umgebungsvariablen-Dateien zu speichern. Richten Sie den OAuth-Flow ein, schränken Sie die Berechtigungen ein und lassen Sie den Agenten mit offenen Augen arbeiten, während seine Hände durch Ihre Richtlinien gebunden sind.