A Row Access Policy limits which rows a principal can see when querying a dataset. In BigQuery, it is enforced at query time, so the policy applies to every consumer of the data, including analysts, applications, and AI agents that reach the table directly.
Expanded Definition
A Row Access Policy is a query-time control that limits which rows a principal can read from a dataset, rather than restricting access to the table as a whole. In cloud analytics platforms such as BigQuery, it is evaluated every time data is queried, which means the policy applies consistently across analysts, applications, and AI agents that connect directly to the table.
That makes row-level enforcement different from coarse dataset permissions or column masking. Row Access Policies are usually paired with identity-aware design so that the rule can resolve users, groups, service accounts, or workload identities correctly. The security value is strongest when the policy logic reflects business context, such as region, tenant, customer assignment, or case ownership. Guidance varies across vendors on how much policy complexity should live in SQL versus external identity attributes, so implementation choices should be reviewed carefully. For a standards-oriented view of access governance, see the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a Row Access Policy as if it were a substitute for identity governance, which occurs when broad table access is granted first and row filtering is expected to compensate afterward.
Examples and Use Cases
Implementing Row Access Policies rigorously often introduces query-design and administration overhead, requiring organisations to weigh fine-grained data sharing against policy complexity and test coverage.
- A multinational sales team queries one customer table, but each rep only sees accounts assigned to their territory.
- A healthcare analytics application returns only the patient records allowed under a user’s care team or care location.
- An internal BI tool enforces tenant isolation so each business unit can query the same shared dataset without seeing other tenants’ rows.
- An AI agent running on top of warehouse data is constrained to the same row filters as the human user or service account that invoked it.
- Policy owners validate logic against identity sources and audit findings using the Ultimate Guide to NHIs and the NIST SP 800-53 Rev 5 Security and Privacy Controls.
Row filters are also useful in incident response and delegated operations, where a support team needs selective visibility without full-table access. In practice, organisations often compare the policy design with lessons from Top 10 NHI Issues before extending access to automation.
Why It Matters in NHI Security
Row Access Policies matter because NHI-driven access often bypasses the human review patterns that traditional data governance assumes. A service account, pipeline, or AI agent can query sensitive tables at machine speed, so row filtering becomes a direct control on how much data an NHI can exfiltrate or accidentally expose. NHIMG research shows that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which makes coarse access controls especially risky when datasets are shared broadly.
When row-level enforcement is missing or misconfigured, the result is not just overexposure. It can create silent leakage across tenants, regions, or customer segments, especially when downstream tools cache results or reuse credentials. That is why row policies should be governed alongside identity lifecycle, secrets management, and auditability rather than treated as a reporting feature. The operational lesson aligns with Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
Organisations typically encounter the need for Row Access Policies only after a shared dataset, service account, or AI agent has already exposed data outside its intended boundary, at which point row-level containment becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Row-level filtering limits what an NHI can retrieve from shared datasets. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should enforce least privilege at the data row level. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement controls govern which records a subject may read. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires policy decisions to follow the request, including data queries. |
| NIST SP 800-63 | Identity assurance influences whether a principal should receive row-scoped access. |
Map query access to least-privilege rules and review row filters as part of access governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
