AWS MCP Servers: Why Raw Access Isn't Enough

AWS has been shipping official MCP servers for its services: EC2, S3, Lambda, CloudWatch, Cost Explorer, and a growing list of others. Point Claude Code, Cursor, or your own agent at one and it gets tools for that service instantly, no custom integration code. It is a genuinely useful piece of plumbing. It is also easy to mistake for a security boundary, which it was never built to be.

What an AWS MCP server actually does

The Model Context Protocol standardizes how an agent discovers and calls tools. An AWS MCP server wraps an AWS SDK client and exposes each API operation, or a curated subset, as a callable tool with a typed schema. The protocol spec covers the transport: how the agent lists available tools and how it invokes one. It says nothing about authorization.

So when you run an AWS MCP server, you have decided two things whether you meant to or not:

• What credentials the server runs with. Usually whatever is in the ambient AWS credential chain on the machine running it.
• What that identity can do. Every tool the server exposes inherits the full permission set of those credentials, not just the permissions the current task needs.

The server is a very capable translator between “the agent wants to do X” and “call the AWS API for X.” It is not a gatekeeper that asks whether X should happen.

Where raw MCP access to AWS breaks down

The credentials are as broad as whoever configured the server. Most setups point the server at a developer’s AWS profile or a role with wide service access, because narrowing it per-tool is tedious. The agent then has that same width for every call, whether it is listing S3 buckets or deleting one.

There is no approval step. A human reviewing “read this CloudWatch log group” and “terminate this EC2 fleet” before either happens is not something the MCP layer provides. The agent calls the tool, the SDK call executes, and the result comes back. If the call was wrong, it already ran.

Prompt injection reaches real infrastructure. An agent that reads a support ticket, a log line, or a file from S3 as part of its task is reading untrusted text. If that text can talk the agent into calling a destructive tool, prompt injection stops being a chatbot problem and becomes an AWS incident. The MCP server has no way to tell the difference between a call the operator intended and one the agent was steered into.

Attribution is an afterthought. CloudTrail records what the underlying credentials did, same as any SDK caller. Unless you explicitly set sts:SourceIdentity on the session, “an agent did this” and “you did this” look identical in the logs. Reconstructing which agent, on whose behalf, for what task, requires work nobody did by default.

No rollback. If a tool call changes a security group or overwrites a Lambda’s configuration, “what was it before, and how do we put it back” is not something the MCP server tracks. You are back to manual forensics.

Raw AWS MCP server vs. a governed one

	Raw AWS MCP server	Governed control plane behind MCP
Credentials	Ambient, usually broad	Short-lived role, assumed per request
Tool scope	Full API surface of the SDK	Typed, risk-tiered operations
Destructive calls	Execute immediately	Held for human approval
Attribution	Manual SourceIdentity setup, if any	Automatic, per agent seat
Rollback	None	Captured for governed fix operations
Audit	CloudTrail only	CloudTrail plus a tamper-evident ledger

Closing the gap without giving up MCP

None of this means skip MCP for AWS. It means put governance where the MCP server currently has none.

Never run the server with your own broad credentials. Create a dedicated role scoped to what the agent’s task actually needs and assume it with short-lived STS credentials, the same discipline covered in how to give Claude Code safe AWS access. Read-only first, always.

Set SourceIdentity on every session so CloudTrail can tell an agent’s actions apart from a human’s, and so you can alert on that identity specifically.

Put a broker between the MCP server and AWS for anything destructive. The MCP server should call typed, risk-tiered operations, not raw SDK methods. Reads execute immediately; writes above a severity threshold pause in an approvals queue until a person signs off. That is the same pattern behind guardrails that actually work: the check lives outside the model, so a poisoned prompt cannot approve its own destructive call.

Log more than CloudTrail gives you for free. Which agent, on whose behalf, was this call part of, and what would reverse it. That is what turns “we can see the API calls” into an audit trail an auditor will accept, not just a debugging aid.

How Mesoplane approaches it

Mesoplane puts a governed control plane behind the MCP facade instead of wiring an MCP server straight to AWS credentials. The agent calls typed operations; Mesoplane assumes a short-lived role in your account per request, holds no standing credentials, requires human approval for destructive changes above a policy threshold, and records every call on a tamper-evident ledger attributed to the agent’s seat via SourceIdentity. The same governed operations project through Claude Code skills, the HTTP API, and MCP, so you get the discovery benefit AWS’s MCP servers give you without inheriting their blast radius. See the full security model for how the no-standing-credentials design works.

Frequently asked questions

What is an AWS MCP server?

It is a server that speaks the Model Context Protocol and exposes AWS APIs as tools an agent can call: list EC2 instances, query CloudWatch logs, describe an RDS cluster, and so on. AWS publishes an official set of these servers (awslabs) covering common services. They handle discovery and the wire format. They do not decide whether a given agent should be allowed to run a given call against your account.

Is it safe to connect an AWS MCP server directly to my account?

It is safe for read-only exploration if the server runs with a scoped, read-only role. It stops being safe the moment the underlying credentials can write, because the MCP layer itself has no concept of approval, blast radius, or rollback. A prompt-injected or simply wrong tool call executes with whatever permissions the server's credentials carry.

Do AWS MCP servers support approvals or audit logging?

Not natively. CloudTrail logs the API calls the underlying credentials make, the same as it would for any SDK caller, but it does not attribute actions to a specific agent unless you set SourceIdentity yourself, and there is no built-in approval gate before a destructive call executes. You have to build that layer, or put a governed broker in front of the MCP server.