Policy-Driven Query-Level Data Access

Diving deeper into

Zachary Friedman, associate director of product management at Immuta, on security in the modern data stack

Interview
Organizations need a single copy of the data while accommodating the growing demand for self-service interactive queries.
Analyzed 3 sources

The strategic point is that access control has to move from the dataset level to the query result level. In a modern warehouse, hundreds or thousands of employees want to hit the same Snowflake or Databricks tables directly, and each person should see a different slice of rows or masked columns. Creating separate copies for every role turns one analytics system into a maze of duplicates, stale data, and compliance headaches.

  • Immuta is built as a policy engine on top of cloud data platforms. A company connects its identity system, like Okta, to Snowflake, Databricks, BigQuery, Redshift, or Starburst, then writes business rules once. The platform translates those rules into row and column level controls across the underlying systems.
  • This is different from tools like BigID, which start by scanning many systems to find and classify sensitive data. BigID helps answer where the PII is and what kind of data it is. Immuta’s core job is deciding what a given analyst can actually see when running a live query.
  • The old workaround was to make safe copies, analyst copy, finance copy, partner copy, and so on. That breaks down as self serve analytics spreads because every new team or tenant creates another branch of data to maintain, audit, delete, and keep in sync for rules like GDPR and internal entitlements.

This heads toward a world where the warehouse becomes the single live source of truth, and security sits in the path of every query instead of in downstream copies. The winners will be the platforms that let more people ask questions against core data without forcing central teams to rebuild permissions and duplicate tables every time access rules change.