Amazon EKS MCP Server: SigV4, CloudTrail and Write-Mode Risks

The question I wanted answered was simple: if I point an AI assistant at a production EKS cluster, what stops it from creating a VPC, deleting a stack or granting itself IAM permissions? The marketing phrase is write mode, and I expected a toggle in the console. There is no such toggle, and finding out what actually plays that role took a close read of five AWS pages.

This post is a documentation read, not a benchmark. I read the EKS user guide pages for the MCP server, the AWS managed policy reference, the launch blog and the mcp-proxy-for-aws README, and I did not run the server against a cluster. Every flag, permission name and default below comes from those pages, and where the pages disagree with each other I say so.

What the server is, and what preview means here

The Amazon EKS MCP server is described as a fully managed service, hosted in the AWS cloud, with no local installation to maintain. AWS announced managed MCP servers for EKS and ECS in preview on 21 November 2025, and the EKS pages I read in October 2026 still carry the note that the server is in preview release and is subject to change. The IAM managed policy for its read-only tools was introduced the same day.

Preview matters for an operations tool because the contract is allowed to move. The docs promise that new tools and fixes arrive automatically, which is convenient and also means the tool list you reviewed last month may not be the one your agent sees today. The launch blog lists availability in all AWS Commercial regions, excluding US GovCloud and China regions, and I found no pricing statement on the announcement page.

The request path: a local proxy that signs with SigV4

Your assistant does not talk to AWS directly. It launches mcp-proxy-for-aws as a stdio server, and that proxy, in the words of the getting started guide, acts as a client-side bridge handling AWS SigV4 authentication with your local AWS credentials. The hosted endpoint has the shape https://eks-mcp.REGION.api.aws/mcp, and the signing service name is eks-mcp. Because the identity is an ordinary IAM principal, everything you already know about roles, session policies and permission boundaries applies.

The launch blog adds a detail that is easy to miss: the region in the endpoint URL is where the server is hosted, while the proxy's --region argument scopes which EKS clusters it works on. The configuration reference then contains two defaults that disagree, which is why the table below is worth reading before you copy an example.

Sixteen read tools, four write tools, one permission each

The tools reference splits the server into read-only tools and full access (write) tools. Read-only covers documentation search, the troubleshooting guide, describe and list calls for clusters, node groups, add-ons and access entries, EKS insights, VPC config, Kubernetes events and pod logs, CloudWatch logs and metrics, and a tool that reads the policies attached to an IAM role. The write side is manage_k8s_resource, apply_yaml, manage_eks_stacks and add_inline_policy. The table shows the ones that decide your risk.

Every connection also needs eks-mcp:InvokeMcp, which the docs describe as the permission for initialization and for retrieving the list of available tools. So a principal with InvokeMcp alone can connect and see tools but call none of them.

Write mode is two switches, and neither lives on the server

The docs talk about creating resources if write mode is enabled, but I found no server setting by that name. What the pages describe instead are two independent controls. IAM decides whether a signed call to a privileged tool is allowed: eks-mcp:CallPrivilegedTool is the permission for full access tools. Separately, the proxy's --read-only flag stops those tools being offered to the assistant at all. The managed policy AmazonEKSMCPReadOnlyAccess includes the eks-mcp permissions for invoking MCP and calling read-only tools, and the getting started page lists it as the only managed option for read-only operations.

The four layers compose, but they do not fail the same way, so decide which one you are relying on.

For a production profile I would use layers one to three together. The config below follows the docs' own read-only production scenario with the exact flags they show. I replaced @latest with a version placeholder because the proxy README labels its CLI install as a pinned distribution, and an operations tool should not change under you between restarts.

Read-only production entry. Pin the proxy version you tested, and set the endpoint region and --region explicitly, because the docs state two different defaults.

{
  "mcpServers": {
    "eks-mcp-prod-readonly": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@<TESTED_VERSION>",
        "https://eks-mcp.us-west-2.api.aws/mcp",
        "--service", "eks-mcp",
        "--profile", "production",
        "--region", "us-west-2",
        "--read-only"
      ],
      "autoApprove": ["list_k8s_resources", "get_pod_logs", "get_k8s_events"]
    }
  }
}

