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

Many assume that AI coding assistants automatically log every interaction, but in reality they often run without any session recording.

Today, teams that embed Claude into their development pipelines on Google Cloud typically grant the agent a long‑lived service‑account key or embed an API token in the build environment. The key is copied into CI runners, shared across multiple projects, and never rotated. When a developer triggers a code‑generation request, the call travels directly from the runner to Claude’s endpoint, bypassing any central control point. The result is a blind spot: no replayable record of what prompts were sent, what code snippets were returned, or which user initiated the request. If a generated snippet contains a secret or a vulnerable pattern, the organization has no forensic trail to investigate.

What developers really need is a way to capture every Claude session while still allowing the agent to reach its service endpoint. The ideal solution records the request and response, ties the log to the initiating identity, and stores the data outside the runner so it cannot be tampered with. However, without an intervening gateway the request still flows straight to Claude, leaving the connection unmonitored, un‑approved, and un‑masked. The setup alone, service‑account identities, OIDC tokens, or IAM bindings, identifies who may call the API, but it does not enforce any guardrails on the traffic itself.

Why session recording matters for Claude agents

Session recording provides three concrete benefits:

• Forensic visibility: When a security incident surfaces, auditors can replay the exact prompt‑response exchange to understand intent and impact.
• Compliance evidence: Regulations that require proof of who accessed a code‑generation service can be satisfied with logs that tie each interaction to a user.
• Risk mitigation: By surfacing every generated snippet, teams can automatically scan for secrets or policy violations before the code reaches production.

These outcomes only materialize when the recording happens at the point where the request leaves the developer’s environment and before it reaches Claude. Anything less leaves a gap that can be exploited or simply ignored.

How hoop.dev enforces session recording

hoop.dev sits in the data path as an identity‑aware proxy for Claude’s API. The gateway runs a lightweight agent inside the same VPC as the Claude endpoint, and every developer or CI job must connect through the gateway instead of calling Claude directly. Because hoop.dev terminates the protocol, it can inspect the payload, attach the caller’s identity, and write a complete session record to a durable store.

When a request arrives, hoop.dev extracts the OIDC token presented by the caller, verifies the token against the organization’s IdP, and then forwards the request to Claude. During this forward, hoop.dev writes the full request and response pair to an audit log that ties each entry to the user’s identity. The log can be replayed for forensic and compliance purposes.

Because the gateway is the only place where traffic is observable, hoop.dev also enables optional inline masking of sensitive fields in Claude’s responses. If a generated snippet contains a secret, the gateway can redact it before the response reaches the developer’s console, while still preserving the original value in the secure audit record.

For deeper details on configuring session recording and masking policies, see the hoop.dev learn page.

All of these enforcement outcomes, recording each Claude session, linking it to the initiating identity, and optionally masking secrets, are possible only because hoop.dev occupies the data path. The surrounding identity setup (service accounts, OIDC tokens) merely decides who may start a request; hoop.dev is the mechanism that actually enforces the policy.

Deploying hoop.dev for Claude on GCP

Implementing this architecture follows a three‑step pattern:

1. Provision the gateway: Use the official getting started guide to launch hoop.dev in your GCP project. The guide walks you through deploying the Docker Compose stack or a Kubernetes manifest, configuring OIDC authentication, and attaching the network‑resident agent to the same subnet as the Claude endpoint.
2. Register Claude as a connection: In the hoop.dev UI you define a new target pointing at the Claude service URL. The gateway stores the service credentials, so developers never see them. You also enable the session‑recording toggle for this connection.
3. Update callers: Change your CI pipelines, local scripts, or IDE extensions to point at the hoop.dev endpoint instead of the raw Claude URL. The client libraries remain unchanged; the gateway presents the same wire‑protocol.

After these steps, every Claude interaction passes through hoop.dev, and the gateway automatically creates a replayable log for each session.

Frequently asked questions

Does hoop.dev add latency to Claude calls?

Because hoop.dev operates at Layer 7, the additional round‑trip is minimal, typically a few milliseconds. The security and audit benefits far outweigh the small performance impact.

Can I still use existing service‑account keys?

Yes. The keys remain the credential that hoop.dev uses to authenticate to Claude, but they are stored only inside the gateway. Callers never need direct access to the keys.

How are the session logs stored?

hoop.dev writes logs to a durable backend configured in the deployment (for example, Cloud Storage or a managed database). The logs are tied to the user identity, providing the evidence needed for audits.

Ready to add reliable session recording to your Claude workflows? Explore the open‑source repository on GitHub and follow the documentation to get started.