When a new Claude coding agent is added to a GCP project, the team often copies a service‑account key into the container image so the agent can run SQL statements against the production database. The key never changes, the container can spin up on any node, and every query is logged only by the database’s own audit trail, which does not capture who or what issued the command. The result is a long‑lived credential with unrestricted reach and no visibility into the agent’s activity, leaving database access governance ineffective.
Even after the team switches to an OIDC‑based identity for the agent, the token simply grants the agent permission to open a direct TCP connection to the database. The request still travels straight to the database server, bypassing any point where a policy could block a dangerous statement, require a human approval, or redact sensitive columns. The setup now has proper authentication, but it lacks the enforcement layer that turns authentication into true database access governance.
Why database access matters for Claude agents
Claude agents can generate code that reads or writes data on the fly. Without a guardrail, a single malformed prompt can produce a DROP TABLE or expose customer PII in a response. Auditors expect to see who accessed which rows, under what justification, and whether any protected fields were masked. Engineers need a way to grant temporary, purpose‑specific rights that disappear when the job finishes. The missing piece is a runtime proxy that sits on the data path, inspects each statement, and enforces policy before the database ever sees the command.
Architectural requirement: a data‑path gateway
The solution must satisfy three conditions:
- All traffic between the Claude agent and the database must flow through a controlled point.
- The gateway must be able to evaluate the identity token, apply just‑in‑time (JIT) rules, and request approvals when a query exceeds a risk threshold.
- The gateway must record every session, mask any columns that contain regulated data, and allow replay for forensic analysis.
Only a Layer 7 gateway that proxies the wire‑protocol can meet these criteria. Any check performed inside the agent or after the database receives the query would be too late to prevent a breach.
How hoop.dev implements the gateway for Claude
hoop.dev provides exactly the data‑path component described above. The gateway runs as a network‑resident service inside the same VPC as the database. An agent deployed alongside the database holds the static database credential, but the credential never leaves the agent. Claude agents authenticate to hoop.dev via OIDC; hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed.
When a Claude agent issues a SQL statement, hoop.dev intercepts the protocol, evaluates the statement against the configured policy, and takes one of several actions:
- Inline masking: hoop.dev rewrites the response to replace or redact columns that match a masking rule, ensuring that PII never reaches the downstream consumer.
- Command blocking: dangerous commands such as DROP, TRUNCATE, or mass‑update statements that exceed a row‑count threshold are rejected before they hit the database.
- Just‑in‑time approval: queries that cross a risk boundary trigger an approval workflow; a human reviewer can allow or deny the operation in real time.
- Session recording: hoop.dev captures the full request/response stream, timestamps, and the identity that initiated the session. The recording can be replayed later for audit or incident response.
All of these enforcement outcomes exist because hoop.dev sits in the data path. The identity system alone cannot provide them; the gateway is the only place where the policy can be applied consistently.
Deploying hoop.dev for Claude on GCP
Start by deploying the hoop.dev gateway in the same GCP project as the target database. The quick‑start guide walks through a Docker Compose deployment that includes an OIDC provider configuration, masking rules, and guardrails. After the gateway is running, register the PostgreSQL (or MySQL) connection in hoop.dev, supplying the host, port, and the service‑account credential that the internal agent will use.
Next, configure Claude’s runtime to obtain an OIDC token from the organization’s identity provider. The token is presented to hoop.dev when the agent opens a database client. hoop.dev validates the token, applies the JIT policy, and either forwards the query to the database or enforces one of the controls described above.
Because hoop.dev records each session, you instantly gain a searchable audit trail that shows which Claude prompt generated which SQL statement, who approved it, and what data was returned. This evidence satisfies compliance requirements and gives engineers confidence that AI‑generated code cannot silently exfiltrate or destroy data.
Key benefits at a glance
- Fine‑grained database access control for AI agents without modifying the agent code.
- Real‑time masking of regulated columns.
- Automatic blocking of high‑risk commands.
- Just‑in‑time approval workflow that integrates with existing ticketing systems.
- Full session replay for forensic analysis and compliance reporting.
FAQ
Q: Does hoop.dev store the database credentials?
A: The credentials are kept inside the internal agent that runs next to the database. The gateway never exposes them to the Claude agent or any other client.
Q: Can I use hoop.dev with other AI coding models?
A: Yes. The architecture is model‑agnostic; any service that can present an OIDC token can be routed through hoop.dev for the same set of controls.
Q: How does hoop.dev integrate with existing CI/CD pipelines?
A: CI jobs can request a short‑lived OIDC token, invoke the database through hoop.dev, and benefit from the same masking and approval policies without any code changes.
For a step‑by‑step walkthrough, see the getting‑started guide. The full source code and contribution instructions are available on GitHub. Additional feature details can be explored in the learn section. Implementing hoop.dev gives you a single, enforceable control surface for database access that protects both your data and your AI agents.
