Least-privilege access for AI agents on EKS

Cluster-admin is the default that quietly wins. An engineer grants an AI agent cluster-admin to get it unstuck during setup, the agent starts working, and nobody walks the permission back. Now an agent that only ever needs to read logs in one namespace can delete any resource in the cluster. Least-privilege access is the discipline of refusing that default. For AI agents on EKS it means the agent's reach is mapped to exactly its job and no further.

Least-privilege access for AI agents on EKS is a blast-radius problem. The smaller the grant, the less an error or a compromise can do, and an agent acting at machine speed makes both an error and a compromise more likely to matter.

Two layers have to agree

EKS access runs through two permission layers: AWS IAM and Kubernetes RBAC. An agent reaching the cluster is governed by the IAM identity used to authenticate and by the RBAC role that identity maps to. Least-privilege access means both layers are narrow and they agree. A tight IAM role mapped to a broad RBAC role still gives the agent the broad role's power, and a tight RBAC role behind an over-broad IAM identity leaves room for trouble elsewhere. The effective permission is the looser of the two, so both have to be deliberate.

How hoop.dev keeps the least-privilege access grant narrow

hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector proxies kubectl and exec to the cluster through a network-resident agent that assumes a configured IAM role, the EKS_ROLE_ARN, as its service identity. You set that role's BINDING_USER_ROLE to a specific Kubernetes RBAC role, so the connection can do only what that RBAC role permits. The AI agent reaches the cluster only through this connection, so its ceiling is the RBAC role you chose, not whatever the agent might otherwise hold.

Scoping steps

1. Define a Kubernetes RBAC role with the minimal verbs and resources the agent needs, for example get and list on pods and logs in one namespace.
2. Create an IAM role for the connection and map it to that RBAC role through aws-auth and the binding user role.
3. Configure the EKS connection in hoop.dev with the cluster URL, region, cluster name, and the role ARN.
4. Grant the agent only this connection, not a broader one.
5. Verify with kubectl auth can-i delete pods through the gateway and confirm it returns no.

# RBAC role the connection maps to
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]   # no delete, no exec, one namespace

The can-i check is the proof. If the agent cannot delete a pod through the gateway, the narrow RBAC role is doing its job, and no amount of clever prompting or compromised logic gives the agent a verb the role does not grant.

Pitfalls

• Do not grant cluster-admin "temporarily." Temporary grants are the most permanent kind.
• Do not narrow IAM while leaving RBAC wide, or the reverse. The effective permission is the looser of the two.
• Do not give one agent a connection scoped for a different agent's job. One connection, one scope, one agent.

Why this is the stronger answer

One approach gives the agent broad access and trusts it not to misuse the parts it does not need. The other maps the agent to a narrow RBAC role and makes the rest unreachable. least-privilege access is the second, and hoop.dev enforces it by routing the agent through a connection whose ceiling you set. See the getting started guide and read more on scoping access to infrastructure.

FAQ

Which layer enforces least-privilege access? Both. The connection's IAM role maps to a Kubernetes RBAC role; the agent's ceiling is that RBAC role.

Can one agent have several scoped connections? Yes, but grant each only when needed. Separate connections keep blast radii separate.

Does the agent see the IAM role? No. The role lives on the connection and is assumed by the gateway agent.

hoop.dev is open source and MIT licensed. Pull it from github.com/hoophq/hoop and give every agent the narrowest EKS grant its job allows.