AWS MCP Server: agent access to your account, scoped by IAM

AWS made the MCP Server generally available on May 6, and the part worth your attention is not that an AI agent can now reach AWS. That was already possible if you were willing to hand-roll a server or, worse, paste an access key into a config file. What changed is that the access now flows through IAM the same way a console session or an SDK call does, with a managed endpoint AWS runs for you and two new context keys that let you tell agent-driven calls apart from your own.

That distinction is the whole story. A coding agent with your credentials is exactly as dangerous as your credentials, and most people wiring up MCP servers over the past year quietly skipped that math. The GA release gives you the tools to do the math properly. This is how it actually works, where the sharp edges are, and the IAM policy I would put in place before letting any agent near a production account.

What the server actually exposes

The AWS MCP Server is a managed, remote Model Context Protocol server. AWS hosts it, so there is nothing to run locally and nothing to patch. It presents a small, fixed set of tools rather than one tool per service, which keeps the agent's context window from drowning in thousands of tool definitions.

The one that matters is call_aws. It executes any of the 15,000-plus AWS API operations using your existing IAM credentials, and AWS adds new APIs within days of their launch. So instead of a connector that wraps forty hand-picked operations, the agent gets the entire API surface, gated by what your IAM policy allows. There is also run_script, which lets the agent write a short Python script that runs server-side in a sandboxed environment, plus search_documentation and read_documentation for pulling current AWS docs at query time. Documentation retrieval no longer needs authentication at all, which is a small but welcome GA change.

If you have read my piece on keeping agents inside your network perimeter with Claude MCP tunnels, the mental model is similar but inverted. Tunnels are about letting an agent reach a private MCP server you host. This is AWS hosting the server and the agent reaching out to it. Both come down to the same question: what is this thing allowed to do once it connects?

Wiring it into Claude Code

Setup is one command. For Claude Code, you register the proxy and point it at the regional endpoint:

claude mcp add-json aws-mcp --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws==1.6.0","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'

The mcp-proxy-for-aws client signs each request with SigV4 using whatever AWS credentials the proxy resolves from your environment, then forwards it to the managed endpoint. The endpoint is available in US East (N. Virginia) and Europe (Frankfurt) at GA, and the AWS_REGION metadata controls which region the operations target, not where the MCP endpoint lives.

The server is the same for Claude Code, Kiro, Cursor, Codex, and any MCP-compatible client, so the setup differs only in how each client registers an MCP server. There is no additional charge for the server itself. You pay for the AWS resources the agent creates and any data transfer, nothing more.

So far this reads like a clean developer-experience win, and it is. The risk is entirely in the credentials the proxy picks up.

The credential question nobody wants to answer

Here is the failure mode. You already have AWS credentials on your machine, probably an admin or power-user profile, because that is what you use day to day. The proxy resolves those credentials by default. So the moment you finish that setup command, your coding agent can call any of 15,000 APIs with your full permissions. call_aws does not care whether the request to delete a production bucket came from your fingers or from a model that misread a prompt.

Before GA, the only honest mitigation was to run the agent under a dedicated, scoped IAM role and never under your real identity. That advice still holds, and it is the first thing to get right. Create a role with only the permissions the agent needs, point the proxy at a profile that assumes it, and keep your admin credentials out of the agent's reach entirely.

[profile agent-aws]
role_arn = arn:aws:iam::111122223333:role/coding-agent-readonly
source_profile = default
region = us-west-2

The proxy resolves credentials the same way the AWS CLI does, so pointing it at that scoped profile is a matter of setting AWS_PROFILE=agent-aws in the environment the MCP client launches from. Get this wrong and the proxy silently falls back to your default profile, which is how people end up handing an agent admin access without realizing it. Verify which identity the agent is using with a call_aws to sts:GetCallerIdentity before you trust it with anything.

A read-only role is the safe default for an agent that is mostly reading state, describing resources, and reasoning about your infrastructure. Grant write access deliberately, service by service, only once you have watched what the agent actually does. This is the same discipline I lean on when I run Claude Code in CI/CD pipelines: the automation gets a narrow role, never the keys a human would use.

It is worth understanding when the agent reaches for run_script instead of call_aws. A single API call answers a single question. But "find every unencrypted EBS volume across all regions and group them by account" is dozens of paginated calls stitched together, and asking the model to orchestrate that one call_aws at a time burns tokens and time. run_script lets it write a short boto3 script that runs server-side in the sandbox and returns just the answer. The same IAM credentials and context keys apply, so your policy governs the script exactly as it governs a direct call. There is no separate escape hatch to worry about.

