Session recording for AI coding agents on Kubernetes

Session recording becomes essential when an AI coding agent drives kubectl commands without visibility, because a single stray kubectl delete can wipe a production namespace and the incident leaves no forensic trail. The cost is not only the lost workload but also the time spent investigating who issued the command, whether the change was intentional, and how to prevent recurrence.

Many teams hand the agent a static kubeconfig file that embeds a cluster‑admin token. The token is stored in a secret store, checked into CI pipelines, and shared across dozens of bots. Because the connection goes straight from the agent to the Kubernetes API server, there is no central point that can observe, record, or intervene in the request. The result is blind, standing access: every command executes unchecked, and no replay exists for post‑mortem analysis.

What organizations often need is a way to capture every interaction – a full session recording – while still allowing the AI agent to reach the cluster. The requirement fixes the lack of visibility, but the request still travels directly to the API server, meaning the cluster itself remains the only authority and no audit data is collected. Without an intervening control plane, the session cannot be logged, replayed, or reviewed.

hoop.dev provides the missing control plane. It sits in the data path between the AI agent and the Kubernetes API server, acting as an identity‑aware proxy that inspects each wire‑protocol message. Because hoop.dev is the only component that sees the traffic, it can record the entire session, store the log for later replay, and make the recording available on demand. The gateway captures every request and response, preserving command arguments, timestamps, and the resulting API objects.

In practice, the AI agent authenticates to hoop.dev using an OIDC token issued by the organization’s identity provider. hoop.dev validates the token, extracts group membership, and applies just‑in‑time policies that determine whether the agent may proceed. Once authorized, the request is forwarded to the Kubernetes API server through a network‑resident agent that holds the cluster credential. The forwarder never exposes the credential to the AI agent, and hoop.dev remains the sole point where the session is observed.

Because hoop.dev is the active subject of the enforcement, it guarantees that session recording occurs for every connection. If the gateway were removed, the AI agent would again talk directly to the API server and no recording would happen. This makes hoop.dev the essential component for achieving audit‑ready, replayable sessions.

The recorded sessions are stored in a backend that can be queried later. Security teams can replay a session to see exactly which resources were created, modified, or deleted, and developers can use the replay to debug unexpected cluster state. The logs also satisfy compliance requirements that demand evidence of who performed which action and when.

Deploying the solution starts with the gateway itself. The quick‑start uses Docker Compose to stand up hoop.dev locally, but production deployments use Kubernetes or AWS to place the gateway close to the target cluster. An agent runs inside the same network as the Kubernetes control plane, holding the cluster bearer token. From there, the gateway can forward traffic securely while maintaining full visibility.

Identity configuration follows the standard OIDC flow: the organization’s IdP (Okta, Azure AD, Google Workspace, etc.) issues a token, and hoop.dev validates it. The token’s groups drive policy decisions, such as limiting the AI agent to a specific namespace or restricting it to read‑only operations. Because the policy is enforced at the gateway, the AI agent cannot bypass the controls even if it tries to present a different credential.

Once the gateway is in place, the AI coding workflow changes minimally. The agent points its kubectl client at the hoop.dev endpoint instead of the raw API server URL. All other client behavior remains the same, so existing automation scripts continue to work. The only addition is the guarantee that every command is recorded and can be replayed on demand.

For teams that need to audit AI‑driven changes, this architecture delivers a single source of truth for session activity. It eliminates the blind spot created by direct credential sharing, reduces the blast radius of accidental or malicious commands, and provides a replayable audit trail that can be handed to auditors or used for internal forensics.

To get started, follow the getting started guide that walks through deploying the gateway, configuring the Kubernetes connection, and enabling session recording. The learn section contains deeper explanations of policy definition and replay tooling.

For the full source code, contribution guidelines, and issue tracker, visit the GitHub repository.

FAQ

Will session recording add latency to Kubernetes API calls?

Because hoop.dev records the request and response as they pass through, the added latency is limited to the processing time of the gateway, which is typically a few milliseconds. The impact is negligible compared to the network round‑trip to the API server.

Can I record sessions for only a subset of namespaces?

Yes. Policies defined in hoop.dev can scope recording to specific namespaces or resource types. The gateway will still forward all traffic, but it will only retain logs for the scoped resources, reducing storage overhead.

What happens if the AI agent loses its OIDC token mid‑session?

The gateway will terminate the connection and mark the session as incomplete. The partial recording remains available for analysis, showing exactly where the interruption occurred.