When an AI coding assistant like Claude writes directly to internal services, a single stray query can corrupt a database, expose secrets, or trigger a cascade of downstream failures. Without audit trails, the resulting downtime, data loss, and remediation effort quickly outweigh any productivity gain, and auditors will question how the change was authorized.
Teams often treat Claude as just another service account: they embed a static credential in the deployment pipeline, grant it broad read‑write rights, and assume the model is safe because the code is generated by a trusted model. In practice, that assumption leaves the organization without visibility into what Claude actually executed, which fields were returned, or whether a risky command was issued.
Why audit trails matter for Claude agents
Audit trails give you a tamper-evident record of every request, response, and decision point. With a reliable log you can answer questions such as:
- Which user‑initiated prompt caused a particular data write?
- Did Claude retrieve a secret that should have been masked?
- Was a destructive command approved by a human before execution?
Without that evidence, post‑incident analysis becomes guesswork, and compliance programs lack the proof points they need.
The gap in current setups
Most organizations rely on two pieces of the puzzle:
- Setup: an identity provider that issues a token for Claude, and a role that grants the service account the required permissions.
- Direct connection: Claude talks straight to the target database or API using the granted credentials.
The setup correctly identifies who is making the request, but it does not enforce anything on the path to the resource. The request reaches the database unmediated, so there is no place to inspect the query, mask sensitive columns, or require a human approval step. Consequently, audit trails are absent, and any policy you wish to apply, such as “do not allow DELETE without approval”, cannot be enforced.
Putting hoop.dev in the data path
hoop.dev is a Layer 7 gateway that sits between Claude’s token and the infrastructure it accesses. The gateway runs a network‑resident agent next to each target (for example, next to a PostgreSQL instance). When Claude presents its OIDC token, hoop.dev validates the identity, checks group membership, and then proxies the connection. Because the proxy is the only point where traffic flows, hoop.dev can apply guardrails in real time.
In this architecture the setup still decides who Claude is, but the data path, the hoop.dev gateway, is where enforcement happens. No other component sees the raw credentials, and no traffic bypasses the gateway.
How hoop.dev creates audit trails
Once the connection is routed through hoop.dev, the gateway records every request and response at the protocol level. It stores a timestamped log entry that includes the user identity, the exact query, and the outcome. Because hoop.dev owns the session, it can also replay the interaction for forensic review.
In addition to raw logging, hoop.dev adds three enforcement outcomes that directly support audit‑trail requirements:
- Session recording: hoop.dev captures the full dialogue, enabling replay of exactly what Claude sent and what the target returned.
- Inline masking: when a response contains sensitive fields, hoop.dev can redact or replace those values before they reach Claude, while still logging the original content for audit purposes.
- Just in time approval: for commands that match a risky pattern (for example, DROP DATABASE), hoop.dev can pause the request and route it to a human approver. The approval decision is recorded alongside the request, completing the audit trail.
All of these outcomes exist because hoop.dev sits in the data path; remove the gateway and the capabilities disappear.
Next steps
To start protecting Claude with audit trails, follow the getting started guide to deploy the gateway and register your Claude endpoint as a connection. The documentation explains how to configure OIDC authentication, enable session recording, and define masking rules for sensitive columns.
For deeper insight into the feature set, explore the feature documentation. It walks through policy creation, approval workflows, and replay tooling.
When you are ready to examine the source code or contribute, explore the repository on GitHub. The project is MIT licensed and welcomes community involvement.
FAQ
Do I need to change Claude’s code to use hoop.dev?
No. hoop.dev works at the protocol layer, so Claude continues to use its standard client libraries. The only change is the endpoint address, which points to the gateway instead of the raw service.
Can I mask only specific columns in a query result?
Yes. hoop.dev’s masking policies let you define field‑level rules. When a result set contains a column marked as sensitive, the gateway redacts the value before it reaches Claude while preserving the original value in the audit log.
What happens if an approval is denied?
hoop.dev aborts the request and records the denial event. Claude receives an error response, and the full decision trail is available in the audit log for later review.
