An internal AI coding assistant is wired into the CI pipeline, and every action it takes against a production EKS cluster is currently invisible to auditors. Because the assistant runs without session recording, a malicious prompt could cause the agent to delete a namespace or expose secrets without any replayable evidence.
The lack of visibility means security teams cannot reconstruct what happened, and compliance auditors have no proof that the AI‑driven change was reviewed. What teams really need is reliable session recording for these AI‑driven sessions. The ideal solution would capture every command, arguments, and response while still allowing the agent to talk directly to the Kubernetes control plane. In the current setup, the request still reaches the cluster unmediated, so there is no point at which the system can observe or store the interaction.
To address this, the architecture must insert a mandatory data‑path component between the AI agent and the Kubernetes API. This component validates the caller’s identity, maps it to an AWS IAM role, and then proxies the request. Because all traffic is forced through a single gateway, the component can record each request and response, write the data to a durable store, and make the session replayable for forensic analysis.
hoop.dev provides exactly that gateway. The gateway runs a lightweight agent inside the same network as the cluster and becomes the only conduit for API calls. When the AI coding agent initiates a kubectl command, the request is routed to the hoop.dev gateway instead of the EKS endpoint. The gateway validates the OIDC token, assumes the configured IAM role, and forwards the request to the cluster. Because the gateway is the sole conduit, it can apply session recording consistently for every command, regardless of who issued it.
Why the data path matters for session recording
The first line of defense is the identity setup. Engineers and service accounts obtain OIDC tokens from an identity provider; the token tells the system who is making the request. This setup step decides who may start a session, but it does not enforce any guardrails on its own. The actual enforcement must happen where the traffic is inspected.
hoop.dev sits in that exact spot. By sitting between the caller and the EKS control plane, it can observe every API call, log the payload, and store the result in a secure location. The recorded session can later be replayed in a sandboxed environment, allowing engineers to see exactly what the AI assistant did, step by step. This capability satisfies forensic requirements and gives security reviewers a clear picture of any unexpected changes.
How session recording works for EKS
When a request reaches hoop.dev, the gateway creates a session context identified by the AI agent’s user name and the target cluster. Every API call – whether it is a GET for pod information or a POST that creates a deployment – is logged with timestamps, request payloads, and the cluster’s response. The logs are written to a durable store outside the agent’s process, ensuring that even if the agent is compromised, the recorded evidence remains intact.
The recorded session can be replayed in a sandboxed environment, allowing engineers to see exactly what the AI assistant did, step by step. This capability satisfies forensic requirements and gives security reviewers a clear picture of any unexpected changes.
Deploying hoop.dev for AI‑driven EKS access
1. Deploy the gateway in the same VPC or subnet as the EKS cluster. The official quick‑start uses Docker Compose, but Kubernetes or AWS deployments are also supported.