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

When a contractor leaves a project, their CI job continues to run Claude‑driven code generation against a production Postgres cluster. The job still holds a static credential that was baked into the pipeline, and every new query it issues can read or modify live data without any human review. The result is a silent data‑exfiltration risk that goes unnoticed until a downstream service fails.

Why production access matters for AI coding agents

Claude, the large‑language model offered by Anthropic, can write and refactor SQL on the fly. When developers embed Claude in CI pipelines, the model becomes an automated actor that talks directly to the database. In a production environment that means any generated statement could affect billing, compliance, or customer privacy. Traditional access controls, static passwords or long‑lived service accounts, do not provide the granularity needed to limit Claude to read‑only or to require a human sign‑off before a destructive command runs.

The missing enforcement gap

Identity providers such as Okta or Azure AD can authenticate the CI job, and role‑based policies can restrict which databases the job may reach. Those policies stop the job from connecting to the wrong host, but they do not inspect the actual SQL payload. Without a gate that sits on the data path, there is no place to:

• Mask sensitive columns returned by SELECT statements.
• Block DROP, ALTER, or DELETE commands before they hit Postgres.
• Require a real‑time approval workflow for any statement that writes data.
• Record the full session for later replay and audit.

All of those controls are necessary to achieve true production access governance for an AI coding agent.

How hoop.dev secures Claude’s access to Postgres

hoop.dev is a Layer 7 gateway that sits between Claude’s client library and the Postgres endpoint. The architecture follows three distinct responsibilities:

1. Setup: Identity is handled by OIDC or SAML. The CI job obtains a short‑lived token from the organization’s identity provider. The token proves who the request is and whether it may start, but it does not enforce any data‑level policy.
2. The data path: The token is presented to hoop.dev, which proxies the TCP stream to Postgres. Because the gateway sits on the protocol level, it is the only place the system can inspect, modify, or block the SQL payload.
3. Enforcement outcomes: While the request flows through hoop.dev, the gateway can mask columns that contain personal data, reject any command that matches a “dangerous” pattern, and trigger an approval workflow for write operations. Every interaction is recorded, enabling replay for forensic analysis.

In practice, a developer configures a Postgres connection inside hoop.dev, supplies the database credential to the gateway (the credential never leaves the agent’s network), and then points Claude’s client to the hoop.dev endpoint. When Claude generates a query, the gateway evaluates the statement against the configured policies. If the statement is a simple SELECT, the response may have sensitive fields masked before it reaches the CI job. If the statement attempts to modify data, the gateway either blocks it outright or forwards it to an approval queue where a security engineer can approve or reject the operation in real time.

Key enforcement outcomes for production access

Because hoop.dev is the sole data‑path component, the following outcomes are guaranteed only when the gateway is present:

• Session recording: hoop.dev captures the full request and response stream, creating a comprehensive audit log that can be replayed for compliance reviews.
• Inline data masking: Sensitive columns such as SSN or credit‑card numbers are replaced with placeholder values before the data reaches Claude, reducing exposure risk.
• Just‑in‑time approval: Write‑heavy statements trigger a workflow that requires a human decision, turning an automated agent into a controlled actor.
• Command blocking: Predefined patterns for destructive commands are rejected automatically, preventing accidental schema changes.

Each of these controls would be impossible to enforce if the CI job connected directly to Postgres, because the database itself does not understand the intent behind Claude‑generated SQL.

Getting started with hoop.dev

To adopt this model, start by deploying the hoop.dev gateway in the same network segment as your Postgres cluster. The quick‑start guide walks through a Docker‑Compose deployment that includes OIDC authentication, masking rules, and guardrails out of the box. After the gateway is running, register a Postgres connection, upload the database credential, and define the policies that reflect your production access requirements. Finally, point Claude’s client library at the hoop.dev endpoint and let the gateway enforce the rules you have set.

For step‑by‑step instructions, see the getting‑started documentation. The broader feature set, including approval workflows and masking configuration, is described in the learn section. The full source code and contribution guide are available on GitHub.

FAQ

Does hoop.dev replace the need for database‑level roles?

No. Database roles still define what a user can do once a statement reaches Postgres. hoop.dev adds a layer that can inspect, mask, and approve the statement before it ever touches the database.

Can I use hoop.dev with other LLMs besides Claude?

Yes. The gateway is language‑agnostic; any client that speaks the underlying protocol (Postgres in this case) can be protected, whether it is driven by Claude, GPT, or a custom model.

What happens if the gateway is unavailable?

Because all traffic must pass through hoop.dev, a failure in the gateway blocks access entirely. This is a deliberate safety mechanism that prevents accidental bypass of production access controls.