Secure AI Agent Access Patterns to AWS Resources Using MCP
AWS made the control question explicit in April 2026: when an AI agent touches AWS, which IAM principal is actually acting? That is the part people skip, and it is where the risk lives. A local assistant on a laptop, a hosted runtime on EC2 or EKS, and an AgentCore-based service all fail in different ways if you let them inherit the same broad credentials.
The new security guidance is not about whether MCP works. It is about where the trust boundary sits. Once you define the principal, the rest of the design becomes much clearer: session policies trim permissions, permission boundaries cap blast radius, and principal tags give you a clean way to report by team or workload.
Access Pattern Table
| Pattern | Where credentials live | Best control lever | Main risk |
|---|---|---|---|
| Local agent on a developer laptop | Developer profile, env vars, or named AWS CLI profile | Tight IAM role, session duration, permission boundary | The agent inherits admin-like access too easily |
| Hosted agent on EC2 or EKS | Execution role for the runtime | Session policy plus role separation | One runtime role can become a shared super-role |
| MCP client per tool or per service | Separate AssumeRole call for each integration | Tool-scoped credentials | More moving parts, but much safer |
| Human and agent on the same role | Same IAM principal | Context keys and explicit deny rules | You lose the ability to distinguish intent |
What the Architecture Looks Like
flowchart LR
Dev[Developer laptop or local agent] --> MCP[MCP server]
Host[AgentCore Runtime or EC2/EKS agent] --> STS[STS AssumeRole + session policy]
MCP --> AWS[AWS resources]
STS --> AWS
Tags[Principal tags and session tags] --> IAM[IAM policy evaluation]
IAM --> AWS
What To Do First
Start with the smallest possible principal. If a human is launching the agent, use a named profile or a short-lived role just for that task. If the agent is hosted, give the runtime one execution role and then split sensitive actions into separate STS calls with a session policy. That is the difference between a manageable assistant and a very fast path to over-privilege.
The practical gotcha is that MCP makes tool access feel modular, but IAM is still evaluated at the identity layer. If you do not split roles early, the agent will quietly accumulate permissions because it is easier to keep the code working than to fix the IAM model later.
Related reading
- AWS Bedrock agents + MCP in DevOps
- stateful MCP gateways and runtime design
- IAM role and policy design
- permission boundaries for guardrails
Sources
Explore more like this
Aurora Serverless v2 + Bedrock: AI Database Queries in 2026
I connected Bedrock to our Aurora cluster last month. The first thing I asked it was “show me all customers who churned in Q1 but came back in Q2” —...
AWS WAF Rules Deep Dive: Rate-Based, Geo, and Custom Rules
WAF is one of those services where the default managed rules get you 80% of the way there. The last 20% is where it gets interesting.
AWS VPC Design Patterns in 2026: From Single Account to Multi-Account Landing Zone
The VPC decisions you make on day one will follow you for years. I’ve lived through the consequences—redesigning a network that was built without proper CIDR planning, watching a simple...
Comments