Row-Level and Column-Level Security in Cloud Data Warehouses

Row-level and column-level security in cloud data warehouses are about controlling who can see which data. The hard part is making those controls hold through every door, including BI tools, APIs, embedded analytics, and AI agents. A well-written table policy is the starting point. It works only when every query reaches the right enforcement point with the right identity and context.

Why RLS and CLS exist at the warehouse layer, and what they actually do

Row-level security, or RLS, limits the records a user can retrieve based on their identity and attributes. A regional sales manager might see only their region’s sales, while a CFO sees every region. Column-level security, or CLS, masks or blocks particular fields, including government-issued identification numbers, credit card numbers, and salary figures. Access to a table does not grant access to everything inside it. The two controls work together, narrowing both the records returned and the details visible within those records.

The table is the right place to start. When restrictions live only in an application, another application can reach the same data without applying them. Attaching policy to the table puts the warehouse in charge, so queries from different tools pass through the same gate. That is the design intent, but customers still have to configure the gate correctly. The vendor secures the infrastructure, while the customer configures and maintains access policies. Snowflake’s SEC 10-Q said customer accounts had been accessed because customers had not set up MFA and network access policies. That is a separate control from RLS or CLS, but it makes the responsibility clear. Available safeguards do not configure themselves.

How RLS and CLS are implemented across the major cloud warehouses

Microsoft Fabric Warehouse implements RLS through predicate-based security policies, using the same model as SQL Server. A predicate is a function bound to a table through a security policy, and a SELECT against that table passes through its filter. Column controls work through GRANT and DENY permissions on specific columns. A user can have GRANT SELECT on columns they are allowed to read and DENY SELECT on restricted fields. The distinction is visible in the query result. A SELECT * request produces column-level permission errors for restricted fields.

Fabric also illustrates the boundary of SQL-layer protection. Its warehouse column policy does not automatically extend to the underlying Parquet files, so someone with file-layer access can preview raw storage without that policy applying. Storage access therefore needs separate protection. Snowflake’s IS_AGENT_ACTIVATED function, introduced in 2026, addresses a different boundary by letting row access and masking policies branch when an agent is active in the execution context. This works with Cortex Agents, protocol-connected agents, and other agentic contexts. A human analyst can be allowed to see a full record while an agent receives only data designated safe for AI processing.

Across platforms, maintainability depends on how permissions are organized. Centralized Access Control Lists, or ACLs, can map groups to business attributes such as regions or sensitivity tiers. Reporting-layer views then apply those mappings without duplicating rules in every report. Groups are the useful unit of administration here. They let access follow a team’s business responsibilities rather than a growing collection of individual exceptions.

Why enforcing rules in one query path is not the same as enforcing them everywhere

A dashboard proves only what happens through that dashboard. Warehouse permissions configured for human analysts using approved BI tools may not account for APIs, embedded products, or agents added later. Each surface has its own choices about how to connect and which credentials to use. The warehouse can apply its policy correctly while returning data the person behind the request should not see. That happens when the policy evaluates the connection’s permissions.

Power BI, Tableau, and Looker can connect using a service account’s identity. If that account has broad access, an identity-based row filter can return all rows available to the account. Embedded analytics adds a tenant boundary to the same problem, so teams often have to keep tenant filters up to date for each surface. Direct API and JDBC connections may bypass the BI layer entirely and use privileged roles for which masking does not apply. An agent that uses a shared account has another way to reach data through those same broad permissions.

The platforms provide enforcement mechanisms, but the organization decides which paths reach them and which identities those paths present. At the file-access boundary described above, the request never goes through the SQL policy at all. Treating a new surface as just another interface keeps the old assumptions in place even as it opens a new door and changes the security model.

How service account permissions and identity passthrough determine whether the policy actually fires

The decisive identity is the one the warehouse receives. RLS and CLS evaluate session context at query time, including the user, role, and caller type. A service account with broad permissions passes those permissions into the session context. The policy may still execute, but it answers the wrong access question. It determines what the service account may retrieve.

The first defense is least privilege for service accounts. A BI service account should have only the permissions available to the tool’s most restricted user, rather than the maximum access needed by anyone using it. That constrains exposure, but it cannot express every user’s different entitlement through one shared identity. Identity passthrough addresses that problem by forwarding the authenticated end user’s identity from the BI tool or API to the warehouse. Permissions can then be evaluated at query time against the actual user.

