The fastest way to ship an AI agent against a Kubernetes cluster is to hand it a kubeconfig with a broad service account and move on. It works in an afternoon. It also gives the agent a non-human identity that is shared, long-lived, and indistinguishable from every other automation using the same token. Six months later nobody can say which agent did what, and rotating the credential means coordinating with workloads you have lost track of.
The good news is that doing this correctly does not have to be the slow path. A real non-human identity for an agent can be lower friction than the shared-token shortcut, if the identity and the access live at the boundary instead of inside the agent.
What a non-human identity has to be
A non-human identity is the agent's own account: distinct, attributable, and governed separately from any human's. For an agent operating Kubernetes, that means the agent is not just another consumer of a shared cluster service account. It is an identity the access layer recognizes, so that authorization, audit, and revocation all key off the agent itself.
The shared kubeconfig fails this on every count. It is not distinct, so two agents look identical. It is not attributable, so the cluster audit log sees one actor. And it is not cleanly revocable, because killing the token kills everything that holds it.
Where the friction actually comes from
Engineers reach for the shared token because the alternative usually means provisioning per-agent credentials, distributing them, rotating them, and scrubbing them out of logs and environment variables. That is real work, and it is the work that makes teams give up and share one secret.
The friction disappears when the agent stops holding a cluster credential at all. If the agent connects through an access boundary that already knows its non-human identity, there is no kubeconfig to distribute, no token to rotate inside the agent, and no secret to leak. The identity is asserted at the boundary, and access to the cluster is brokered per task from there.
The low-friction model
This is the model hoop.dev is built to. The agent connects to the Kubernetes cluster through hoop.dev, a Layer 7 access gateway and identity-aware proxy that sits in front of the cluster's access path. The agent presents its non-human identity to the gateway, the gateway authorizes the specific command against that identity, and it brokers the connection to the cluster per task. The agent never stores a long-lived kubeconfig, because it is not the cluster principal. hoop.dev reaches the cluster; the agent reaches hoop.dev.
The developer experience that follows is the point. Onboarding an agent is granting its identity a scope, not minting and shipping a secret. Offboarding is removing the identity, and every connection it could open closes at once. Attribution is automatic, because each session is recorded against the identity, outside the agent. The getting-started docs for connecting a Kubernetes cluster walk through the setup, and the learn pages on the access model cover how identities map to scopes.
What it looks like in practice
A platform team runs four agents against the same cluster: one for cost cleanup, one for log triage, one for deploy rollbacks, one for read-only dashboards. Under shared tokens, those four are one actor with one giant scope. Under per-agent non-human identity at the boundary, each has its own identity and its own narrow scope. The cleanup agent can delete completed jobs and nothing else. The dashboard agent can only read. When the log-triage agent misbehaves, you revoke one identity and the other three keep running.
Pitfalls to skip
- One identity, many agents. The instant agents share an identity, attribution and revocation both break. One identity per agent is the whole point.
- Long-lived tokens in the agent. Any secret the agent stores can leak and outlives the task. Keep the cluster credential out of the agent and broker access at the boundary.
- Identity without scope. A distinct identity that still carries cluster-admin has solved attribution and nothing else. Pair the identity with a task-scoped grant.
FAQ
Isn't a Kubernetes service account already a non-human identity?
It is, but in practice agents share one service account, which collapses attribution and revocation. A per-agent non-human identity asserted at the access boundary keeps each agent distinct without shipping a kubeconfig into the agent.
Does this add latency to the agent's calls?
The agent makes one connection hop through the boundary, the same hop that removes the standing credential. In exchange you get per-task authorization and a recording tied to the identity.
hoop.dev is open source. To give each agent a real non-human identity in front of your Kubernetes cluster, start from the repository on GitHub.
