TL;DR: The governance gap is not enforcement alone, but policy drift, hidden grantee lists, and scattered evidence across datasets, according to PlainID, whose Google BigQuery support discovers native Row Access Policies and Policy Tags across datasets and centralises them into one view, giving teams a single place to audit row and column access for applications, analysts, and AI agents.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should teams govern BigQuery row and column controls across many datasets?
A: Start by treating native dataset policies as the authoritative control source, then build a consolidated inventory of Row Access Policies, Policy Tags, and Data Policies.
Q: Why do native data controls still create risk when they are enforced inside the platform?
A: Native enforcement reduces the chance of bypass, but it does not eliminate policy drift, stale principals, or mismatched sensitivity tags.
Q: How can security teams tell whether BigQuery policies are actually working?
A: Look for consistency between the live filter expression, the masking rule, and the principal list across all datasets.
Practitioner guidance
- Inventory native BigQuery policies across all datasets Map Row Access Policies, Policy Tags, and Data Policies to each dataset, then compare live state with the intended access model.
- Validate policy drift against compliance evidence Check whether the documented rule still matches the live filter expression, masking rule, and principal list.
- Align AI retrieval paths to native data enforcement Confirm that retrieval-augmented workflows only consume data after BigQuery has applied the row and column rules.
What's in the full announcement
PlainID’s full article covers the operational detail this post intentionally leaves for the source:
- How the Google BigQuery Authorizer discovers row policies, policy tags, and masking rules across connected datasets.
- What the native control view shows for who is covered, what is filtered, and what is masked.
- How the integration supports distributed deployment across applications, APIs, data platforms, and agentic development platforms.
- Where the platform positions centralized authorization management relative to BigQuery’s internal policy engines.
👉 Read PlainID’s article on BigQuery native control discovery for agentic AI →
BigQuery row and column controls: what IAM teams need now?
Explore further
Centralised visibility is now the control plane problem, not just the reporting problem. BigQuery already exposes the enforcement primitives, but distributed dataset ownership makes it difficult to prove what is live, where it applies, and whether policy intent still matches policy state. That is a governance failure in its own right, because auditors and security teams cannot rely on controls they cannot consistently reconstruct. The implication is that data access assurance must span the platform, not only individual datasets.
A few things that frame the scale:
- 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: What should organisations do before connecting AI agents to sensitive BigQuery data?
A: Confirm that row and column restrictions are enforced before retrieval, not after the model has already seen the data. The agent should inherit the platform’s native limits, and the security team should verify that no alternate path can bypass those controls.
👉 Read our full editorial: BigQuery native controls need central governance for agentic AI