You're on Satori: Satori Decides What Each Person Sees at Query Time. Data Workers Owns Whether What They See Is Right

Your warehouse access runs through Satori. Tables and schemas are grouped into datasets. People get access through access rules, self-service or approved requests, and just-in-time access hands out temporary, policy-driven permissions "without manual ticketing workflows". Satori can revoke permissions that go unused. Dynamic masking applies by identity, role and attribute, and row-level security means each region's team sees only its own rows. On Snowflake, Satori's native integration creates the dataset roles and pushes the masking and row-level policies into Snowflake, recreating them on its next enforcement cycle if a CREATE OR REPLACE drops them. Database activity monitoring keeps the record of who queried what. Since Aug 28, 2025, Satori has been part of Commvault, which sells it as Commvault Data & AI Access Governance. Satori decides what each person sees at query time. Data Workers owns whether the data behind that access is right, and proposes the access changes a fix needs to their owners, behind approvals.

Key takeaways

• •Satori keeps its job. Datasets, just-in-time access, masking, row-level security, activity monitoring and AI access governance stay in Satori.
• •Data Workers connects to Satori over its API today and changes nothing in it. When a fix needs a policy change, Data Workers drafts it for the Satori admin, who applies it.
• •Correct access can still hide the wrong data. A row filter or a revoked permission can make a pipeline read less than it should while every test passes. Data Workers watches the baselines your pipelines record and traces a gap to its cause.
• •Each owner approves their own part. The Satori change goes to its admin, dbt changes arrive as diffs, and reruns are queued after approval, with one receipt per change.
• •Your data stays in your systems. Data Workers' agents run in your infrastructure under the warehouse role you give them, so Satori's policies decide what they see too.

Satori decides what each person sees at query time. Data Workers owns whether what they see is right.

Satori answers one question very well: should this identity see this row and this value, right now? Data Workers answers the questions that come next. Is the data behind that answer complete? Did an access change make a pipeline read less than it should? Who changes what, where, to put it right?

Here's a Tuesday at a sporting-goods retailer that sells in North America, Europe and Asia-Pacific. An Airflow 2 loader task lands storefront orders in Snowflake raw_shop.orders every hour. At 02:00 the dbt_daily DAG runs dbt Core, which builds fct_orders as an incremental model with a three-day lookback, then mart_revenue_daily and mart_demand_daily. At 05:30 a second DAG, replenishment_daily, reads the demand mart and posts reorder quantities to NetSuite. Power BI's Revenue Daily semantic model refreshes at 07:00. Satori governs Snowflake natively; its Orders dataset covers raw_shop and core. After every run, the pipeline records two numbers with monitor_metrics: rows landed in raw_shop.orders and rows merged into fct_orders. The team keeps approved notes in the Context Wizard graph: which Satori policies apply to the Orders dataset, and that the Power BI model and the replenishment DAG read the marts. Approval requests reach owners in Slack. This is an illustrative example.

Satori did exactly what it was told: a user outside every group saw nothing, as its default said. Grants in Snowflake follow roles, this exception followed a user name, and the migration that moved dbt to a new user was correct for one and invisible to the other. The cause was in GitHub, the policy in Satori, the symptom in Snowflake and the stakes in NetSuite and Power BI. Each owner approved their own part, and the receipt holds the whole story.

Why doesn't Satori just do this itself?

Because Satori is built to sit between identities and data and decide, consistently, at query time. That focus is why it works. Policies apply the same way whether a person, a BI tool or a pipeline is asking, and the native integration restores them when a table is recreated. The AI side follows the same line: Commvault's page governs "sensitive data exposure to AI and LLM-based applications", Satori's OpenAI data store keeps "track of AI activity", and its Microsoft Security Copilot integration lets Copilot query posture data through Satori's APIs. All of it acts on access.

Fixing a data gap is a different product with a different liability: context across Airflow, dbt, Snowflake, Power BI and NetSuite, a baseline for every run, a named owner's approval per change, reruns in order, and proof the numbers came back. An access platform that rewrote pipelines and reran jobs would be changing the data it exists to guard. Data Workers is the product on the other side of that line, and it hands every access decision back to Satori.

Every tool owns a slice. Data Workers covers the whole lifecycle

Satori owns its slice: deciding what each person sees at query time. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the policies you keep in Satori.

How Satori and Data Workers work together

