When a contract ends, the cloud‑native team often forgets to revoke the service account that powers an AI coding assistant. Without audit trails, the team cannot reconstruct the model’s actions. The Claude agent, still running inside a Kubernetes pod, can continue to issue API calls, push code, or read secrets without anyone noticing. In that moment there is no record of what the model asked the cluster to do, no way to prove whether a data leak occurred, and no mechanism to stop a rogue request before it reaches a database.
Claude agents are attractive because they can write code, refactor functions, and even open pull requests on behalf of developers. The convenience comes with a hidden risk: the model operates under a static credential that may be over‑privileged, and the Kubernetes network gives it unrestricted lateral movement. Without visibility, security teams cannot answer basic audit questions such as who triggered a particular change or what data was returned by a downstream service.
Most organizations already enforce least‑privilege for human users through OIDC or SAML providers. They assign short‑lived tokens, embed group membership, and require multi‑factor authentication. Extending that same identity fabric to Claude is a logical first step. The model can be given a dedicated service account that only allows read‑only access to a repository, for example. However, even with a scoped service account the request still travels directly to the target pod or database, bypassing any checkpoint that could log the interaction or intervene if the model tries to execute an unexpected command.
The missing piece is a control surface that sits on the data path itself. By placing a gateway between the Claude pod and the infrastructure it talks to, every request can be inspected, recorded, and, if necessary, blocked or routed for human approval. This approach satisfies the need for audit trails while preserving the benefits of a non‑human identity and a least‑privilege token.
hoop.dev provides exactly that Layer 7 gateway. It runs as a network‑resident agent alongside your Kubernetes cluster and proxies all traffic destined for the resources Claude needs to reach. Because hoop.dev operates at the protocol level, it can see each command, response, and error before they leave the cluster.
When Claude initiates a connection, whether it is a Kubernetes exec session, an HTTP request to an internal service, or a database query, hoop.dev intercepts the flow. The gateway authenticates the Claude service account via OIDC, validates group membership, and then enforces policy that you define centrally. Because the gateway is the only path to the target, any policy you attach is guaranteed to be applied.
Why audit trails matter for Claude agents
Audit trails are the forensic backbone for any system that automates code changes. hoop.dev records every session byte‑for‑byte, timestamps each request, and keeps the logs in a location isolated from the compute node running Claude. The result is a complete replayable history: you can see exactly which prompt caused a git push, which query retrieved a customer record, and how long the operation took. This level of visibility satisfies internal governance, supports incident response, and provides the evidence auditors expect when they ask for “who did what and when”.
Beyond simple logging, hoop.dev can enrich audit trails with contextual metadata such as the originating service account, the Kubernetes namespace, and any approval workflow that was triggered. That metadata makes it possible to filter logs by risk level, correlate events across services, and generate reports that highlight anomalous behavior.