Audit logging for MCP servers on BigQuery

How can you prove that every query run against BigQuery from an AI‑driven MCP server is accounted for with reliable audit logging?

Most teams treat BigQuery as a data lake that engineers reach with a shared Google service‑account key. The key lives in a CI/CD secret store, is checked into scripts, and is handed to any process that needs to run a query. Because the same credential is used by dozens of pipelines, there is no built‑in way to know which user, which job, or which automated agent issued a particular SELECT or INSERT. The result is a blind spot: compliance checks cannot answer who read a sensitive column, and incident responders cannot trace the exact command that caused a data leak.

What organizations really need is comprehensive audit logging for every request that touches BigQuery. The goal is to capture the full query text, the identity that initiated it, and the timestamp, while still allowing the MCP server to talk directly to the BigQuery endpoint. In the current state, even if you enable BigQuery’s native audit logs, those logs are tied to the service‑account identity, not to the individual engineer or AI workflow that triggered the request. The request still reaches the target without a gate that can attach per‑user context or enforce additional policies.

To close that gap, the enforcement point must sit on the data path, not in the identity provider or in the downstream service. A gateway that proxies the connection can read the OIDC token, map it to a role, and then forward the request using the stored service‑account credential. Because the gateway is the only place the traffic passes, it can inject audit metadata, enforce query‑level policies, and write a log entry for every interaction.

hoop.dev provides exactly that data‑path gateway for BigQuery. It runs a lightweight agent inside the network that holds the Google service‑account credential. Users and AI agents authenticate to hoop.dev with OIDC or SAML, so the gateway knows the true caller before it forwards the request. Once the connection is established, hoop.dev records the full query payload, tags it with the caller’s identity, and stores the record in an audit log store. Because hoop.dev is the only component that sees the query before it hits BigQuery, the audit logging is guaranteed to be complete and accurate.

Why the data path matters for audit logging

Setup steps such as configuring OIDC providers, assigning IAM roles, or federating Google identities decide who may start a session. Those steps are essential, but they do not enforce any policy on their own. The gateway, hoop.dev, acts as the sole enforcement layer. By sitting between the caller and BigQuery, it can:

• Capture every SQL statement, including ad‑hoc queries generated by an LLM.
• Attach the exact user or service account that originated the request, derived from the verified OIDC token.
• Store the log entry in a format that auditors can query without needing access to the underlying BigQuery project.
• Provide replay capability so a security analyst can reconstruct the exact session that led to a data exposure.

Without hoop.dev in the data path, the same audit logging requirement would rely on downstream logging that cannot be tied to individual identities, leaving a compliance gap.

How hoop.dev integrates with BigQuery

The integration follows a simple three‑stage flow:

1. Identity verification. A user or AI agent presents an OIDC token to hoop.dev. The gateway validates the token against the configured IdP and extracts group membership or custom claims that drive authorization.
2. Credential handling. hoop.dev’s agent holds the Google service‑account key. The caller never sees the key, eliminating credential sprawl.
3. Query forwarding and logging. The request is proxied to BigQuery over the native protocol. Before forwarding, hoop.dev records the query text, caller ID, and timestamp, then writes the entry to the audit log store.

This design satisfies the precondition of wanting audit logging while still allowing the MCP server to communicate directly with BigQuery. All policy enforcement, capturing the query, associating it with an identity, and persisting the log, happens inside hoop.dev, the only point where the traffic can be inspected.

Benefits for compliance and incident response

Because hoop.dev generates a complete audit trail, organizations can meet internal governance requirements and external audit demands without building custom logging pipelines. The audit logs are searchable by user, time range, or query pattern, making it easy to answer questions such as “Who accessed column X on 2024‑12‑01?” or “What queries were issued by the LLM during the last deployment?”. In a breach scenario, the recorded session can be replayed to understand exactly what data was read or modified, dramatically shortening investigation time.

Additionally, hoop.dev’s architecture isolates credential exposure. The service‑account key never leaves the agent, and the gateway can be hardened with network policies, reducing the blast radius of a compromised client.

Getting started

To add audit logging for your MCP servers, start with the official getting‑started guide, which walks you through deploying the gateway, configuring OIDC, and registering a BigQuery connection. Detailed feature explanations are available in the learn section.

Getting started with hoop.dev

Learn more about audit logging and other features

FAQ

Does hoop.dev alter the query before it reaches BigQuery?
No. hoop.dev forwards the original SQL unchanged; it only records metadata and enforces policies defined by the administrator.

Can I retain the native BigQuery audit logs in addition to hoop.dev’s logs?
Yes. hoop.dev’s logs are complementary and provide per‑user context that native logs lack.

Is the audit log protected against undetected changes?
The logs are written to a storage backend configured by the operator, allowing any changes to be detected during review.

Ready to explore the code? View the open‑source repository on GitHub.