An AI agent does not log in the way a person does. It holds a token, a kubeconfig, or an embedded credential, and it runs kubectl against your cluster whenever its loop decides to. When that credential is a long-lived secret baked into a deployment, you have created a non-human identity with standing access to EKS and no clear owner. That is the problem worth solving before you let an agent touch production.
Configuring AI agents access to EKS with non-human identity done right means the agent never holds cluster credentials at all. The identity it presents is verified at a gateway, the connection to the cluster runs under a separate service role, and every command is attributed back to the agent that issued it.
Why non-human identity breaks the usual model
Human access to EKS already has rough edges: shared kubeconfigs, IAM users that outlive the engineer, group bindings nobody audits. Agents make all of that worse because they act continuously and at machine speed. A leaked human token might get used a few times before someone notices. A leaked agent credential gets used thousands of times in an hour, and the agent never sleeps, so the exposure is constant rather than occasional.
So the requirement is not "give the agent a smaller token." The requirement is that the agent's identity and the credential that reaches the cluster are two different things, and the second one never leaves a controlled boundary. The moment those two collapse into one secret on the agent, you have standing access again under a new name.
Where the identity-aware proxy sits
hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector runs an agent inside your network that proxies kubectl and exec traffic to the cluster. The agent authenticates to the cluster by assuming a configured AWS IAM role, the EKS_ROLE_ARN, as hoop.dev's own service identity. That role maps to a Kubernetes RBAC role inside the cluster through the connection's binding user role.
The AI agent, meanwhile, authenticates to hoop.dev as itself. It calls the gateway, the gateway verifies the agent's identity, applies policy, and only then dispatches the command over the cluster connection. The agent never sees the IAM role or a kubeconfig. This is an identity-aware proxy in the literal sense: the proxy knows who is calling and decides what that caller may do before any traffic reaches EKS.
Configuration steps for non-human identity
- Stand up the gateway and run the network-resident agent near your EKS cluster so it can reach the API server over an outbound connection.
- Create a least-privilege IAM role for the connection and record its ARN. Map that role to a Kubernetes RBAC role through the aws-auth mapping and the connection's binding user role.
- Define the EKS connection with the cluster URL, region, cluster name, and the role ARN. This is the only place the cluster-reaching credential lives.
- Register the AI agent as a distinct identity in hoop.dev and grant it access to that connection. The agent now has a non-human identity that is named, scoped, and revocable.
- Verify by issuing a
kubectl get pods through the gateway and confirming the session shows the agent as the actor while the cluster sees the service role.
CLUSTER_URL=https://example-endpoint.eks.amazonaws.com
AWS_REGION=us-east-1
EKS_CLUSTER=prod-cluster
ROLE_ARN=arn:aws:iam::123456789012:role/eks-agent-access
BINDING_USER_ROLE=eks-readonly
Notice what is not in that configuration: anything the agent itself holds. The role ARN and the RBAC binding live on the connection, set by an operator, not handed to the agent. The agent's only credential is the one it uses to authenticate to the gateway, and that grants nothing on the cluster by itself.
Pitfalls to avoid
- Do not hand the agent its own IAM role "just for now." Temporary becomes permanent, and you are back to standing access with no owner.
- Do not over-scope the binding role. Map the connection to the narrowest RBAC role the agent's job needs, and revisit it when the job changes.
- Do not skip attribution. A non-human identity with no recorded session is indistinguishable from an attacker once something goes wrong.
One model leaves a credential inside the agent. The other keeps the credential at the boundary and lets the agent prove who it is on every call. The second is the one you want a non-human identity to run under.
Putting it together with hoop.dev
The architectural point is that the identity that reaches EKS must live outside the agent process, because the agent process is exactly the thing you cannot trust to hold a secret. hoop.dev is built to that requirement. Read the getting started guide for connection setup, and see how scoped identity and command-level audit fit together for the broader model.
FAQ
Does the AI agent ever hold cluster credentials? No. The credential that reaches EKS is the connection's IAM role, assumed by the gateway agent. The AI agent only authenticates to hoop.dev.
Is assume-role the right pattern for EKS here? Yes. EKS access through the gateway assumes a configured IAM role as the service identity, which maps to Kubernetes RBAC. This is specific to EKS, not a general AWS pattern.
How do I revoke an agent's access? Remove the non-human identity's grant on the connection at the gateway. The cluster credential never moves, so there is nothing leaked to rotate.
hoop.dev is open source and MIT licensed. Clone the repo at github.com/hoophq/hoop and wire your EKS connection to a non-human identity you can actually account for.
