Putting access controls around Claude: database access for AI coding agents (on Postgres)

Why uncontrolled database access is dangerous for AI coding agents

Giving Claude unrestricted database access is a recipe for data leakage. In many teams the AI coding assistant runs with a static PostgreSQL password baked into its container or injected as an environment variable. Teams share that credential across every Claude instance, often granting full read‑write rights on production schemas. The result is a single secret that teams can copy, rotate only when the whole service is redeployed, and it never appears in an audit log.

When Claude issues a query it does so directly against the database. If the model hallucinates a table name or a column that contains personally identifiable information, the database executes the request without any guardrails. A malicious prompt can cause a DELETE, ALTER, or even a data‑exfiltration query, and the engineering team has no record of who triggered it, what data was returned, or whether the operation should have been allowed.

What a proper non‑human identity solves – and what it still leaves exposed

Moving Claude to an OIDC‑issued service account is a step forward. The token can be scoped to a specific database role, limiting the set of tables Claude may touch. However, the request still travels straight to PostgreSQL, bypassing any runtime policy engine. The gateway does not apply inline masking, humans cannot approve a risky query, and the system does not record the session for later review. The token alone cannot enforce command‑level controls.

How hoop.dev provides the missing enforcement layer

hoop.dev is a Layer 7 gateway that sits between Claude and the PostgreSQL endpoint. It terminates the client connection, holds the actual database credential, and forwards traffic only after applying policy checks.

When Claude initiates a connection, hoop.dev authenticates the OIDC token, maps the identity to a set of policies, and then proxies the session. The gateway can:

• Mask sensitive fields in query results, ensuring that columns such as SSN or credit‑card numbers are redacted before Claude sees them.
• Require just‑in‑time approval for commands that match a risk pattern, for example a DELETE FROM or an ALTER TABLE that touches production tables.
• Block dangerous statements outright, preventing accidental or malicious data destruction.
• Record the entire session for replay, audit, and compliance reporting.

hoop.dev makes these outcomes possible because it sits in the data‑path. The identity token, the service account, and the database role each contribute information, but enforcement lives exclusively in the gateway.

Architectural steps to protect Claude’s database access

1. Deploy the hoop.dev gateway in the same network segment as the PostgreSQL instance. The quick‑start guide walks you through a Docker‑Compose deployment that includes OIDC verification out of the box.

2. Register the PostgreSQL target with hoop.dev, providing the host, port, and the credential that the gateway will use. The gateway retains the credential, so Claude never obtains the database password.

3. Configure an OIDC client for Claude. The service account receives a short‑lived token that encodes the intended role. hoop.dev reads the token, extracts group membership, and maps it to the policies defined in step 4.

4. Define policies in hoop.dev’s policy store: specify which tables or columns may be accessed, which statements require approval, and which columns should be masked. Policies are evaluated per‑query, so even a well‑intentioned request is subject to the same safeguards.

5. Enable session recording. hoop.dev records each request and response in a log that can be used for audit and replay by an auditor or a security analyst.

With this architecture the AI coding agent gains the ability to read and write only what is explicitly allowed, while the organization retains full visibility and control over every database interaction.

Getting started and further reading

For a step‑by‑step walkthrough of the deployment, connection registration, and policy definition, see the getting‑started guide. The learn section provides deeper explanations of masking, approval workflows, and session replay.

FAQ

Q: How does hoop.dev decide which columns to mask?
A: Masking rules are defined in the gateway’s policy store. When a query result is streamed back, hoop.dev inspects the column metadata and replaces values that match a mask rule before they reach Claude.

Q: Does Claude ever see the database password?
A: No. hoop.dev holds the credential and presents a temporary session token to the database. Claude only presents its OIDC token to hoop.dev.

Q: Can we replay a session after the fact?
A: Yes. hoop.dev records each session in a log that can be replayed for forensic analysis or compliance reporting.

Explore the open‑source implementation and contribute to the project on GitHub.