When an AI coding assistant like Claude writes code inside a CI/CD pipeline, the lack of a reliable audit trail can hide bugs, license violations, or even malicious payloads. Without session recording, a compromised model or a careless prompt can inject vulnerable code that later surfaces in production, exposing the organization to costly remediation, regulatory penalties, and brand damage.
Teams often grant Claude a static API key, embed it in build scripts, and let the model run unchecked. The generated snippets flow directly to the repository, and the pipeline logs capture only the final artifact, not the interactive exchange that produced it. This blind spot makes it impossible to answer questions such as: who prompted the model, what exact prompts were used, and which responses were accepted or rejected.
Current practice: unchecked Claude agents in CI/CD
Most engineering groups treat Claude as another command‑line tool. A service account stores the model’s secret, the CI runner invokes the Claude CLI, and the output is merged into the codebase. The approach is simple, but it has three serious drawbacks.
- Shared credentials. The same API key is reused across dozens of pipelines, making revocation a nightmare.
- No visibility. Build logs contain the final files but not the conversational context that produced them.
- Uncontrolled execution. Any prompt can trigger expensive or risky operations, and there is no gate to stop a dangerous request before it reaches the model.
Because the connection goes straight from the runner to Claude’s endpoint, the pipeline has no place to enforce policies or capture a replayable record of the interaction.
The missing control: session recording without a guardrail
What engineers really need is a way to record every request and response that flows between the CI job and Claude, while still allowing the model to be called on demand. In theory, adding a logging proxy could capture the traffic, but without a dedicated data‑path component the proxy would be an after‑thought, lacking authentication, approval workflows, and the ability to block commands in real time.
Even with a proxy, the underlying credential would still be exposed to the runner, and the proxy would not be able to enforce just‑in‑time access or mask secrets that appear in model responses. In short, the desired outcome, session recording, remains unattainable unless the enforcement point sits directly on the traffic path.
hoop.dev as the identity‑aware gateway
Enter hoop.dev. The gateway is a Layer 7 proxy that sits between the CI/CD environment and Claude’s API. It authenticates the runner via OIDC, then forwards the request to Claude while applying policy checks at the protocol level. Because the gateway is the only place the traffic passes, it can reliably record every session, enforce just‑in‑time access, and mask any sensitive data that the model returns.
How session recording works
When a pipeline step invokes Claude, the request first reaches hoop.dev. The gateway captures the full request payload, the model’s response, and metadata such as the identity of the runner and the timestamp. This information is stored in an audit log that can be replayed later for forensic analysis or compliance reporting. Because hoop.dev controls the connection, the recorded session is guaranteed to be complete, no gaps caused by network hops or client‑side buffering.
Additional guardrails provided by the gateway
- Just‑in‑time access. The runner receives a short‑lived token from hoop.dev, limiting the window in which Claude can be called.
- Human approval for risky prompts. If a prompt matches a high‑risk pattern, hoop.dev can pause the request and route it to an approver before forwarding it.
- Inline masking. Any response that contains secrets, API keys, passwords, or tokens, can be redacted before it reaches the pipeline, preventing accidental leakage.
- Session replay. Recorded sessions can be streamed back to a developer or auditor, reproducing the exact interaction that generated the code.
All of these outcomes are possible only because hoop.dev occupies the data path. The surrounding identity provider, IAM roles, or CI configuration alone cannot provide session recording or inline masking; they merely decide who may start a request.
Getting started with hoop.dev and Claude
To add session recording to your CI/CD pipelines, deploy the hoop.dev gateway using the quick‑start Docker Compose flow or the Kubernetes manifests described in the getting‑started guide. Register Claude as a target connection, configure the gateway to hold the Claude API key, and enable the session‑recording feature in the gateway’s policy definition. Once the gateway is in place, update your pipeline scripts to point at the hoop.dev endpoint instead of calling Claude directly.
All of the configuration details, including how to define masking rules and approval workflows, are covered in the learning section. The source code and example manifests are available in the public repository, so you can audit the implementation before deploying it in production.
For the full list of steps and a walkthrough of a typical CI/CD integration, clone the repository at github.com/hoophq/hoop and follow the README.
FAQ
Does hoop.dev store Claude’s API key?
Yes. The gateway holds the credential internally, so the CI runner never sees the raw secret. This eliminates credential sprawl and reduces the blast radius of a leak.
Can I replay a recorded session after a pipeline run?
Absolutely. The audit log created by hoop.dev can be streamed back to a developer or auditor, reproducing the exact request and response sequence that generated the code.
Is session recording enough to meet compliance requirements?
Session recording provides the core evidence auditors look for, who accessed the model, what was asked, and what was returned. Combined with the gateway’s approval and masking features, it satisfies many internal and external audit frameworks that require traceability of AI‑generated artifacts.
