An AI coding agent that automatically generates Kubernetes manifests and pushes them to a production EKS cluster can speed up delivery, but it also creates a blind spot. The agent typically runs with a long‑lived service account that has broad RBAC permissions. When a new change is produced, the agent applies it directly, bypassing any human review. If the generated manifest contains a misconfiguration, a secret leak, or an unintended workload, the damage is immediate and hard to trace.
Teams recognize that an approval workflow is essential: before any manifest reaches the cluster, a responsible engineer should examine the change and explicitly grant permission. However, simply adding a review step in a CI pipeline does not solve the core problem. The request still travels straight to the EKS API server, the agent retains its credentials, and the cluster sees no record of who approved what. Without a control point on the data path, the system cannot enforce the approval, cannot mask sensitive fields in responses, and cannot produce a reliable audit trail.
Implementing approval workflows for AI agents on EKS
To close the gap, the enforcement point must sit between the AI agent and the Kubernetes control plane. This is where a Layer 7 gateway becomes the decisive boundary. The gateway receives the agent’s request, checks the policy, and only forwards the request after the required approval is recorded. Because the gateway owns the connection, it can also mask secret values returned by the API and record every kubectl command for replay.
Setup: defining who can request access
The first layer is identity. The AI agent authenticates to the gateway using an OIDC token issued by the organization’s identity provider. The token conveys the agent’s service account identity and any group memberships that determine whether the request is eligible for a Just‑In‑Time (JIT) approval. This step decides who is making the request, but it does not enforce any policy on its own.
The data path: the gateway as the only enforcement point
Once the token is validated, the request enters the gateway’s data path. Here, hoop.dev inspects the Kubernetes API call at the protocol level. Before the call reaches the EKS endpoint, the gateway checks whether an approval record exists for the specific manifest hash. If no approval is found, the gateway blocks the operation and returns a clear “approval required” response to the agent.
hoop.dev also applies inline masking to any fields that contain credentials or tokens, ensuring that downstream services never receive raw secrets. Because the gateway holds the cluster credentials, the AI agent never sees them, satisfying the “agent never sees the credential” principle.