Two different problems. Running agents on EKS is about long-lived workers, GPUs, sandboxes for code they write, and tight egress. Letting an agent operate EKS, through the EKS MCP server or kubectl, is about read-only by default, separate roles for writes, and approvals. The setups that are safe enough to use.
Requests
Agent tasks are jobs, not requests: queue them so a long run never holds a connection.
Orchestration
Execution
Code an agent writes runs on nodes that hold nothing else.
Models
Karpenter or Auto Mode brings GPU nodes up only when work arrives.
Guardrails
Agents as workloads: queue in, isolated workers, narrow egress
Treat code an agent writes as untrusted. Run it in short-lived pods on a separate node pool, with no service account token, no cloud credentials, and network policies that allow only the egress the task needs.
Containers are not a security boundary, as AWS's own Pod Identity docs say; nodes are. Separate node pools for untrusted execution are the minimum.
GPU capacity is the expensive part. Scale GPU node pools to zero between jobs, and use split cost allocation data to see GPU spend per namespace.
Cap spend per tenant and per task in code: tokens, tool calls, wall-clock time.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
AWS publishes an open-source EKS MCP server that gives coding assistants tools to inspect and manage clusters: list and describe resources, read logs and events, generate and apply manifests, and run troubleshooting. Two flags define how much it can do, and both default to off: --allow-write for anything that changes the cluster, and --allow-sensitive-data-access for logs, events and Secrets.
Give the agent its own IAM role and its own access entry, with an access policy scoped to the namespaces it may touch. Never your admin credentials.
Separate roles for read and write, as the EKS MCP server's documentation recommends.
Route production writes through an approval: a pull request to the GitOps repository rather than kubectl apply.
Keep CloudTrail and the control plane audit log on; every agent action is attributable to its role.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
EKS for HIPAA in 2026: What the BAA Covers and What You Still Have to Configure
EKS, ECR, Fargate, EBS, EFS and GuardDuty are on AWS's HIPAA eligible services list, so you can run workloads with PHI on Kubernetes under a BAA. Eligibility is not compliance: encryption, access, isolation, audit logs and what lands in your logs are yours. A control-by-control checklist, with a diagram.
Read
EKS Network Policies With the VPC CNI: Default Deny, Admin Policies, and the Limits to Know
The VPC CNI enforces Kubernetes network policies natively, and from version 1.21 adds cluster-wide admin policies that namespace owners can't override. How the tiers are evaluated, a default-deny setup, and the limits: EC2 Linux nodes only, 24 port-protocol combinations per CIDR, and pods without an owner.
Read
As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.