BigQuery access governance — every statement reviewed before it runs

How AccessFlow connects

It is an engine plugin rather than an in-process JDBC datasource: a standalone shaded JAR, pinned in the connector catalog by URL and SHA-256, downloaded on first use, hash-verified, and loaded into an isolated classloader. If the hash does not match, it does not load. In an air-gapped install the JAR can be pre-seeded into the driver cache and the runtime told never to reach the network.

There is no host or port. The database name field holds the GCP project id, optionally as project.dataset to pin a default dataset — project and dataset ids cannot contain dots, so that split is unambiguous. The stored credential is the service-account key JSON, AES-256-GCM encrypted at rest and decrypted only when the client is constructed.

A custom endpoint can be supplied to point the client at an emulator, in which case it runs without credentials. One cheap client stub is cached per datasource and dropped whenever the datasource configuration changes or is deactivated.

What AccessFlow understands

The GoogleSQL tokenizer understands both string quote styles, triple-quoted strings, and backtick identifiers — including a single backtick spanning a full project.dataset.table path. It accepts SELECT, INSERT, UPDATE, DELETE, MERGE and table, view and schema DDL including TRUNCATE.

Operations map onto the same query types the SQL engines use, so the per-user read, write and DDL capabilities, the routing-policy engine and the multi-stage approval chains apply completely unchanged.

What it refuses

Rejected with HTTP 422: scripting in all its forms (BEGIN, DECLARE, CALL, EXECUTE IMMEDIATE, IF, LOOP, WHILE), EXPORT DATA and LOAD DATA, ASSERT, GRANT and REVOKE, and procedure, function, index and model DDL.

Multi-statement input is refused, as are user-supplied ? and @name parameter markers — the rewriter owns the parameter slots, so a statement may not arrive with its own.

Row-level security and masking

Policies are ANDed into the WHERE clause and bound as positional query parameters on the job configuration. The same shapes that fail closed on Snowflake fail closed here, an INSERT into a policied table is rejected, and a deny-all short-circuits without an API call.

Masking recurses by dot-path through RECORD fields, so a rule on user.email redacts that nested leaf while the rest of the record stays visible; a whole-column rule collapses maps and lists entirely.

What the rewrite actually does

A policy restricting orders to the caller's region narrows the statement before the job is submitted — and therefore before any bytes are scanned:

-- submitted
SELECT id, email FROM orders WHERE status = 'OPEN';

-- executed (row-security policy: orders.region = the caller's region)
SELECT id, email FROM orders WHERE (status = 'OPEN') AND orders.region = ?;
--                                                                       ^ bound, never concatenated

The value is bound as a positional query parameter on the job configuration. A deny-all short-circuits without an API call, so a misconfigured policy scans nothing and bills nothing.

Dry-run and the scan-byte estimate

BigQuery has a real dry-run of its own: AccessFlow submits the governed statement as a job with the dry-run flag set, so Google validates it and reports the bytes it would process without running it. That figure becomes the estimated scan size a reviewer sees before approving — the direct cost signal for a bytes-billed warehouse.

Introspection lists datasets (or only the pinned default dataset), then tables and their schemas, flattening RECORD fields to dot-path columns. BigQuery has no primary keys, so none are reported.