When several workloads share an account, revoking it disrupts every downstream system that depends on it. Per-workload credentials provide a safer boundary for that operation. For agents acting on someone’s behalf, the workload boundary alone is not enough. The user’s identity must also reach the warehouse for the agent to receive the user’s permitted view.

What changes when AI agents become query callers alongside human analysts

Correct identity does not make an agent a human analyst. Agents lack institutional memory about what a vague column means, and a stale or partial answer can look as confident as a correct one. They also query programmatically and continuously. A permission error can therefore become a sustained, high-volume exposure. SQL text alone gives audit logs too little context to make those requests intelligible.

The context can change after retrieval, too. In a multi-agent architecture, a CRM record may move through a customer service agent, a pricing system, and a fraud workflow. Rules written for a human reading that record in the CRM may not anticipate those later uses. An agent allowed to change data needs stricter governance for those actions than for reading it.

Snowflake’s agent-aware function lets policies tell an agent query apart from the same user querying interactively, so limits on what data is exposed do not depend on application instructions. Databricks’ cross-engine ABAC beta in 2026 addresses enforcement across query engines. It applies row filters and column masks at server-side scan planning through Iceberg REST APIs, so the controls hold no matter which agent framework or query engine sends the request.

Why the semantic layer is governance infrastructure, not just a convenience for analysts

An agent can receive exactly the rows and columns it is allowed to read and still give the wrong answer. Without defined business logic, it must infer meaning from raw table and column names. Terms such as “gross margin,” “active customers,” and “revenue” can mean different things to marketing, finance, and product. Correct permissions do not resolve those differences.

Forrester’s June 2026 report Make Data AI Ready Via Semantic Layer Platforms said the next-generation semantic layer is a control plane. In plain terms, that is a governed foundation for metric definitions, calculations, and access policies delivered consistently to BI tools, data products, and agents. Its role goes beyond saving analysts some SQL. When definitions are applied at query time and queries go through a single defined interface, consumers get governed answers instead of raw results they have to make sense of on their own. The same interface also makes those interactions auditable.

The semantic layer must account for combinations as well. Joining a customer table with a transaction table may reveal sensitive information even when each table passes its column-level policy on its own. A layer that understands those joins can address what source-by-source checks miss. This supplements RLS and CLS with the meaning and context of combined data that table permissions alone cannot give, and carries access controls beyond the warehouse boundary to the answer being served.

How data products and marketplaces change what "enforced access" must mean

Making data into a product adds another trust boundary. A consumer needs the access policy to hold for every downstream query as well as when a team first prepares the dataset. That requirement separates a governed marketplace from a catalog. A catalog inventories metadata, while a marketplace makes data products discoverable, evaluable, and directly consumable.

Alation’s Data Products Marketplace was announced in March 2025 and was generally available in Q3 2025. It provides a centralized hub where teams use a no-code interface to publish certified, AI-ready data products that business users and AI systems can discover and access. Certification is useful, but it is not an enforcement mechanism. For that promise to hold, the product’s access rules must stay in place when it is packaged and shared. Snowflake Marketplace providers have also built large businesses in governed, live-query data sharing, so more is at stake when those rules must hold beyond the team that first set them.

The advantage is therefore not simply having more datasets. It is making trusted products easy to discover, access, govern, and use. For multi-tenant products, that promise is hard to keep when every surface has to keep its own tenant filter mapping up to date. Each additional surface creates another place for permissions to diverge. Centralized data-layer policy, evaluated at query time under the actual consumer’s identity, is the scalable approach because the entitlement does not have to be recreated wherever the product appears.

What a policy architecture that holds across every query path actually requires

A durable architecture has to connect these controls. Table-level enforcement must remain the foundation, the actual user’s identity must pass through every query surface, and agent contexts must be distinguished where tighter restrictions are required. Those mechanisms perform different jobs. Identity passthrough establishes whose permissions apply, while caller-aware policy narrows the result when the way that authority is being used requires it. Storage permissions must close routes that bypass SQL enforcement entirely.

The serving layer must also make decisions inspectable and current. Audit logs need identity, intent, and lineage together, so a request can be understood as a human query, an agent action, or an embedded product interaction. Freshness is part of that requirement. A cached or static export suitable for a weekly dashboard may already be stale for an agent making a real-time decision, so policy must be evaluated against live data at runtime. A shared semantic interface supplies table descriptions, metric definitions, relationships, and access policies to downstream consumers without rebuilding that context in each application.

The practical test is blunt. If a restriction holds in the dashboard but fails in an agent query, the architecture has failed. The goal is to pass a compliance audit and close every door except the governed one.