Without immutable session logs, a misbehaving AI coding agent can rewrite production manifests and leave no trace for incident response.
Why session recording matters for AI agents on Kubernetes
Devin, an LLM‑driven coding assistant, often runs kubectl exec or applies manifests directly against a cluster. The convenience is real, but the risk is hidden: the agent’s internal state is volatile, and any mistake disappears as soon as the process ends. Teams need a reliable replay that shows exactly what was sent, when, and under which identity, because the agent’s own console output can be filtered or suppressed.
Common mistakes to avoid
- Assuming the AI’s console output provides sufficient evidence. The agent can hide or alter that output.
- Granting long‑lived credentials to the agent and never rotating them. This creates a standing access window that bypasses any review.
- Relying only on Kubernetes audit logs. Those logs record API requests but miss the raw command‑line interaction that led to the request.
- Storing recordings on the same host that runs the agent. If the host is compromised, the evidence disappears.
Each of these pitfalls stems from a missing control surface: there is no single point where traffic can be inspected, logged, and protected before it reaches the cluster.
Architectural requirements for reliable session recording
Three layers are essential. First, setup – identity providers such as Okta, Azure AD, or Google Workspace issue OIDC tokens that uniquely identify the caller. This step decides who is asking for access, but it does not enforce any policy on its own.
Second, the data path – a gateway that sits between the requester and the Kubernetes API server. Only at this point can a system see every byte that flows to the cluster, apply guardrails, and capture an immutable record.
Third, the enforcement outcomes – session recording, replay, and audit export. hoop.dev creates these outcomes because it sits in the data path; without that interception, nothing is recorded.
How hoop.dev provides the missing data‑path
hoop.dev implements a Layer 7 gateway that proxies Kubernetes exec and API traffic. It authenticates each request with the OIDC token supplied by the user or AI agent, extracts group membership, and then decides whether the request may proceed. The gateway holds the Kubernetes credentials, so the caller never sees them.
When a request is allowed, hoop.dev streams the traffic through its proxy and simultaneously writes a session record. The record captures the full command line, the response payloads, timestamps, and the identity that initiated the session. Because hoop.dev records inside the gateway, the AI agent or any compromised node inside the cluster cannot alter the evidence.
hoop.dev stores the recordings in a location that is separate from the Kubernetes control plane. Because the gateway writes the data after the traffic passes through, the agent cannot modify the stored session. Auditors can retrieve a replayable stream, replay it in a sandbox, or export it for compliance reporting. hoop.dev also supports just‑in‑time approvals, so a high‑risk operation pauses for human sign‑off before it ever reaches the cluster.
Getting started with hoop.dev for Devin
To put session recording around Devin, follow the high‑level steps below. Detailed instructions live in the getting‑started guide and the broader learn section.
- Deploy the hoop.dev gateway in a network zone that can reach your Kubernetes control plane. The quick‑start uses Docker Compose; production deployments can run on Kubernetes or in AWS.
- Configure an OIDC identity provider that issues tokens for both human engineers and AI service accounts. Assign the AI service account to a group that receives just‑in‑time access to the target cluster.
- Register the Kubernetes connection in hoop.dev, supplying the cluster endpoint and a service‑account token that the gateway will use. The token never leaves the gateway.
- Enable the session‑recording feature for that connection. hoop.dev then automatically captures every exec session and API call.
- Grant Devin the ability to request a session via the hoop.dev CLI or its API. hoop.dev evaluates the identity token, and if approved, records the session end‑to‑end.
Because hoop.dev is open source, you can inspect the code, run it in your own VPC, and integrate it with existing CI/CD pipelines. The repository is available at github.com/hoophq/hoop.
FAQ
What exactly does hoop.dev capture in a session recording?
hoop.dev records the raw request payload, the full response from the Kubernetes API, timestamps for each exchange, and the identity that initiated the session. The system stores the record in a format that can be replayed verbatim.
Who can access the stored recordings?
hoop.dev controls access to recordings with the same OIDC policies that govern session initiation. Only users with the appropriate group membership can retrieve or replay recordings.
Does session recording replace Kubernetes audit logs?
No. hoop.dev complements native Kubernetes audit logs by adding visibility at the command‑line level, which is especially valuable for AI agents that generate commands dynamically.
