Many assume that an on‑prem Claude coding agent automatically logs every prompt and response, but the reality is that the model runs as a plain process with no built‑in audit trail.
Without a reliable record, teams lose visibility into who asked the model to generate code, what the model returned, and whether any secret data was inadvertently exposed. Session recording becomes the linchpin for forensic analysis, compliance reporting, and internal governance, especially when the LLM operates behind a corporate firewall.
In a typical on‑prem deployment, engineers start a Claude server, point their IDE or CLI at the local endpoint, and issue prompts directly. The connection is a raw TCP stream; no identity checks, no approval workflow, and no persistent log of the exchange. The server’s stdout may be captured, but that log is not tied to a user identity, cannot be replayed reliably, and is easily altered or deleted.
Organizations often begin to tighten the perimeter by assigning a service account or a machine‑identity token to the Claude process. That step limits which machines can start the server, but the request still travels straight to the model without passing through a control point that can observe or record the conversation. The underlying risk remains: a privileged user can invoke the model, retrieve code, and erase any trace.
hoop.dev inserts a Layer 7 gateway between the caller and the Claude server. The gateway acts as an identity‑aware proxy: it validates the caller’s OIDC token, enforces just‑in‑time access policies, and then forwards the request to the model. Because the gateway sits in the data path, it can capture the full request and response payload, store a session record, and make that record searchable for audit purposes.
Session recording for Claude on‑prem
The gateway runs a lightweight agent inside the same network segment as the Claude service. When a user or automated workflow invokes the model, the traffic is routed through the agent, which hands the data to the hoop.dev proxy. At that point the proxy writes a timestamped entry that includes the caller’s identity, the exact prompt, and the model’s output. The record is kept separate from the Claude process, ensuring that even if the model is compromised the audit trail remains intact.
Identity and just‑in‑time access
Access begins with an OIDC or SAML identity provider such as Okta or Azure AD. The user obtains a short‑lived token that hoop.dev validates. Policies can require that a request be approved by a human before the model runs, or that only certain groups may generate code that touches production repositories. Because the enforcement happens in the gateway, the Claude server never sees the token or the approval decision.
Replay and audit
Each recorded session is stored in a secure store that can be queried by compliance tools. Auditors can replay the exact exchange, see which identity initiated it, and verify that any sensitive data was masked according to policy. The replay capability also helps developers reproduce bugs that stem from generated code.
Optional inline masking
For environments where the model might return secrets, hoop.dev can mask configured fields before the response reaches the caller. The masking rule is applied in the same data path that records the session, so the original value is never exposed downstream.
By centralising these controls in a single gateway, organizations avoid stitching together disparate tools for identity, logging, and approval. The result is a coherent security posture that scales with the number of AI agents and developers.
To get started, follow the getting‑started guide which walks you through deploying the gateway, registering a Claude endpoint, and configuring OIDC authentication. The learn section provides deeper insight into policy definition, masking, and replay features.
FAQ
- Does hoop.dev require changes to my Claude code? No. The gateway works at the protocol level, so existing clients continue to use the same CLI or API calls.
- Can I disable recording for a specific workflow? Policies are fine‑grained; you can allow a request to pass without recording, but the default stance is to record every session.
- How long are session records retained? Retention is defined by your storage policy; hoop.dev simply writes the record, and you manage lifecycle according to corporate requirements.
Explore the open‑source repository on GitHub to view the code, contribute, or spin up your own instance.