Your people stay where they are: Claude, Cursor or Copilot for questions and code, Satori for access, Power BI for the numbers. Spellbook Data Catalog (in preview) is where the data team looks: each incident, proposed change, blast radius, approver and rollback. Approval requests reach people in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work, and the Autonomous Data-Conductor runs each fix behind per-domain guardrails.

Where Satori fits. Data Workers connects to Satori over its API today, and Satori stays the record for datasets, access rules, just-in-time grants, masking, row-level security and query activity. The team records each policy that shapes a pipeline's reads as an approved note in the Context Wizard graph, and the Satori admin carries a proposed change into Satori. Data Workers reads natively what sits around Satori: Snowflake, PostgreSQL, the dbt manifest, pull requests on GitHub, Airflow, Dagster and Prefect runs, and Okta users and groups, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis.

What Data Workers writes, and where. Nothing in Satori: policies, exceptions, datasets and grants stay with Satori's admins. dbt fixes go to the owner as a diff to merge. Snowflake access changes are proposed for the platform owner. On Databricks, Data Workers applies Unity Catalog grants and revokes only after approval. Masking is always a dry-run proposal that a person approves and applies. When a fix calls for a grant, provision_access records it with its expiry in Data Workers' access-grants ledger, and the owner revokes it when the window closes. Reruns are queued through your orchestrator after approval.

Setup today. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Give the agents a Snowflake role whose Satori policies match what they should see.

