Configuring AI coding agents access to EKS with just-in-time access

Just-in-time access is essential when an AI coding agent is given a permanent Kubernetes credential, because the cost is invisible until a breach occurs. A single compromised token can let the agent enumerate pods, pull secrets, or launch containers that run arbitrary code across the whole cluster. The resulting lateral movement, data exfiltration, and compliance gaps can cripple a product team and erode customer trust.

Most organizations already use OIDC‑backed identities for engineers and have begun to experiment with AI‑driven assistants. The identity system can tell who is asking for access, and a request can be scoped to a short‑lived session. Yet the request still travels directly to the EKS API server, bypassing any enforcement point. No command‑level audit, no inline masking of sensitive fields, and no real‑time approval workflow exist once the connection is made. The result is a blind spot: the cluster sees a valid client, but the organization cannot verify what the client does.

Why just-in-time access matters for AI agents

AI agents are powerful because they can generate and execute code at speed. That speed is a double‑edged sword. If an agent mistakenly issues a kubectl exec into a privileged pod, it can read environment variables that contain database passwords or API keys. If it runs a kubectl delete on a namespace, it can erase weeks of work in seconds. Just-in-time access limits the window during which those privileges are usable, but it must be coupled with real‑time controls that watch each command before it reaches the cluster.

Without a guardrail, the organization loses visibility into which AI‑generated commands actually ran, cannot prove that a secret was never exposed, and cannot enforce a policy that requires human sign‑off for high‑risk operations. Those gaps directly conflict with audit requirements and increase the risk of accidental or malicious damage.

How hoop.dev enforces just-in-time access for EKS

hoop.dev sits in the data path between the AI agent and the EKS control plane. The gateway validates the OIDC token presented by the agent, extracts the user’s group membership, and then decides whether the request may proceed. The agent itself never sees the underlying AWS credentials; instead, hoop.dev’s runtime agent assumes a dedicated IAM role that is configured on the EKS connection. That role maps to a Kubernetes RBAC binding, so the session inherits the exact permissions needed for the requested task.

When the AI agent initiates a kubectl command, hoop.dev intercepts the request at the protocol layer. If the command matches a policy that requires approval, such as creating a Deployment in a production namespace, hoop.dev pauses the request and routes it to a human approver. Once approved, the command continues to the cluster. If the command is deemed unsafe, hoop.dev blocks it outright, preventing the action before any impact occurs.

Every response that contains potentially sensitive data, like secret values returned from a kubectl get secret call, is masked by hoop.dev in real time. The masking policy can be tuned to hide fields that match patterns for passwords, tokens, or private keys, ensuring that downstream logs or AI‑generated output never expose raw secrets.

In addition to approval and masking, hoop.dev records the entire session. It captures each command, its arguments, and the resulting output, storing the audit trail outside the cluster. The recorded session can be replayed for forensic analysis, compliance reporting, or debugging AI behavior. Because hoop.dev is the only point that can apply these controls, removing it would eliminate all of the described enforcement outcomes.

To adopt this model, start by deploying hoop.dev’s gateway using the standard Docker Compose quick‑start or a Kubernetes deployment. Connect your OIDC provider, register the EKS cluster as a connection, and configure the IAM role that the gateway agent will assume. Detailed steps are available in the getting‑started guide, and the broader feature set is described in the learn section. The repository contains the full source code and example manifests for a production‑grade deployment.

FAQ

• Do I need to change my existing CI/CD pipelines? No. hoop.dev presents a standard Kubernetes endpoint, so existing kubectl invocations continue to work once the gateway address is used.
• Can I limit just‑in‑time access to specific namespaces? Yes. The RBAC binding created by the assumed IAM role can be scoped to the exact namespaces required for the AI task.
• How are approvals handled for AI‑generated commands? hoop.dev forwards approval requests to any configured workflow, email, Slack, or an internal ticketing system, allowing a human to approve or reject the operation before it reaches the cluster.

Ready to see the code in action? Explore the open‑source repository and contribute at https://github.com/hoophq/hoop.