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

Many assume that letting an AI coding assistant like Claude query a database is safe because the model never sees raw rows, but that belief ignores data masking requirements. In reality the assistant can retrieve and expose sensitive fields unless the response is masked.

Teams often give Claude a service account that has broad read access to a production PostgreSQL instance. They store the credential in a configuration file or container secret that developers share. When Claude generates a SELECT statement, the query travels directly to the database, returns full rows, and the raw data lands in the model’s output. No audit trail records which columns were returned, and no inline transformation hides personally identifiable information. If a developer later discovers that credit‑card numbers or health identifiers were included in a response, the exposure is already baked into the model.

Why data masking matters for Claude agents

The immediate fix is to add a masking layer, but the problem runs deeper. Even with a masking policy, the request still reaches the database unfiltered. The database sees the original query, executes it, and returns the complete result set. Without a control point that can inspect and transform the response before it leaves the data path, the mask never takes effect. Moreover, the request still uses a static credential that grants far more privilege than any single user should have. The missing piece is a place where the policy can be enforced and the action recorded.

Setup: defining a non‑human identity for Claude

The security team provisions a dedicated service identity for the Claude agent. An OIDC provider (for example, Azure AD or Google Workspace) issues a short‑lived token that carries only the group membership required to run the specific queries the agent needs. The token is scoped to the "Claude‑Postgres" role. This step decides who the request is and whether it may start, but on its own it does not enforce any data‑handling rule.

Data path: inserting a gateway between Claude and Postgres

hoop.dev sits in the data path as a Layer 7 gateway that proxies PostgreSQL traffic. When Claude connects, the request routes through the gateway instead of going straight to the database. The gateway holds the database credential, so the agent never sees it. Because hoop.dev is the only place that inspects traffic, it can apply policies in real time.

hoop.dev masks sensitive fields in query results, records every session for replay, and can require a human approval step for risky statements. The masking policy lives in the gateway configuration and applies to every response that matches the rule set. Because hoop.dev is the active subject, the masking happens reliably regardless of how the underlying database or credential is configured.

Enforcement outcomes: what hoop.dev guarantees

• hoop.dev masks columns that contain personal data before the result leaves the gateway.
• hoop.dev records the full query, the identity that issued it, and the masked response for audit.
• hoop.dev blocks statements that attempt to export large data sets without prior approval.
• hoop.dev provides a replayable session stream that investigators can review.

All of these outcomes exist only because hoop.dev sits in the data path. If the gateway were removed, the static credential would still allow unrestricted reads, and no masking or audit would occur.

Implementing the solution conceptually

From an architectural perspective, the team follows these steps:

1. Register a PostgreSQL connection in hoop.dev, supplying the host, port, and a privileged credential that the gateway will use.
2. Define a masking rule that targets columns such as email, ssn, or credit_card_number. The rule specifies a redaction pattern or tokenization strategy.
3. Assign the Claude service identity to a policy that permits only the required queries and binds it to the masking rule.
4. Deploy the hoop.dev gateway near the database, using the official Docker Compose quick‑start or a Kubernetes manifest.
5. Configure Claude to connect to the gateway endpoint instead of the raw database address.

Because the gateway enforces the mask, Claude never receives raw sensitive values. The session logs and masked responses live outside the agent’s process, providing evidence for compliance audits without exposing the data to the model.

Getting started and where to learn more

The open‑source project includes a quick‑start that provisions the gateway, registers a PostgreSQL target, and shows how to create a masking policy. Follow the getting‑started guide for step‑by‑step instructions, and explore the learn section for deeper coverage of masking rules and session replay.

Explore the source code, contribute improvements, or file an issue on GitHub: hoop.dev repository.

FAQ

Does data masking affect query performance?

hoop.dev applies the mask after the database returns the result set, so the impact is limited to the additional processing step in the gateway. For most workloads the latency increase is negligible compared to the security benefit.

Can I mask data conditionally based on the user?

Yes. Masking policies can reference the identity that issued the query, allowing you to apply stricter redaction for broader‑privilege service accounts while leaving less‑sensitive fields visible to trusted users.

What happens if Claude tries to run a prohibited command?

hoop.dev blocks the command before it reaches PostgreSQL and returns an error to the agent. The blocked attempt logs as part of the session record.