SOC 2 for AI coding agents: guardrails for code and data access (on BigQuery)

How can you prove to a SOC 2 auditor that an AI coding agent accessed BigQuery safely and under control?

SOC 2 evidence for AI coding agents

Today many teams hand an AI‑driven code‑assistant a service account key or a static OAuth token and let it run queries against BigQuery. The agent talks directly to the Google endpoint, the credential never changes, and the only log that exists is whatever BigQuery emits internally. There is no record of who triggered the request, no approval step, and no guarantee that sensitive columns were hidden from the agent’s output. In short, the audit trail is thin, the data‑flow is opaque, and the risk of accidental data exfiltration or unauthorized DML is high.

SOC 2 expects concrete artifacts: a reliable access log that ties every action to an individual identity, evidence of pre‑execution approvals for high‑risk operations, immutable records of the exact query and response, and proof that any protected data was masked before it left the system. Those artifacts must be generated at the point where the request crosses the boundary between the user (or AI agent) and the data store.

Introducing a strong identity layer, OIDC‑backed service accounts, least‑privilege IAM roles, or short‑lived tokens, solves the "who" problem but does not automatically give you the audit and control plane you need. The request still travels straight to BigQuery, bypassing any gate that could enforce masking, block dangerous commands, or require a human sign‑off. Without a gateway in the data path, the only evidence you have is the downstream BigQuery audit log, which does not capture the decision‑making steps that SOC 2 auditors look for.

That is where hoop.dev fits. hoop.dev is a Layer 7 identity‑aware proxy that sits between the AI coding agent and BigQuery. The gateway authenticates the agent via OIDC, checks the user’s group membership, and then applies a policy engine on every query before it reaches the database. Because the gateway is the only point of egress, hoop.dev can:

• Record each session, including the exact SQL text, the identity that issued it, and a timestamp.
• Mask columns that contain personally identifiable information or other regulated fields, ensuring the agent never sees raw values.
• Require just‑in‑time (JIT) approval for queries that modify schema, write to protected tables, or exceed a cost threshold.
• Block commands that match a deny list, such as dropping tables or exporting data, before they execute.
• Store an audit trail that can be exported for SOC 2 evidence collection.

Each of those outcomes is produced by hoop.dev, not by the underlying BigQuery service or the AI agent’s token. If you removed hoop.dev while keeping the same OIDC configuration, none of the session recordings, masking, or approval records would exist.

Artifacts that satisfy SOC 2 requirements

Access request log. hoop.dev writes a line for every query that includes the principal’s email, the client IP, and the requested resource. Auditors can trace any data‑access event back to a specific AI‑generated request.

Approval workflow evidence. When a policy demands human sign‑off, hoop.dev creates an approval record that captures who approved, when, and why. The approval record is stored alongside the query log, providing a complete decision trail.

Session replay. The gateway captures the full request‑response exchange. A reviewer can replay the session to see exactly what the AI agent saw, which is essential for demonstrating that protected data never left the environment unmasked.

Data‑masking audit. For every column that hoop.dev masks, an audit entry notes the column name, the masking rule applied, and the original data type. This proves that the system enforced data‑privacy controls at runtime.

Audit store. All logs are written to a dedicated audit store that the gateway controls. The store is separate from the AI agent and the downstream BigQuery service, supporting the non‑repudiation aspect of SOC 2.

How to get started

Deploy the gateway using the Docker‑Compose quick‑start, configure a BigQuery connection with the service account that the AI coding agent will use, and define policies that match your organization’s risk appetite. The getting‑started guide walks you through the deployment steps, while the learn section explains policy syntax, masking rules, and approval workflow configuration.

FAQ

Q: How does hoop.dev record a session for an AI agent?
A: The gateway intercepts the SQL payload, writes the request and the masked response to its audit store, and tags the entry with the agent’s identity. The recorded stream can be replayed in a secure viewer.

Q: Do I still need BigQuery’s native audit logs?
A: BigQuery logs are useful for operational monitoring, but they do not contain the approval or masking evidence that SOC 2 auditors require. hoop.dev complements native logs with the missing control‑plane artifacts.

Q: Can I keep my existing IAM roles for the service account?
A: Yes. hoop.dev stores the credentials for the service account and presents them to BigQuery on behalf of the AI agent. The IAM role should follow the principle of least privilege; hoop.dev then adds the runtime guardrails on top of that baseline.

By placing enforcement in the data path, hoop.dev turns every AI‑driven query into a fully auditable, policy‑controlled transaction. The resulting artifacts, session logs, approval records, masked data evidence, are exactly what a SOC 2 audit expects.

Ready to see the code? Explore the open‑source repository on GitHub and start building a SOC 2‑ready pipeline for your AI coding agents today.