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

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.