The next block is the IAM side. It attaches the managed read-only policy to the role the proxy signs as, then adds an explicit deny on the privileged action, so the write tools stay unavailable even if someone later attaches a broader policy by mistake.

# Read-only role for the assistant: AWS managed policy for the read tools.
aws iam attach-role-policy \
  --role-name eks-mcp-readonly \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSMCPReadOnlyAccess

# Explicit deny on the privileged action. A deny beats every allow, so a broader
# policy attached later to this role cannot quietly re-enable the write tools.
aws iam put-role-policy \
  --role-name eks-mcp-readonly \
  --policy-name deny-eks-mcp-privileged \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "eks-mcp:CallPrivilegedTool",
      "Resource": "*"
    }]
  }'

What CloudTrail gives you, and what it does not say

The introduction page says CloudTrail integration captures initialization and full access tool calls made through the hosted service, for audit trails and compliance reporting. Read that sentence literally: it names initialization and full access (privileged) calls. It does not say that every read-only call is recorded, and I could not find a page that publishes the event names or event source for these calls. So do not build an alert on a name you guessed.

What you can do without guessing is search by the principal. Every call is signed by an IAM identity you control, and CloudTrail records who that was. Give each agent its own role session name and you get one clean thread per agent.

# The docs do not publish the event names for these calls, so search by who
# signed them instead of guessing a name. The username is the role session
# name, which is why each agent should get its own.
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=agent-triage-01 \
  --max-results 20 \
  --query 'Events[].[EventTime,EventSource,EventName]' \
  --output table

That trail is evidence after the fact. It will tell you which role session ran manage_eks_stacks at what time, and it will not stop it. It also does not store the prompt that led to the call, so you still need your assistant's own transcript to explain why.

Where it bites: the trade-offs the pages state plainly

The most useful sentences in the documentation are the unflattering ones. The optional write policy is documented as including high-risk permissions, anything with Delete or an unrestricted IAM resource, because manage_eks_stacks needs them to set up and tear down cluster resources. In practice that policy lets the principal create IAM roles, attach policies and delete VPC components, so an assistant with it is an infrastructure administrator that takes instructions in English.

Three more constraints follow from the same pages. Write Kubernetes operations reach only public clusters, as of the docs, while read operations reach private and public ones. apply_yaml relies on the Kubernetes API for validation, so a manifest from an untrusted source is applied as written. And the server redacts common secret patterns, replacing them with HIDDEN_FOR_SECURITY_REASONS, but the docs also tell you not to pass secrets through prompts, YAML or Kubernetes Secrets created via MCP, so redaction is a backstop rather than a promise.

What to do on Monday

Start with a role that can only look, prove it, and only then decide whether anything deserves write access. None of these steps needs the server to be anything more than preview.

1. Create a role for the assistant and attach AmazonEKSMCPReadOnlyAccess, then add an explicit deny on eks-mcp:CallPrivilegedTool.
2. Prove the policy with simulate-principal-policy before any agent connects, and keep the output with your change record.
3. Configure the proxy with --service, --region, --profile and --read-only, all explicit, and with a pinned proxy version.
4. Give each assistant its own role session name so CloudTrail can be searched by principal, then run a real question and find your own call in the trail.
5. Decide in writing which environments, if any, get a write role, and who can assume it. Keep add_inline_policy out of reach for everyone.

# Step 2: prove the role can invoke and read, and cannot call privileged tools.
# Expect "allowed" for the first two actions and "explicitDeny" for the third.
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/eks-mcp-readonly \
  --action-names eks-mcp:InvokeMcp eks-mcp:CallReadOnlyTool eks-mcp:CallPrivilegedTool \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output table

If step four finds nothing for a read-only question, that is consistent with the docs, which name only initialization and full access calls. Write that down as a known gap rather than assuming the trail is complete.

My rule after reading the pages: a managed MCP server moves the operating burden to AWS but moves no decision about authority. Authority is still IAM, enforced by an explicit deny, and the --read-only flag is a convenience on top of it. Treat the audit trail as the record of what you allowed, not as the thing that allowed it.