When an AI coding agent can run kubectl commands against an EKS cluster without just-in-time access, a single bug can expose the entire workload, leak secrets, and trigger costly outages.
In many teams the AI helper authenticates with a long‑lived IAM user or a Kubernetes service account that is bound to cluster‑admin privileges. The credential lives in a config file, is checked into source control, and is reused across dozens of pipelines. When the agent misbehaves, the cluster sees the request directly, no one can tell which job issued the command, and the damage spreads before anyone notices.
Just-in-time access promises that an AI agent only receives a short‑lived token right before it needs to run a specific kubectl command, and that the token expires immediately after. In practice, teams often add a JIT layer but still let the request flow straight to the EKS API. The gateway that grants the token does not see the command payload, no audit record is created, and sensitive fields such as secret environment variables travel unmasked.
Why just-in-time access matters for AI agents
AI‑driven code generation can produce a burst of cluster activity that would be harmless if each operation were visible and bounded. Without a control point, a single mis‑generated manifest can create privileged pods, expose database credentials, or delete critical namespaces. The cost of a breach or a mis‑configuration grows with the time it remains undetected, and the operational impact can ripple through dependent services.
Threat model without a gateway
When the AI agent talks directly to the Kubernetes API, the attacker who compromises the agent inherits the same privileges. There is no central point to enforce policy, no way to mask secrets in responses, and no replayable log that shows which manifest created a privileged pod. Lateral movement becomes trivial because the same static credential can be reused across clusters.
Placing hoop.dev in the data path
Enter hoop.dev, a layer‑7 gateway that sits between the identity provider and the EKS control plane. Identity is still handled by an OIDC or SAML provider – the token tells hoop.dev who is requesting access, and the provider’s groups drive the initial authorization decision. The gateway runs an agent inside the customer network that assumes a dedicated IAM role configured for EKS authentication. Because the agent holds the role, the original service‑account credential never touches the AI process.
The gateway is the only place where traffic to the Kubernetes API can be inspected. Every kubectl request, exec session, or port‑forward passes through this data path, giving a single enforcement surface.
Enforcement outcomes delivered by hoop.dev
hoop.dev records each command that the AI agent issues, creating a replayable audit trail. It can mask fields such as secret environment variables or TLS keys in pod specifications before they reach the cluster, preventing accidental exposure. For high‑risk operations – for example creating a ClusterRoleBinding or deleting a namespace – hoop.dev can pause the request and route it to a human approver. Once approved, the request proceeds; otherwise it is blocked. All of these controls happen at the gateway, ensuring that the AI never sees the underlying credential and that every action is traceable.
By centralising enforcement, teams reduce blast radius, gain evidence for post‑incident analysis, and satisfy audit requirements without scattering policies across multiple tools.
Policy definition and workflow
Administrators define a policy that ties a specific AI role to a set of allowed Kubernetes verbs and namespaces. The policy also declares which verbs trigger an approval workflow. When the AI presents a just-in-time token, hoop.dev evaluates the request against this policy before forwarding it. If the request matches an allowed verb, it is sent straight through; if it matches a protected verb, hoop.dev initiates a JIT approval step.
Masking rules are expressed as field‑level selectors on the API objects. For example, any "data" field inside a Secret can be replaced with a placeholder before the response is returned to the AI, ensuring that the AI never learns the raw secret value.
Operational benefits
- Fine‑grained visibility: every kubectl command is logged with the identity that issued it.
- Reduced credential sprawl: the AI never stores long‑lived keys.
- Dynamic risk mitigation: high‑impact actions require explicit human approval.
- Data protection: sensitive fields are masked in real time.
- Replayability: sessions can be replayed for debugging or compliance audits.
Getting started
To try this pattern, follow the getting‑started guide for deploying the gateway and configuring the EKS role. The learn section explains how to define masking rules, approval workflows, and session replay. The repository contains the Helm chart and Docker Compose files you need to run hoop.dev in your environment.
FAQ
How does just-in-time access work with AI coding agents?
The AI receives a short‑lived token from the identity provider. The token is presented to hoop.dev, which validates it, checks the requested operation against policies, and then forwards the request to EKS only for the approved window.
Does hoop.dev store any credentials?
No. The gateway’s agent assumes the configured IAM role for EKS. The credential lives inside the agent and is never exposed to the AI process or the user.
Can I replay a session to see what the AI did?
Yes. hoop.dev records each command and the full response stream, allowing you to replay the session for forensic analysis or training purposes.
Explore the source code and contribute on GitHub.
