All posts

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

Running Claude‑powered coding agents on Kubernetes without a guardrail leaves every prompt, every generated snippet, and every command trace exposed to anyone who can reach the pod. Without session recording, a compromised CI runner or a careless developer can execute arbitrary code, exfiltrate secrets, or rewrite source files, and there is no reliable evidence to reconstruct what happened. Organizations often launch Claude containers with a shared service account token, grant the pod cluster‑

Free White Paper

AI Session Recording + Kubernetes API Server Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Running Claude‑powered coding agents on Kubernetes without a guardrail leaves every prompt, every generated snippet, and every command trace exposed to anyone who can reach the pod.

Without session recording, a compromised CI runner or a careless developer can execute arbitrary code, exfiltrate secrets, or rewrite source files, and there is no reliable evidence to reconstruct what happened.

Organizations often launch Claude containers with a shared service account token, grant the pod cluster‑wide permissions, and rely on Kubernetes RBAC alone. The token is baked into the image or mounted as a secret, and the pod talks directly to the API server and the underlying file system. No audit log captures the exact sequence of prompts and responses, and any post‑mortem investigation must piece together fragmented container logs that may have been rotated or deleted.

This reality creates two gaps. First, the request from the AI agent reaches the target environment unchecked; the gateway that could inspect traffic is missing. Second, even if an audit log exists at the cluster level, it does not contain the fine‑grained interaction between Claude and the codebase, making compliance and forensics impossible.

Why session recording matters for AI coding agents

Claude can generate code that writes files, modifies configurations, or invokes downstream services. Each of those actions represents a potential security event. Session recording captures the full dialogue – the prompt, the model’s response, and the resulting commands – creating a complete record that can be reviewed, replayed, and analyzed for anomalies.

Beyond forensic value, recorded sessions support governance policies such as “no secret leakage” and “all code changes must be traceable to an authorized request.” When a regulator asks for evidence of who altered production code, the recorded session provides a concise, verifiable artifact.

Common pitfalls when you skip a gateway

  • Shared credentials are stored in plain text inside container images, making rotation difficult.
  • Cluster‑wide RBAC grants give the agent more privileges than needed, increasing blast radius.
  • Native Kubernetes audit logs do not capture the content of AI‑generated prompts, only API calls.
  • Without an inline guard, malicious output can be executed before anyone notices.

These issues persist even if you tighten IAM policies, because the enforcement point – the data path between the agent and the Kubernetes API – remains uncontrolled.

Continue reading? Get the full guide.

AI Session Recording + Kubernetes API Server Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

How hoop.dev provides session recording for Claude

hoop.dev sits in the Layer 7 data path as an identity‑aware proxy. When a Claude instance tries to connect to the Kubernetes API, the request is routed through hoop.dev instead of going directly to the cluster. hoop.dev authenticates the caller via OIDC, then inspects every protobuf or HTTP request that carries the prompt and the model’s reply.

During this inspection hoop.dev records each interaction and retains the transcript for later review. The recording happens regardless of the underlying Kubernetes RBAC settings, because hoop.dev is the only component that sees the traffic.

Because the gateway holds the service‑account credential, the Claude container never touches the token. This eliminates credential leakage and enables just‑in‑time issuance of short‑lived tokens, further reducing exposure.

Implementation overview

Deploy the hoop.dev gateway in the same network segment as your Kubernetes control plane. The gateway runs as a Docker container or a Kubernetes pod, and an agent runs on each node to forward traffic. Register a connection for the Kubernetes API, configure the gateway to use the cluster’s service‑account credential, and enable the session‑recording guardrail in the policy definition.

When Claude’s client connects, hoop.dev validates the OIDC token, forwards the request to the API server, and records the full request/response pair. The recorded session can be replayed in the hoop.dev UI or exported for downstream analysis.

For a step‑by‑step walkthrough, see the getting started guide. For deeper details on guardrails, see the feature guide. Both pages explain how to configure the policy that turns on session recording for specific AI workloads.

FAQ

Does session recording add latency?

hoop.dev records at the protocol layer, adding only a few milliseconds of overhead. The impact is negligible compared with the time Claude spends generating a response.

Can I disable recording for low‑risk workloads?

Yes. Policies are scoped by identity, namespace, or label, so you can enable recording only for privileged agents while allowing others to operate without it.

Where are the recordings stored?

Recordings are retained by hoop.dev and can be accessed through its audit UI or exported as needed.

Explore the source code on GitHub to see how the session‑recording guardrail is implemented and contribute enhancements.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts