If you're running AI coding agents like Claude Code or Cursor against AWS, the attack surface just got real. AWS MCP Server reached general availability, which means your agents can now call AWS APIs directly — not suggest code for you to run, but actually execute against your live infrastructure. That changes the security conversation entirely.
This post is for developers and platform engineers who are already wiring AI agents into their AWS workflows, or are about to. The performance story is fine; the permission story needs your attention first.
1. Why This Matters Now
For the past year, AI coding assistants have operated at arm's length from your cloud. The agent writes an aws s3 rm command, you paste it into a terminal, you take the blast. That friction was annoying — but it was also a forcing function for human review.
GA of the AWS MCP Server removes that friction in both directions. The convenience is real: agents can now scaffold infrastructure, query resource state, and run deployments without leaving the IDE workflow. But the failure modes shift too. Before, a hallucinated CLI command was embarrassing. Now, a misconfigured IAM role attached to your MCP server can let an agent — or a prompt injection payload riding inside an S3 object — touch production resources without a human in the loop.
The timing matters because "GA" signals enterprise readiness to decision-makers who may start approving these integrations broadly. If your org is about to roll this out at scale, the window to establish guardrails is right now, before the patterns calcify.
2. The Core Idea
The security perimeter of an AI agent is exactly as strong as the IAM role it inherits.
That sentence sounds obvious, but it breaks down in practice because teams default to over-permissioned roles when they want to "just make it work." With a human in the loop, overpermissioning is bad hygiene. With an autonomous agent, it's a live grenade.
Three things changed at GA that make this concrete:
| Capability | What It Means for Security |
|---|---|
| Full AWS API coverage (S3, Lambda, EC2, RDS, IAM, etc.) | Every service your agent can reach is a blast radius multiplier |
| IAM governance integrated at the MCP layer | You can and must scope the agent's role to minimum required actions |
| CloudTrail passthrough | Agent API calls appear in your audit logs — use this as your verification layer |
The analogy I keep coming back to: attaching AdministratorAccess to an MCP server is the equivalent of giving a junior contractor the master key to every floor of your building, including the server room. You wouldn't do that for a human. Don't do it for an agent.
The good news is that IAM's existing machinery — permission boundaries, service control policies, condition keys — works exactly the same for agent-sourced API calls. You don't need new tooling. You need to apply what you already know.
3. How to Implement It
Start with a purpose-built IAM role for your MCP server. Never reuse a developer role, a CI role, or anything with broad permissions inherited from somewhere else.
Step 1 — Create a scoped IAM policy
The following example allows read-only S3 access and Lambda invocation on a single function, nothing else. Adjust to your actual use case.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ReadOnly",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::my-project-bucket",
"arn:aws:s3:::my-project-bucket/*"
]
},
{
"Sid": "LambdaInvokeScoped",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-agent-function"
}
]
}
Step 2 — Attach a permission boundary
Even if someone later tries to attach a broader policy to this role, the permission boundary acts as a hard ceiling.
aws iam put-role-permissions-boundary \
--role-name mcp-agent-role \
--permissions-boundary arn:aws:iam::123456789012:policy/mcp-agent-boundary
Step 3 — Verify CloudTrail is capturing agent calls
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=Username,AttributeValue=mcp-agent-role \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--query 'Events[*].{Time:EventTime,Event:EventName,Source:EventSource}' \
--output table
Expected output: a table of API calls the agent made in the last hour. If this returns nothing, either the agent hasn't been called yet or CloudTrail isn't configured for the right region. Fix that before you go further.
Step 4 — Separate credentials per environment
Your development MCP server should never hold a credential that can touch production. Use separate AWS profiles:
# ~/.aws/config
[profile mcp-dev]
role_arn = arn:aws:iam::DEV_ACCOUNT_ID:role/mcp-agent-role
source_profile = default
region = us-east-1
[profile mcp-prod]
role_arn = arn:aws:iam::PROD_ACCOUNT_ID:role/mcp-agent-role
source_profile = default
region = us-east-1
Then in your MCP server config, explicitly reference the environment profile rather than the default credential chain:
aws_mcp_server:
profile: mcp-dev # never "default" in a shared environment
region: us-east-1
audit_mode: true
Step 5 — Scan new MCP servers before connecting
mcp-scan is a static analysis tool that inspects MCP server definitions for suspicious tool descriptions or prompt injection vectors before you connect.
npx mcp-scan@latest scan ./mcp-config.json
Look for warnings about overly broad tool descriptions, missing input validation, or tool names that shadow built-in commands. Any new MCP server you add to your stack should pass this check first.
4. What to Watch in Production
Prompt injection via data payloads. The most underappreciated risk isn't a misconfigured role — it's an agent reading a maliciously crafted S3 object, Slack message, or database row that contains instructions telling it to exfiltrate credentials or escalate permissions. Scope your agent's read access to only the buckets and tables it genuinely needs to operate.
IAM policy drift. Roles that start scoped tend to accumulate permissions over time as teams add features without revisiting the policy. Set a reminder to audit MCP agent roles quarterly with:
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:role/mcp-agent-role
# then retrieve the report:
aws iam get-service-last-accessed-details --job-id <job-id> \
--query 'ServicesLastAccessed[?TotalAuthenticatedEntities==`0`].ServiceName'
Any service that shows zero authenticated calls in the last 90 days should be removed from the policy.
Cross-environment credential leakage. On Mac and Linux, the default credential provider chain resolves to ~/.aws/credentials if no explicit profile is set. If a developer runs a dev MCP server locally with their personal credentials, you may be invoking with far more permissions than the role config suggests. Always set AWS_PROFILE explicitly in your MCP server launch script rather than relying on ambient credentials.
CloudTrail coverage gaps. By default, CloudTrail only captures management events, not S3 data events. If your agent is reading or writing S3 objects, you need to explicitly enable data event logging for those buckets:
aws cloudtrail put-event-selectors \
--trail-name my-trail \
--event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,"DataResources":[{"Type":"AWS::S3::Object","Values":["arn:aws:s3:::my-project-bucket/"]}]}]'
Blast radius on mutation actions. Actions like ec2:TerminateInstances, rds:DeleteDBInstance, or any iam:* call should be absent from agent roles unless there is a documented, reviewed reason. When in doubt, deny by default and add back with justification.
Closing
The AWS MCP Server GA is genuinely useful infrastructure — but the value only holds if your IAM posture is tight before you connect. Minimum-privilege roles, permission boundaries, CloudTrail data events, and environment credential isolation are not optional hardening steps. They are the baseline.
Next: once your CloudTrail pipeline is capturing agent calls, consider routing those events to CloudWatch Alerts or a SIEM. Anomalous call patterns — unusual regions, off-hours API bursts, or IAM self-modification attempts — become detectable signals rather than silent failures.
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: AI Insights
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기