NIST for non-human identities: governing machine access end to end (on BigQuery)

How can you prove to an auditor that your service accounts accessing BigQuery are following NIST guidelines?

Most organizations treat non‑human identities like any other credential: they store a long‑lived service‑account key in a repository, a CI pipeline pulls the key, and the job connects directly to BigQuery. The connection bypasses any central enforcement point, and the only trace left is the occasional Cloud‑audit log entry that shows a project‑level API call. Teams lack per‑query visibility, lack a record of which automated process issued the request, and lack a way to mask or redact sensitive result fields before they land in downstream storage.

This reality violates several NIST SP 800‑53 controls. AC‑2 requires account management and periodic review; AU‑6 demands audit review, analysis, and reporting; and SC‑7 calls for boundary protection and monitoring. When a machine identity queries data without a gatekeeper, the organization cannot demonstrate that it enforces least‑privilege, that it reviews each access, or that it protects data in transit and at rest from accidental exposure.

Moving to a token‑based model for non‑human identities is a step forward. By federating service accounts to an OIDC provider, each automated workload receives a short‑lived token that encodes its group membership and intended purpose. You can scope the token to a specific BigQuery dataset, and the token expires after a few minutes. However, the request still travels straight from the workload to BigQuery. The data path remains open, meaning teams still lack a place to enforce query‑level policies, lack a central log of every statement, and lack inline masking of personally identifiable information. Consequently, the organization cannot provide an auditor with concrete evidence that it reviews, approves, and records each machine‑initiated query.

hoop.dev sits in the data path as an identity‑aware proxy for BigQuery. It receives the OIDC token, validates the identity, and then forwards the request to BigQuery on behalf of the workload. Because the gateway is the only point where traffic to the database passes, hoop.dev can apply just‑in‑time approvals, block disallowed statements, mask sensitive result columns, and record the full session for replay.

Why nist compliance matters for machine identities

NIST standards explicitly require auditability and least‑privilege enforcement for all identities, human or not. Control AC‑2 requires organizations to uniquely identify each account and review its permissions regularly. Control AU‑6 expects organizations to log, retain, and analyze every security‑relevant event. Control SC‑7 mandates that the organization monitor and control communications at the boundary of its information system. When non‑human identities bypass a boundary, none of these controls can be satisfied.

Setup: defining who can start a request

You register service accounts with an OIDC provider, and you grant each account a minimal set of scopes that map to a specific BigQuery dataset. The identity provider supplies a signed token that hoop.dev can verify. This step decides who may initiate a connection, but it does not enforce what the connection can do once it reaches BigQuery.

The data path: where enforcement lives

You force all traffic to BigQuery through the hoop.dev gateway. The gateway acts as a Layer 7 proxy, inspecting the SQL protocol before it reaches the database. Because the gateway is the sole conduit, it can enforce policy in real time. This location gives the organization a reliable place to block, approve, or transform a query.

Enforcement outcomes generated by hoop.dev

• Session recording – hoop.dev captures each request, response, and timestamp, creating a replayable audit trail.
• Inline masking – hoop.dev redacts sensitive columns such as SSN or credit‑card numbers before returning the result to the caller.
• Just‑in‑time approval – hoop.dev routes high‑risk queries, for example full‑table scans on production data, to a human approver before execution.
• Command blocking – hoop.dev automatically rejects disallowed statements like DROP DATABASE.

Each outcome provides an artifact that satisfies a specific NIST control. The recorded session satisfies AU‑6; the masking satisfies SC‑7’s data‑in‑transit protection; the JIT approval satisfies AC‑2’s review requirement; and the command blocking satisfies SC‑7’s boundary protection.

How the generated evidence maps to NIST controls

Auditors look for concrete records that demonstrate compliance. hoop.dev provides:

1. A log entry for every query, including the identity that issued it, the exact SQL statement, and the masked result set.
2. An approval record that shows who authorized a high‑risk operation, when, and why.
3. A policy‑violation report that lists any blocked commands and the rule that triggered the block.

You can export these artifacts to the organization’s SIEM or retain them according to your retention policy, giving auditors a clear, query‑level view of machine activity that aligns with NIST requirements.

Getting started with hoop.dev for BigQuery

To implement this architecture, begin by deploying the gateway using the official getting‑started guide. The documentation walks you through configuring an OIDC client, registering a BigQuery connection, and defining the policies that enforce masking and approvals. You can find detailed policy examples and deployment patterns in the learning hub.

Getting started with hoop.dev provides step‑by‑step instructions for a quick deployment. For deeper policy design, refer to the hoop.dev learning center, which covers best practices for audit logging, JIT approvals, and data masking.

FAQ

Does hoop.dev replace BigQuery IAM?

No. BigQuery IAM continues to control which service account can access which dataset. hoop.dev adds a transparent proxy layer that enforces additional runtime policies and records evidence.

Where are the session logs stored?

hoop.dev writes logs to a configurable backend such as a SIEM connector or a storage service you choose. You define the retention period, and auditors can query the logs without exposing raw credentials.

Can existing service accounts be used?

Yes. You can federate existing service accounts to the OIDC provider, and hoop.dev will use its own credential to connect to BigQuery on their behalf, ensuring the workload never sees the database password.

Ready to see the code and contribute? Explore the hoop.dev repository on GitHub.