# Data Row-Level Security and Policy Tags
Status: public
Confidence: medium (0.725) (verified)
Last verified: 2026-06-02
Generation: ai_structured


## TL;DR

Row-level security and policy tags define which data an agent is allowed to see, not just which table it can query.

## Core Explanation

Data agents need permission evidence at row and column level. A table grant can still hide sensitive rows through policies or mask columns through tags and access rules. Query answers are only safe if the agent knows which identity and policy context produced them.

For RAG and analytics agents, row-level security must carry into extracts, vector indexes, semantic layers, and cached results. Otherwise an answer can leak data that the warehouse would have filtered.

## Source-Mapped Facts

- PostgreSQL documentation describes row security policies as controls that restrict which rows can be returned, inserted, updated, or deleted. ([source](https://www.postgresql.org/docs/current/ddl-rowsecurity.html))
- BigQuery documentation describes row-level security as allowing access control to subsets of data in the same table. ([source](https://cloud.google.com/bigquery/docs/row-level-security-intro))
- Snowflake documentation describes row access policies as schema-level objects that determine whether rows are visible in query results. ([source](https://docs.snowflake.com/en/user-guide/security-row-intro))

## Further Reading

- [PostgreSQL Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
- [BigQuery Row-Level Security](https://cloud.google.com/bigquery/docs/row-level-security-intro)
- [Snowflake Row Access Policies](https://docs.snowflake.com/en/user-guide/security-row-intro)