Putting access controls around ChatGPT: session recording for AI coding agents (on Kubernetes)

Why session recording matters for AI coding agents

AI coding assistants such as ChatGPT can be embedded in CI pipelines, auto‑generate code, and issue commands directly against a Kubernetes cluster. When a model decides to apply a manifest, scale a deployment, or delete a namespace, the action is executed without a human eye on the request. If the model misinterprets a prompt or is tricked into running malicious code, the result can be a production outage, data loss, or a security breach. The lack of a reliable audit trail makes post‑mortem analysis almost impossible.

The missing piece in a direct Kubernetes connection

Teams often grant the AI agent a service‑account token that has the same RBAC permissions as a human operator. The token is mounted into the container, the agent talks straight to the Kubernetes API server, and the request is processed as if it came from a person. This setup satisfies the "who can act" question, but it provides no visibility into "what actually happened". No session logs are kept, no replay is possible, and any accidental or malicious command disappears into the API server’s internal audit stream, which is not tied back to the originating model.

Even when organizations enable Kubernetes audit logging, the logs are coarse‑grained and lack the context of the AI‑generated prompt that triggered the operation. The result is a gap: the request reaches the target directly, with no session recording, no replay, and no way to prove which model or which prompt caused the change.

Introducing hoop.dev as the enforceable data path

hoop.dev sits between the AI agent and the Kubernetes API server, acting as a Layer 7 gateway. It verifies the OIDC token presented by the agent, extracts group membership, and then proxies the request to the cluster. Because the gateway is the only point where traffic passes, hoop.dev can record each request and response, store a replayable session, and make that evidence available to auditors.

hoop.dev does not replace the service‑account token; it simply hides the credential from the agent. The agent never sees the Kubernetes credential; the gateway presents it on behalf of the request after the identity check. This separation ensures that the setup (identity verification) alone does not provide the enforcement outcome – the recording happens only because hoop.dev occupies the data path.

How session recording works in practice

When the AI model issues a kubectl command or calls the Kubernetes REST endpoint, the request enters hoop.dev. The gateway captures the full request payload, including the API verb, resource type, and namespace, then forwards it to the API server. The response – whether it is a success, an error, or a list of resources – is captured as well. Both sides of the exchange are stored as a single session record that can be replayed later, showing exactly what the model asked for and what the cluster returned.

Because the recording happens at the protocol level, hoop.dev can also mask sensitive fields in the response, such as secret data or token values, before they reach the AI agent. This inline masking protects downstream processes while still preserving a complete audit trail for human reviewers.

Session records are persisted for later review and can be queried through hoop.dev’s UI or API. Teams can search by model name, time window, or Kubernetes resource, and replay a session to see the exact command sequence that was executed. This capability satisfies compliance requirements that demand evidence of who performed which action, even when the actor is an autonomous AI system.

Common mistakes to avoid

1. Storing the service‑account token in the container. If the token is directly mounted, the AI agent can bypass hoop.dev and communicate with the API server on its own, eliminating the recording layer entirely. Always let hoop.dev be the sole holder of the credential.

2. Relying solely on Kubernetes audit logs. Native audit logs do not capture the originating prompt or the exact sequence of API calls made by the model. Without hoop.dev, you lose the contextual link between AI input and cluster output.

3. Disabling inline masking. Sensitive data returned from the cluster can be fed back to the model, creating a data‑exfiltration risk. Enabling masking at the gateway ensures that secrets never leave the controlled boundary.

4. Granting overly broad RBAC to the AI service‑account. Even with session recording, a token that can delete any namespace expands the blast radius of a mistake. Pair hoop.dev’s just‑in‑time approval workflow with the principle of least privilege.

Best practices for reliable recordings

Deploy hoop.dev in a highly available configuration so that the gateway itself never becomes a single point of failure. Use the official getting started guide to run the service in Docker Compose or Kubernetes, and enable persistent storage for the session archive.

Enable the approval workflow for any destructive operation (e.g., delete, scale‑to‑zero). This adds a human checkpoint before the gateway forwards the request, while still preserving a full session record of the approval decision.

Regularly review recorded sessions for anomalous patterns. Because hoop.dev captures every API call, you can build alerts that trigger on unusual command sequences, such as a sudden surge in "kubectl exec" requests.

Document the mapping between AI model versions and the permissions they receive. When a new model is promoted, update the group membership that hoop.dev uses for policy decisions, ensuring that recording and masking stay aligned with the model’s capabilities.

Getting started

Deploy the gateway using the official getting started guide. The quick‑start runs hoop.dev in Docker Compose, configures OIDC authentication, and connects an agent to your Kubernetes cluster. Once the gateway is running, register the Kubernetes API as a connection and enable session recording in the feature settings. Detailed configuration options and best‑practice recommendations are available in the feature documentation. For a deeper dive into the code and contribution process, Explore the open‑source repository.