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

How can you enforce database access for Claude’s AI coding agent without exposing credentials?

Many teams treat an LLM‑driven coding assistant as just another service account. They generate a static username and password, store it in a secret manager, and hand the same secret to every Claude instance that needs to run queries. The agent connects directly to the PostgreSQL or MySQL endpoint, runs whatever SQL it generates, and returns the result to the user. There is no per‑request visibility, no ability to block a dangerous command, and no way to hide sensitive columns such as credit‑card numbers or personal identifiers. The audit trail lives only in the database’s own logs, which are difficult to correlate with the LLM’s request.

What you really need is a guardrail that lets an AI agent request a database connection, but still enforces least‑privilege, requires human approval for risky statements, masks protected fields in the response, and records the entire session for later review. The precondition is that the request still reaches the database directly; the identity system can tell who is asking, but without a gateway the request bypasses any real enforcement. In other words, authentication and token issuance are necessary, but they are not sufficient to guarantee that the AI‑driven query complies with policy.

Enforcing database access for Claude agents

To satisfy the precondition, you must place a control point on the data path itself. That control point must be able to inspect the wire‑level protocol, apply policies, and then forward the request to the target database. Only a gateway that sits between the Claude runtime and the database can provide the following outcomes:

• Real‑time masking of sensitive columns before they leave the database.
• Blocking of destructive commands such as DROP TABLE or DELETE without explicit approval.
• Just‑in‑time approval workflows that pause a query until a human reviewer signs off.
• Full session recording that captures every statement and response for replay.

All of those capabilities depend on the gateway being in the data path; they cannot be achieved by the identity provider or by configuring the database alone.

hoop.dev as the data‑path gateway

hoop.dev is an open‑source Layer 7 gateway that proxies connections to databases, Kubernetes, SSH, RDP, and internal HTTP services. When a Claude instance authenticates via OIDC, hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed. The actual database credentials are stored inside hoop.dev, so the AI agent never sees them.

Because hoop.dev sits on the wire, it can inspect each SQL statement, apply inline masking rules, and enforce command‑level approval policies. If a query attempts to read a column marked as sensitive, hoop.dev rewrites the response to replace the value with a placeholder. If a statement matches a high‑risk pattern, hoop.dev pauses the flow and routes the request to an approval UI where an authorized engineer can approve or reject it. Every interaction is recorded, and the recording can be replayed later for audit or forensic analysis.

How the enforcement flow works

1. Claude initiates a database connection using its standard client library.
2. The client’s traffic is intercepted by the hoop.dev agent running inside the Azure VNet.
3. hoop.dev validates the OIDC token, maps the request to a policy, and checks whether the operation is allowed.
4. If the statement is safe, hoop.dev forwards it to the target database and returns the (potentially masked) result.
5. If the statement is risky, hoop.dev triggers a just‑in‑time approval step before forwarding.
6. Regardless of outcome, hoop.dev records the full session for replay.

Because hoop.dev is the only component that can see both the plaintext request and the database response, it is the sole source of truth for enforcement outcomes.

Benefits of the gateway approach

• Least‑privilege enforcement: Policies are attached to the identity that the AI agent presents, not to the static secret.
• Data protection: Inline masking ensures that even a successful query never leaks regulated fields.
• Risk mitigation: Dangerous commands are halted before they reach the database.
• Auditable evidence: Recorded sessions provide a complete audit trail for compliance reviews.
• Zero credential exposure: The AI agent never receives the database password, reducing blast radius if the agent is compromised.

Getting started

To protect Claude’s database access on Azure, deploy the hoop.dev gateway inside the same virtual network as your database. Configure an OIDC connection to your Azure AD tenant, register the database as a connection, and define masking and approval policies that match your data‑privacy requirements. Detailed steps are available in the getting‑started guide. For deeper details on policy configuration, see the hoop.dev learn site. The open‑source repository contains all the manifests you need to run hoop.dev in Docker Compose or Kubernetes.

All of the policy definitions, masking rules, and approval workflows are expressed in declarative YAML files. Once the gateway is running, Claude’s client libraries do not need any code changes – they simply point to the hoop.dev endpoint instead of the raw database host.

Begin by exploring the open‑source code on GitHub.

FAQ

Does hoop.dev store my database passwords?

No. hoop.dev holds the credentials only in memory for the duration of a session. The AI agent never receives the secret, and the gateway does not write the password to disk.

Can I audit who ran which query?

Yes. hoop.dev records every statement and response, ties it to the authenticated identity, and makes the log searchable for compliance or forensic purposes.

What happens if an approval is denied?

hoop.dev aborts the request and returns an error to the caller. The session still records the denial event, providing a complete audit trail.

By placing enforcement in the data path, hoop.dev gives you the granular control you need over AI‑driven database access while keeping the implementation simple and auditable.