The organization gives a newly hired AI‑assisted code reviewer a copy of the kubeconfig file so it can push lint fixes directly to the production cluster. The file contains a long‑lived token that grants cluster‑admin rights, and no one ever checks what commands the agent runs. Because the credential lives on the client side, the platform never sees which kubectl commands the client executes, which resources the client queries, or whether a command leaks secrets. Without a control point, the team lacks session recording for this activity.
In many teams, the default workflow for EKS looks exactly like that: teams bake a static credential into CI pipelines or hand it to contractors, and they reuse the same privileged identity across dozens of clusters. Because the credential lives on the client side, the platform never sees which kubectl commands the client executes, which resources the client queries, or whether a command leaks secrets.
Moving to a non‑human identity model, such as issuing short‑lived IAM roles that map to Kubernetes RBAC, solves the credential‑sprawl problem. The role can be scoped to a specific namespace or set of resources, and it can be granted only when an engineer or an automated agent requests access. However, without a control point that sits on the traffic path, the request still travels straight to the EKS API server. The platform still lacks a place to enforce approvals, mask sensitive fields, or capture a reliable audit trail.
Why a gateway is required for session recording
Placing a Layer 7 gateway between the identity provider and the EKS control plane creates a single enforcement surface. The gateway inspects every Kubernetes API call, applies policy, and can record the full request‑response exchange. That is where session recording becomes possible. The gateway does not replace Kubernetes RBAC; it complements it by adding runtime visibility and guardrails that the cluster itself cannot provide.
When an AI coding agent initiates a connection, it authenticates to the gateway using an OIDC token issued by the organization’s identity provider. The gateway validates the token, extracts group membership, and then uses the pre‑configured IAM role for that connection. The agent’s runtime never sees the underlying AWS credentials; the gateway assumes the role on its behalf and translates the identity into a Kubernetes ClusterRoleBinding that limits the session to the exact namespace required for the code review task.
Because the gateway sits in the data path, every kubectl command, every exec session, and every API response passes through it. hoop.dev records each interaction, timestamps it, and stores the logs in a secure audit store. Those logs become the definitive evidence of what the AI agent did inside the cluster, enabling replay, forensic analysis, and compliance reporting.
Architectural flow for AI coding agents on EKS
The flow follows four logical steps:
- Identity verification – the AI agent presents an OIDC token to the gateway.
- Role assumption – the gateway’s agent assumes the dedicated IAM role configured for the EKS connection.
- RBAC mapping – the assumed role maps to a Kubernetes ClusterRoleBinding that grants only the permissions needed for the review job.
- Session recording – the gateway captures every API call and response before it reaches the EKS API server.
This design ensures that the AI agent never holds long‑lived credentials, that access is granted just‑in‑time, and that hoop.dev provides a complete session recording for every interaction.
Benefits of session recording for AI agents
- Forensic replay: If a change later causes an outage, the exact command sequence can be replayed to understand cause and impact.
- Compliance evidence: Auditors receive immutable logs that show who accessed which namespace, when, and what operations were performed.
- Risk mitigation: Unexpected or dangerous commands can be flagged in real time, and the session can be terminated before damage occurs.
- Transparency for AI: Teams can verify that automated agents behave as intended, building trust in AI‑driven workflows.
hoop.dev makes all of these outcomes possible only because it sits in the data path. The underlying IAM role and Kubernetes RBAC provide the “who can do what” decision, but hoop.dev provides the “what actually happened” record.
Getting started with hoop.dev for EKS
hoop.dev provides an open‑source gateway that you can deploy with Docker Compose or a Kubernetes manifest. The official getting‑started guide walks through deploying the gateway, configuring the EKS IAM role, and linking the role to a Kubernetes ClusterRoleBinding. You can find detailed feature documentation, including how session recording is stored and accessed, in the learn section.
Because the solution is open source, you can inspect the code, contribute improvements, or host the gateway behind your own network perimeter. The repository contains all the manifests and example policies you need to tailor the deployment to your security requirements.
FAQ
- Do I need to change my existing Kubernetes RBAC? No. hoop.dev works with the RBAC policies you already have; it only adds a mapping layer that ties the assumed IAM role to a specific binding for the session.
- Can I disable recording for low‑risk namespaces? Yes. The gateway’s policy engine lets you enable or disable session recording on a per‑connection or per‑namespace basis, giving you fine‑grained control.
- How long are the logs retained? Retention is configurable in the gateway’s storage settings. Choose a period that satisfies your compliance window, and hoop.dev will automatically prune older entries.
Implementing a Layer 7 gateway in front of EKS gives you the missing audit layer that turns opaque API calls into a searchable, replayable record. That record is the cornerstone of secure AI‑assisted workflows.
Explore the open‑source implementation on GitHub: github.com/hoophq/hoop.