// Example: .mcp.json for Claude Code (Data Workers servers, per the client setup docs)
{
  "mcpServers": {
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    },
    "dw-governance": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-governance"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code), then ask: "Which dbt models read the Orders dataset, and which pipeline users do they run as?"

One incident, L0 to L4. Autonomy is set per domain, so orders can sit at a different level from customer data.

• •L0 manual. Engineers find each short run by hand, usually after a dashboard looks wrong.
• •L1 observe. Data Workers reports cause, reach and owners, and logs what each action would have needed.
• •L2 propose. Data Workers drafts the Satori change for the admin, the dbt diff and the rerun. Owners approve before anything runs.
• •L3 act reversibly. For proven classes, such as queuing the rerun once the access fix is in, Data Workers acts and verifies. Code still arrives as diffs.
• •L4 autonomous. For a scoped, trusted class, Data Workers runs the loop end to end and posts the receipt. Satori policy stays with Satori's admins.

Read more on safety, how approvals work, who owns the agents and where your data goes. The same build-on pattern holds for query-time policy in Immuta, ALTR and Privacera. For the runs and reports in this story, see You're on Airflow and You're on Power BI.

What changes for your team

Satori programs rarely struggle to decide who sees what. They struggle at the edges, where a correct policy meets a pipeline nobody told it about: a new service user, a renamed table, a just-in-time grant a scheduled job came to depend on. With Data Workers, the data side of those edges runs on autopilot at the level you set.

• •Incidents. A run that reads governed data and comes back short arrives traced to its change, with every reader and owner named.
• •Data quality. Keys, nulls, row counts and recorded baselines are checked after each run, and failures go to the cause.
• •Cloud spend. Snowflake credits are traced to the dbt model behind them through query tags.
• •Access. A policy change a fix needs arrives drafted for the Satori admin, with the evidence and the reason.
• •Audits. Each fix links the trigger, diff, approvers, rerun and counts; with Satori's activity log, it answers who saw what and why the data changed.
• •Migrations. Each wave is planned with its parity checks, and the owner signs off before it closes.

Security and governance teams keep their week for the calls only they make: what counts as sensitive, which regions see which rows, how long a just-in-time window lasts. The data governance leads guide and Inside the Data Access & Governance Agent cover that work.

Keep Satori, or consolidate?

Keep Satori if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

Satori usually stays the access layer: query-time masking, row-level security, just-in-time access and the activity audit are a security decision with their own owners, now inside a wider Commvault platform. What teams consolidate is the work around it: the spreadsheet that maps policies to the pipelines that read through them, the row-count scripts run after a policy change, and the tickets that bounce between security and data engineering when a policy breaks a job. For the policy side, see column masking policies automation and Snowflake access history. Building the fix layer yourself? Read build it ourselves with Claude Code and MCP servers: calling an API is the easy part; lineage, baselines, approvals, rollback and receipts are the work.

The case for your CFO

The outcome: the numbers behind every governed dataset stay complete, gaps caused by access changes are caught before the morning reports and the reorder run, and every fix lands at its source with proof.

The risk story is plain. Data Workers changes nothing in Satori, applies no masking or row policy and deletes no rows. Code changes land through your Git review, Snowflake access changes go to the platform owner, and Unity Catalog grants change only after a named approver says yes. Each change leaves a receipt with the trigger, diff, approver, checks and undo path. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only.

Why now: residency rules, just-in-time windows and AI applications all mean more policies, more identities and more pipelines reading through them, and every new policy is a chance for a correct rule to starve a job nobody listed. The first win: one governed domain, read-only, with every pipeline that reads through a Satori policy mapped to its owner, its identity and its baseline. What stays the same: your Satori datasets, policies, approvers and audit, and the people who run them. Start with a pilot from the pricing page, credited in full against the first year; for the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "Satori decides what each person sees; Data Workers makes sure what they see is right, and every fix comes with an approval and a receipt."

Getting started

Start with a pilot. Pick the domain where governed data drives money, such as orders or revenue. Connect Data Workers read-only to the dbt project, orchestrator, warehouse and BI behind it, record the Satori policies and pipeline identities that shape each run, and let it watch a few weeks of runs before the first fix class. It's the quickest way to see an agentic data platform next to the access governance you already run. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

Is Satori still a product now that Commvault owns it? Yes. Commvault announced its intent to acquire Satori Cyber on Jul 24, 2025, and closed the acquisition on Aug 28, 2025. Commvault sells it as Data & AI Access Governance, and satoricyber.com and the Satori docs stay live. Data Workers works with it under either name.

Does Data Workers connect to Satori? Data Workers connects to Satori over its API today and doesn't write to it. The team records the policies that shape pipeline reads as approved notes, and the Satori admin applies any change Data Workers proposes.

Will Data Workers grant or revoke just-in-time access for us? No. Just-in-time access, self-service and requests stay in Satori. When a fix needs a grant, Data Workers drafts it for the owner and records its expiry in its access-grants ledger; the owner revokes it. On Databricks, it applies Unity Catalog grants and revokes after approval.

Will Data Workers change our masking or row-level policies? No. A policy change arrives as a proposal with its evidence for the Satori admin, who applies it in Satori. No agent can promote a masking change to run on its own.

What does Data Workers see if Satori masks or filters its queries? What its warehouse role may see: Satori's policies apply to Data Workers like any other identity, so give it a role that sees masked values and full row counts. The hosted Conductor sees workflow metadata only, never rows, credentials or model keys.

How would Data Workers know an access change caused a gap? From the evidence around the run: a baseline your pipeline records (rows landed against rows merged), the orchestrator run, the dbt manifest showing no code change, the team's notes on which policies apply, and its review record of the change that moved the job's identity. It names the policy owner to confirm in Satori's activity log.

Sources

• •Commvault, "Commvault Announces Intent to Acquire Data and AI Security Company Satori Cyber" (Jul 24, 2025), https://www.commvault.com/news/commvault-announces-intent-to-acquire-data-and-ai-security-company-satori-cyber (checked Oct 3, 2026)
• •Commvault, "Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform" (Aug 28, 2025), https://www.commvault.com/blogs/commvault-closes-acquisition-of-satori (checked Oct 3, 2026)
• •Commvault, Data Access Governance for Cloud and AI (just-in-time access, dynamic masking, AI and LLM governance), https://www.commvault.com/solutions/data-and-ai-access-governance (checked Oct 3, 2026)
• •Satori, home page, https://satoricyber.com/ (checked Oct 3, 2026)
• •Satori docs, Datasets (access rules, self-service, requests, time limits, unused revocation), https://satoricyber.com/docs/datasets/ (checked Oct 3, 2026)
• •Satori docs, Dynamic Masking, https://satoricyber.com/docs/dynamic-masking/ (checked Oct 3, 2026)
• •Satori docs, Row-Level Security, https://satoricyber.com/docs/row-level-security/ (checked Oct 3, 2026)
• •Satori docs, Snowflake native integration (dataset roles; policies recreated in the next enforcement cycle after CREATE OR REPLACE), https://satoricyber.com/docs/datastores/snowflake/snowflake-native/ (checked Oct 3, 2026)
• •Satori docs, Data stores overview, https://satoricyber.com/docs/datastores/data-stores-overview/ (checked Oct 3, 2026)
• •Satori docs, OpenAI, https://satoricyber.com/docs/datastores/openai/ (checked Oct 3, 2026)
• •Satori docs, Microsoft Security Copilot integration (Copilot queries posture data through Satori APIs), https://satoricyber.com/docs/integrations/microsoft-security-copilot/ (checked Oct 3, 2026)
• •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
• •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)