Non-human identity for AI agents on EKS

When an engineer leaves, you offboard them: disable the account, revoke the keys, done. When an AI agent is retired, what happens to its access? If the agent carried an embedded kubeconfig or a shared IAM key, the honest answer is usually "nothing, until someone remembers." That orphaned credential is the failure mode non-human identity is meant to prevent. Treating an agent as a first-class identity with a lifecycle is the only way its EKS access has an owner, a scope, and an off switch.

Non-human identity for AI agents on EKS is about lifecycle: how an agent's access is created, scoped, audited, and revoked, the same way a human's would be. The framing matters because it changes what you build.

An agent is an identity, not a credential

The common mistake is to think of an agent's access as a secret to distribute. Distribute a secret and you have created something with no owner that lives wherever it was copied, in a deployment manifest, a CI variable, a teammate's laptop. Think of the agent as an identity instead and the access becomes a grant you issue, scope, and remove from one place. The credential that reaches the cluster never has to live on the agent at all, which is the entire shift.

How hoop.dev models the non-human identity

hoop.dev is an open-source Layer 7 access gateway. Each AI agent registers as its own non-human identity in the gateway. When the agent needs the cluster, it authenticates to hoop.dev as that identity; hoop.dev applies policy and then reaches EKS through its kubernetes-eks connector. The network-resident agent assumes a configured IAM role, the EKS_ROLE_ARN, that maps to Kubernetes RBAC. The cluster credential is the connection's, never the agent's.

The lifecycle, step by step

1. Create. Register the agent as a distinct non-human identity. It now exists as a named principal you can reason about.
2. Scope. Grant it the EKS connection mapped to the narrowest RBAC role its job needs.
3. Operate. The agent works through the gateway; every command is attributed to its identity and recorded.
4. Review. Audit the agent's sessions by identity, the same query you would run for a person.
5. Revoke. Retire the agent by removing its grant. No credential to hunt down, because none was ever embedded.

identity: agent-reporting (non-human)
grants:   prod-eks (binding_user_role: eks-readonly)
status:   active -> revoked  # one action, no orphaned key

The revoke step is where this model earns its keep. With an embedded credential, offboarding an agent means finding every place the secret was copied and rotating it, and hoping you found them all. With a named identity, you remove the grant and the agent is done, because the cluster credential never left the connection.

The create step quietly matters just as much. Because the agent is registered as a principal before it ever touches the cluster, you have a place to attach everything else a serious deployment needs: which RBAC role it maps to, what window its access lives in, who approves its risky commands, and where its sessions are recorded. None of that is possible when "the agent's access" is just a secret in a manifest with no identity behind it. Giving the agent a name first is what makes every later control have something concrete to govern.

Pitfalls

• Do not reuse one identity across several agents. Shared identity defeats scoping and attribution at the same time.
• Do not embed an IAM key on the agent as a shortcut. That recreates the orphaned-credential problem you are solving.
• Do not leave retired agents' grants in place. Revocation is the part everyone skips and the part that matters most.

The model this builds to

A credential copied onto an agent has no lifecycle and no owner. A non-human identity has both. hoop.dev treats agents as identities you create, scope, and revoke, with the cluster credential kept at the boundary. Read the getting started guide for setup and see how scoped identity ties into audit and approvals.

FAQ

What makes an agent a non-human identity here? It registers as a named principal in the gateway and authenticates as itself, separate from the credential that reaches EKS.

How do I offboard an agent? Remove its grant at the gateway. Since no cluster credential lived on the agent, there is nothing to leak after revocation.

Can humans and agents share the model? Yes. Both are identities the gateway authenticates, authorizes, and records the same way.

hoop.dev is open source. Clone it at github.com/hoophq/hoop and give every agent a non-human identity you can revoke in one move.