Putting access controls around Claude: audit trails for AI coding agents (on on-prem)

Without audit trails, Claude agents can write, read, and delete code on‑prem without anyone knowing.

In many on‑prem deployments, teams expose a single service account credential to the Claude coding agent so it can call internal repositories, databases, and build tools. The credential is stored in a config file or environment variable that developers share across projects. Because the agent runs with that credential continuously, any command it issues, whether a harmless lint or a destructive schema change, leaves no trace. When a breach or accidental data loss occurs, the organization cannot answer who issued the request, what data was accessed, or whether the action was authorized. The lack of visibility also makes it impossible to satisfy internal governance or external audit requirements.

Adding a non‑human identity layer, such as an OIDC token that the Claude service presents, solves the authentication problem but does not close the audit gap. The token proves the agent is allowed to connect, yet the request still travels directly to the target system. No component in the path records the exact query, no inline masking protects sensitive responses, and no approval workflow can intervene on risky operations. The organization therefore still operates without the essential evidence needed to detect abuse or to prove compliance.

Why audit trails matter for Claude

Claude can generate code, modify configuration files, and invoke internal APIs at a speed that far exceeds human review. Each interaction may touch source code, secret keys, or production databases. An audit trail that captures the full request and response sequence provides three critical benefits:

• Forensic visibility – security teams can replay the exact session to understand how a vulnerability was introduced.
• Policy enforcement – compliance officers can verify that every operation aligns with least‑privilege and change‑management rules.
• Risk reduction – developers gain confidence that any unexpected behavior can be traced back to a specific command.

The missing enforcement layer

When the Claude agent talks directly to a database or a Git server, the only place to enforce controls would be inside the target service. That approach is fragile because the service’s own logging may be incomplete, and the service cannot block a command before it runs without extensive custom logic. Moreover, the service cannot provide just‑in‑time approval or inline masking without being rewritten for each use case.

The proper place for enforcement is a dedicated gateway that sits between the identity (the OIDC token) and the infrastructure resource. By interposing a Layer 7 proxy, the organization gains a single, immutable point where policies are evaluated, actions are recorded, and sensitive fields can be redacted in real time.

hoop.dev as the data‑path gateway

hoop.dev fulfills that role. It runs a network‑resident agent next to the on‑prem resources and proxies every Claude request. Because hoop.dev is the only component that sees the traffic, it can:

• Record each session, storing a complete request‑and‑response log that auditors can replay.
• Apply inline masking to hide passwords, API keys, or personally identifiable information returned by the target.
• Require just‑in‑time approval for commands that match a high‑risk pattern, such as schema migrations or credential rotations.
• Block prohibited commands before they reach the backend, preventing accidental or malicious damage.
• Maintain a per‑user audit trail tied to the OIDC identity that presented the token, ensuring accountability.

All of these outcomes exist only because hoop.dev sits in the data path. The setup phase, defining the OIDC client, provisioning the service account, and registering the Claude target, establishes who may start a session, but the enforcement happens exclusively inside the gateway.

To get started, follow the getting‑started guide. The documentation walks you through deploying the gateway, registering the Claude connection, and configuring the audit‑trail policies that match your risk profile. For deeper insight into masking rules and approval workflows, see the learn section of the site.

Common pitfalls to avoid

• Relying on the target’s native logs alone – they often omit the exact command payload and cannot enforce pre‑execution checks.
• Storing the service‑account credential in a shared file – hoop.dev holds the credential securely, so agents never see it.
• Skipping approval policies for high‑impact commands – without a JIT approval step, a mis‑configured Claude prompt could trigger destructive actions.

FAQ

Do I need to change my existing Claude prompts?
No. Claude continues to send requests as before; hoop.dev transparently proxies the traffic and adds audit capabilities.

Can hoop.dev mask data returned from a Git repository?
Yes. The gateway can be configured to redact secret files or credential patterns in any response before it reaches the agent.

Is the audit log tamper‑proof?
The log is stored outside the target system and is only writable by the gateway process, providing a reliable evidence source for investigations.

Ready to see the code and contribute? Explore the repository on GitHub and start securing your Claude deployments today.