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

When Claude’s code‑generation prompts can run queries against BigQuery without ever exposing raw customer data, teams sleep better at night.

Engineers can let the AI suggest SQL, see only the columns they need, and still comply with internal privacy policies. The result is faster development, lower risk of accidental data leakage, and a clear audit trail that satisfies compliance reviewers.

Why data masking matters for Claude agents

Claude is often used as a pair‑programming assistant that writes queries on behalf of developers. The agent receives a prompt, crafts a SELECT statement, and executes it against a production data warehouse. If the response contains personally identifiable information, credit‑card numbers, or other regulated fields, that data can be copied, cached, or inadvertently displayed in a chat window. Without a guard at the query layer, the organization relies on the AI model not to repeat sensitive values, a fragile assumption.

Current pitfalls in the wild

Many teams grant Claude a service account that holds a static database credential. The credential is stored in a secret manager and referenced by the application that calls the Claude API. This approach has three major gaps:

• All queries travel directly from Claude to BigQuery, bypassing any inspection point.
• The service account usually has broad read permissions, allowing access to every table, even those that contain regulated data.
• No session recording or field‑level redaction is performed, so any accidental exposure is invisible to the security team.

In this state, the organization cannot guarantee that sensitive rows are hidden, nor can it prove to auditors that the AI output was reviewed before reaching end users.

What still needs to be addressed

Adding a policy that “sensitive fields must be masked” is a step forward, but the request still reaches BigQuery directly. The raw response still leaves the Claude process, and there is no place to enforce the rule, no log of who triggered the query, and no replay capability. The missing piece is a data‑path component that can inspect, transform, and record every interaction before the result is handed back to the AI.

hoop.dev as the enforcement layer

hoop.dev is a Layer 7 gateway that sits between Claude’s service account and BigQuery. It receives the OIDC token that identifies the AI agent, validates the token against the organization’s identity provider, and then forwards the request to the database. Because the gateway is the only point where traffic passes, it can apply the following enforcement outcomes:

• Inline data masking: hoop.dev inspects the result set and replaces values in columns marked as sensitive with a placeholder before the data reaches Claude.
• Just‑in‑time access: the gateway checks the request against a policy that limits which tables and columns the agent may read, rejecting any out‑of‑scope query.
• Session recording: every query, response, and masking action is logged in an audit trail that can be replayed for investigations.

The enforcement happens in the data path, not in the identity setup. Setup still decides who the request is – the OIDC token, the service account, the group membership – but it does not perform masking. Only hoop.dev, placed in the gateway, can guarantee that the policy is applied to every response.

How the architecture fits together

1. Setup phase: Create a service account for Claude, configure OIDC federation with your IdP, and assign the account to a group that represents AI coding agents. This step determines the identity that will be presented to the gateway.

2. Data‑path insertion: Deploy hoop.dev in the same network segment as BigQuery. The gateway holds the database credential, so Claude never sees the password or IAM key.

3. Policy definition: In the hoop.dev console, declare which columns are sensitive – for example, email, ssn, credit_card_number. The gateway will automatically replace those values with a mask such as *** for every query result.

4. Runtime enforcement: When Claude issues a SELECT, the request travels to hoop.dev, which validates the token, checks the policy, masks the fields, records the session, and finally forwards the sanitized result back to Claude.

Getting started

The open‑source repository provides a Docker Compose quick‑start that brings up the gateway, an OIDC mock, and a sample BigQuery connection. Follow the step‑by‑step guide in the getting‑started documentation to register the Claude service account, define masking rules, and verify that the masked output is returned.

All of the configuration details – the exact OIDC claim mapping, the list of protected columns, and the storage of audit logs – are covered in the learn section. Because hoop.dev is MIT licensed, you can run it inside your own VPC, apply your own retention policies, and extend the masking logic if needed.

FAQ

Does hoop.dev store the original, unmasked data?

No. The gateway only sees the raw result long enough to apply the mask, then discards it. The audit log records that a query was executed and which columns were masked, but it never retains the original values.

Can I use hoop.dev with other AI agents besides Claude?

Yes. The gateway works with any client that can present an OIDC token and speak the native protocol of the target service. The same masking policy can be reused for other coding assistants or internal bots.

What happens if a query tries to read a column that is not allowed?

hoop.dev blocks the request before it reaches BigQuery and returns an authorization error to the caller. This prevents accidental exposure of restricted data.

By inserting hoop.dev between Claude and BigQuery, organizations gain reliable data masking, fine‑grained access control, and a complete audit trail – all without changing the AI code or the underlying database configuration.

Explore the source and start contributing on GitHub.