Context keys: telling the agent apart from you

The genuinely new capability at GA is a pair of IAM context keys the managed server attaches to every request before forwarding it downstream:

• aws:ViaAWSMCPService is a boolean, set to true when the request comes through an AWS-managed MCP server.
• aws:CalledViaAWSMCP is a string holding the service principal of the specific MCP server, for example aws-mcp.amazonaws.com.

These let you write policy that treats agent-initiated calls differently from your own, even when both use the same underlying identity. That is the lever the earlier hand-rolled approach never had. You can let a developer delete an S3 object from the console while blocking the exact same action when it arrives through an agent.

The most conservative starting point is a service control policy or IAM boundary that denies everything via MCP, then opens up only what you have reviewed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllActionsViaMCP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": { "aws:ViaAWSMCPService": "true" }
      }
    }
  ]
}

More often you want the agent to read freely but never destroy anything. A targeted deny on the irreversible operations does that without crippling the agent's usefulness:

{
  "Sid": "DenyDestructiveActionsViaMCP",
  "Effect": "Deny",
  "Action": [
    "s3:DeleteObject",
    "s3:DeleteBucket",
    "dynamodb:DeleteTable",
    "rds:DeleteDBInstance",
    "ec2:TerminateInstances"
  ],
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:ViaAWSMCPService": "true" }
  }
}

And when you run more than one managed server, aws:CalledViaAWSMCP lets you scope a permission to exactly one of them, so an EKS-focused server can touch EKS while the general server cannot:

{
  "Sid": "AllowEKSOnlyViaEKSMCP",
  "Effect": "Allow",
  "Action": "eks:*",
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:CalledViaAWSMCP": "eks-mcp.amazonaws.com" }
  }
}

A deny with aws:ViaAWSMCPService is the safety net I would not skip. Even with a scoped role, an explicit deny on destructive actions means a misconfigured role or an over-broad grant cannot quietly become a way for an agent to delete production data.

Watch what it does before you trust it

Every call the agent makes lands in CloudTrail like any other API call, with the context keys recorded, so you can audit exactly what an agent did and when. The server also publishes metrics to CloudWatch under the AWS-MCP namespace. The honest workflow is to start restrictive, run the agent against a non-production account, then read the CloudTrail log to learn its real access pattern before you widen anything.

This is the same posture I argue for in my write-up on catching AWS bill spikes before they hit: you cannot govern what you cannot see, and an agent calling APIs in a loop is precisely the kind of thing that shows up as a surprise later. Tie the agent role into your existing cost anomaly rules so a runaway call_aws loop pages someone instead of just appearing on next month's invoice. For regulated environments, AWS has flagged VPC endpoint support as coming, which will let you keep the traffic to the managed server on private network paths rather than the public internet. Until then, the network control you have is IAM, so lean on it.

What changed from preview, and what it means for skills

The preview shipped last November. GA added the IAM context keys, dropped the auth requirement for documentation, reduced the tokens spent per interaction, introduced run_script, and moved its curated guidance from the old "Agent SOPs" model to Skills. That last shift matters if you have invested in Claude Code Skills already. The server now slots into the same Skills mechanism I covered in the Claude Code power-user guide, so the patterns you wrote for your own workflows extend to how the agent approaches AWS operations.

It also means the AWS MCP Server is no longer a thing you bolt on awkwardly. It behaves like a first-class part of the agent toolchain, which is exactly why the IAM side deserves more care, not less. The easier it is to connect, the more accounts it will end up connected to.

Where it fits and where I would hold back

For reading state, exploring an unfamiliar account, drafting infrastructure changes, and answering "what is actually deployed here" questions, this is excellent. The agent reasons over live data instead of stale assumptions, and a read-only role makes the blast radius effectively zero. I would turn this on for any account I am actively working in.

For write operations against production, I am slower. call_aws reaching 15,000 operations is power, and power applied by something that occasionally misreads intent needs guardrails that match. Scoped role, explicit denies on destructive actions, CloudTrail review, and a non-production account to learn in first. The plumbing is solid. Whether it stays safe depends on the policy you write around it.

The shift the GA marks is real: AI agents now reach AWS through the same identity layer everything else uses, instead of through a side door you built yourself. That is strictly better than where we were. It just moves the hard problem from "how do I connect this" to "what is it allowed to do," and the second question is the one worth your evening.