When a nightly build runs an AI‑driven code‑generation job, it needs to push a new container image into a Kubernetes cluster and then execute a health‑check pod. Because the process runs without a person, it requires a non-human identity to be granted access. Using a non-human identity ensures the AI agent is treated as a distinct service principal, separate from any human user.
In many organizations, the token used for such jobs is shared across dozens of pipelines, never rotated, and never tied to a specific execution. The AI agent can reach the EKS control plane, create or delete resources, and there is no record of which pipeline triggered which command. If a rogue model generates a destructive delete request using kubectl, the damage is done before anyone notices.
Why non-human identity alone isn’t enough
Assigning a dedicated IAM role to an AI process is a step forward. The role isolates the credentials from human users and can be scoped to the cluster’s RBAC groups. This is the essence of non-human identity: the agent presents a machine‑specific identity that the cloud provider can audit.
However, the identity check happens at the authentication layer only. Once the role is accepted, the request flows directly to the Kubernetes API server. There is still no guarantee that the command is safe, no live inspection of the payload, and no immutable log that captures the exact sequence of API calls. In short, the data path lacks a guardrail.
hoop.dev as the enforcement layer
Enter hoop.dev. The gateway sits between the AI agent and the EKS cluster, acting as a Layer 7 proxy for the Kubernetes protocol. The agent authenticates to hoop.dev with an OIDC token that represents its non‑human identity. hoop.dev then assumes the IAM role configured on the EKS connection and forwards the request to the cluster.
Because the gateway is in the data path, hoop.dev can enforce policies on every API call. It can:
- Record each kubectl or exec session, storing a replay‑able audit trail.
- Mask sensitive fields in API responses, such as secret data in ConfigMaps.
- Require human approval for high‑risk operations, like deleting a namespace.
- Block commands that match a deny list before they reach the cluster.
- Scope the assumed IAM role to the exact RBAC permissions needed for that request, granting just‑in‑time access.
All of these enforcement outcomes are possible only because hoop.dev is the only point where traffic can be inspected and altered. The non‑human identity of the AI agent tells hoop.dev who is asking, but hoop.dev decides what the request may do and records what actually happened.