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

A fully recorded Claude coding session lets security teams replay every prompt and response, ensuring accountability without slowing developers. When every interaction is captured, auditors can verify that no proprietary code or secrets have been exfiltrated, and incident responders can trace exactly what the model generated.

Why session recording matters for Claude agents

Claude is often deployed as a background service that receives code snippets, suggests implementations, and writes files directly into a repository. On Azure, teams typically spin up a virtual machine or container, grant the service account network access to internal Git servers, and let the model run unchecked. This convenience creates two blind spots: the lack of an audit trail that can be verified for integrity, and the inability to prove that the model behaved within policy. Without a recorded stream, a single erroneous suggestion can go unnoticed until it surfaces in production, at which point remediation is costly.

The unsanitized reality today

In many organizations, the Claude agent authenticates to Azure using a static service principal that has broad write privileges on source control and storage. The agent connects directly to the Git endpoint over HTTPS, and the network path bypasses any inspection point. Engineers trust that the service principal is correctly scoped, but the credential is often shared across multiple projects, rotated infrequently, and never audited at the command level. As a result, every push, branch creation, or secret read happens without visibility, and any misuse blends into normal traffic.

What the missing piece fixes – and what it still leaves open

Introducing a strong identity foundation, OIDC‑based tokens, least‑privilege roles, and Azure AD service accounts, solves who can start a session, but it does not stop the request from reaching the Git server unchecked. The connection still travels straight from the agent to the target, meaning there is no place to enforce policies, no way to capture the exact request and response, and no mechanism to require human approval for risky operations. In other words, the setup defines the caller, but it does not provide the guardrails that a regulated environment demands.

hoop.dev as the data‑path enforcement layer

hoop.dev inserts a Layer 7 gateway between Claude agents and the Azure resources they access. The gateway runs a network‑resident agent close to the target service and proxies all traffic. Because every request must pass through this proxy, hoop.dev becomes the only point where inspection, recording, and policy enforcement can occur.

Setup: identity and provisioning

First, configure Azure AD to issue OIDC tokens for the Claude service account. Register those tokens with hoop.dev so it can verify the caller’s identity and group membership. The gateway stores the credential needed to reach the Git endpoint, so the Claude process never sees a secret. This separation satisfies the principle of least privilege while keeping the credential out of the agent’s memory.

The data path: proxying Claude traffic

When Claude issues a Git command, the request is routed to the hoop.dev gateway. The gateway parses the Git protocol, applies any inline masking rules (for example, redacting secret files in responses), and forwards the request to the actual Git server. Because the gateway sits at the protocol layer, it can capture the full request and response payload without requiring changes to Claude or the client libraries.

Enforcement outcomes: session recording

hoop.dev records each Claude session in an audit log. The log contains timestamps, the authenticated identity, the exact Git commands issued, and the responses returned. Security teams can replay any session in a sandboxed viewer, extract a forensic timeline, and demonstrate compliance with internal policies or external regulations. The recording happens automatically; there is no separate step to enable it, and the agent never has direct access to the underlying storage.

Common mistakes to avoid

• Skipping the gateway entirely and allowing Claude to contact the Git server directly. Without the proxy, no session recording or masking can occur.
• Relying on static service principals without rotating them through OIDC. Tokens provide short‑lived credentials that reduce the blast radius of a compromised secret.
• Disabling recording for performance reasons. The gateway is designed to handle high‑throughput Git traffic; turning off recording removes the core security benefit.
• Forgetting to map Azure AD groups to hoop.dev policies. Proper group mapping ensures that only authorized identities can trigger write operations.

Getting started

Follow the getting‑started guide to deploy the hoop.dev gateway in your Azure environment. The documentation walks you through OIDC configuration, service account provisioning, and enabling session recording for Git traffic. For deeper insight into policy definitions, masking rules, and audit‑log access, explore the learn section of the website.

FAQ

Does hoop.dev store the recorded sessions?

hoop.dev writes each session to a configurable backend that your organization controls. The storage location is defined during deployment, ensuring that logs remain under your governance.

Can I replay a session without exposing the original credentials?

Yes. Because the gateway never hands the underlying credential to Claude, the replay environment can reconstruct the interaction using the recorded data alone, keeping secrets safe.

Is session recording optional for some connections?

Recording can be toggled per connection type, but disabling it defeats the primary security purpose of the gateway for Claude agents.

Ready to see the code in action? Explore the open‑source repository on GitHub and contribute to the project.