Secure AI Agent MCP Access Architecture Diagram: AWS IAM Token Isolation Patterns

The AWS Security Blog post of 14 April 2026 uses IAM as the authorization layer when agents reach AWS through MCP. It says to assume an agent can exercise anything inside its entitlements: OAuth scopes, API keys, or IAM. Three principles cover local assistants such as Kiro and Claude Code, and agents on AgentCore. The 1 September 2026 architecture post is a stateless protocol revision, not this credential split.

What this secure AI agent MCP access architecture diagram shows

An agent runs on a developer machine or on infrastructure you control: AgentCore Runtime, EC2, or EKS. It holds a credential, calls an MCP server, and that server calls AWS. Local credentials come from a named profile, environment variables, or mcp.json. On AgentCore the execution role applies to every operation and, the security post says, cannot be narrowed per invocation in the runtime configuration. Code you control calls AssumeRole or AssumeRoleWithWebIdentity and gives each MCP client its own temporary access key, secret, and session token. That session is the isolation box. It is not a separate vault product. AWS-managed MCP servers stamp condition keys on the downstream call. Self-managed servers do not, unless your code tags the assumed role.

The problem this architecture is solving

Human roles are often broad because a person is expected to judge the call. The post says an agent with that role does not, and that impact grows because agents run at machine speed. It publishes no rate. Granted actions still happen through hallucination, prompt injection, logic errors, or tool poisoning inside permissions you already gave. If the job is a read, grant the read, and bind specific buckets or tables.

Bash, a shell, or a direct SDK can skip MCP. Principle 3 then does not apply. Least privilege and guardrails still do. The post prefers MCP where you can, because that is where the agent-versus-human conditions appear.

Main components and trust boundaries

Principle 1: any granted permission can be used. VPC endpoint policies, resource control policies, resource policies, and SCPs are a second fence. The post does not say they replace the role. Principle 2 cuts that ceiling. If you own the code, the role is the maximum and a session policy is the intersection. It never adds rights. The sample attaches ReadOnlyAccess for one hour. On AgentCore the execution role is the trust anchor. Customer-data tools should assume a scoped role instead of using it directly. The same pattern is described for EC2 and EKS. A Strands agent can open one MCP client per credential set.

If you only edit mcp.json, choose an agent role narrower than the human role before the process starts, and put a permission boundary on that role. A boundary on the everyday human role would constrain the human too. For managed MCP, principle 3 can limit only the MCP path. Tagging Usage=Agent and a quarterly review are the post's guidance, not a quota.

Principle 3 marks the actor. The AWS, EKS, and ECS managed MCP servers set aws:ViaAWSMCPService and aws:CalledViaAWSMCP (sample names aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, ecs-mcp.amazonaws.com). The post says callers cannot spoof them. Its sample allows S3 reads and denies object and bucket deletes only when the boolean is true. Another allows eks:* only via the EKS server. Self-managed servers add no keys. You tag AssumeRole, for example AccessType=AI, and match aws:PrincipalTag. Policy shrinks the session. Tags only label it. Your code sets the tags, so a modified server can lie. Managed keys are injected by AWS.

Request or data path, step by step

Config-bound: mcp.json selects a profile. The post sets AWS_PROFILE for a self-managed server, or mcp-proxy-for-aws --profile for managed AWS MCP. Boundaries must already be on that role. Code-controlled: start as the execution role, AssumeRole with a session policy and, for self-managed MCP, tags, then call AWS with the temporary credentials. Managed servers add context keys for you.

CloudTrail records the MCP service in invokedBy, sourceIPAddress, and userAgent on managed downstream calls. Those are data events, so the trail must log them. Self-managed tags show on the AssumeRole event. A bash aws s3 rm or a direct SDK call skips MCP, the key is absent, and the MCP deny misses. Missing s3:DeleteObject on the role stops both paths.

The diagram: labeled boxes and failure or isolation edges

• Boxes: human or IdP, local profile or execution role, agent runtime, temporary session, MCP client, MCP server, AWS API, CloudTrail beside the API.
• Session policy intersects the role and cannot widen it. AgentCore's execution role is not per tool until AssumeRole.
• Managed MCP: context keys on the downstream call. A delete deny applies only when aws:ViaAWSMCPService is true.
• Self-managed: session tags. Dashed edge: the caller sets them.
• Bash or SDK skips MCP. Keys do not appear. The role policy still binds.

What the source does not claim (preview, case study, or limits)

The 14 April 2026 article is best-practice guidance, not a preview, a beta, or a case study. It has no measured speed and no error rate. It tells you to verify that a service actually evaluates MCP context keys inside a resource control policy. Third-party agent platforms are named and then set aside. Sample role names are examples. The stateless post's session-cache price is not an IAM metric, and the two posts do not disagree on a shared number.

How this differs from a nearby pattern on ByteDiagram

The stateless MCP diagram is the 28 July 2026 drop of initialize and Mcp-Session-Id. AgentCore Gateway, in that post, can handle protocol compatibility. Its checks are issuer, client type, human prompts, and schema, not aws:ViaAWSMCPService. The MCP gateway guide is the front door. This post is which principal the AWS call uses.

FAQ

Does an AgentCore execution role narrow each tool call by itself?

Not in the runtime configuration. The security post says that role applies to every operation and cannot be scoped down per invocation there. Narrower rights come from AssumeRole or AssumeRoleWithWebIdentity plus a session policy, which only intersects the role. The sample attaches ReadOnlyAccess for one hour. A Strands agent can open a separate MCP client per assumed credential set.

How can IAM tell an MCP agent call from a human call?

Managed servers, the AWS, EKS, and ECS MCP servers, add aws:ViaAWSMCPService and aws:CalledViaAWSMCP. The post says callers cannot spoof them. A sample deny of S3 deletes applies only when the boolean is true. Self-managed servers do not add the keys. You tag AssumeRole and match aws:PrincipalTag. The caller sets the tags, so you must trust that code.

Does a deny on aws:ViaAWSMCPService block every path the agent has?

No. The post says Kiro and Claude Code can use bash, a shell, or code execution and call the AWS CLI or a direct SDK. That skips MCP, the key is absent, and the deny does not match. The role's own least privilege, permission boundaries, and SCPs still apply. Removing those general-purpose tools is outside IAM.

Conclusion

The execution role or local profile is a ceiling. A session policy cuts it. Managed MCP can be denied apart from human calls. Self-managed MCP needs tags you trust. A shell that skips MCP never sees the keys. Cite the security post and, for protocol shape only, the stateless MCP post. More diagrams are on the ByteDiagram blog.