You're on Varonis: Varonis Watches Who Touches Your Data. Data Workers Makes Sure the Data Is Right
Running Varonis across Snowflake, Databricks and S3? Keep it watching every permission and every touch. Data Workers keeps the data in your pipelines right and sends each fix to its owner, behind approvals.
Your security team lives in Varonis. The Data Security Platform classifies sensitive data across Microsoft 365, file shares, AWS and your databases, down to the table and column in Snowflake and Databricks. It maps users, roles and data, flags excessive and stale access, and applies dynamic masks. Database activity monitoring, rebuilt on the Cyral acquisition in 2025, captures who queried which data, when and how, with no agents to install. Athena AI lets an analyst ask "which users have accessed our payroll files this week?" in plain language. Varonis Atlas, generally available since May 28, extends the watch to AI, and since August 10 it adds agent intent-based access control. The SlashNext acquisition added email security in 2025. And since September 15, Data Lifecycle Management quarantines redundant, obsolete and stale data automatically, reversibly, deleting nothing until you're sure. Varonis watches who touches your sensitive data. Data Workers owns whether the data in your pipelines is right: it catches the bad data, maps what it feeds, finds the cause and proposes each fix to the person who owns it, behind approvals.
Those jobs meet often: every Varonis action lands on data that pipelines read, from a masked join key to a quarantined file a job loads once a quarter.
Key takeaways
- •Varonis keeps its job. Classification, permission maps, dynamic masks, database activity monitoring, Athena AI, Atlas and lifecycle quarantine stay with your security team. Data Workers works with Varonis from day one.
- •Data Workers owns whether the data is right. It checks nulls and keys after runs, holds per-table row-count baselines, maps what a broken table feeds and names the cause across the warehouse, dbt and the orchestrator.
- •Security changes stay with security. Varonis connects over its API or MCP server today. Anything that touches a Varonis policy, mask or quarantine goes to the security owner as a proposal, with the evidence attached.
- •Fixes go to owners, behind approvals. Reruns are queued through your orchestrator after a named person approves; dbt changes arrive as diffs to merge; grants and masking changes are drafted for their owners.
- •Every fix leaves a receipt with the evidence, approver, checks and undo path.
- •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.
Varonis is the watch on who touches your data. Data Workers is the owner of whether that data is right.
Varonis answers where sensitive data sits, who can reach it and who touched it. Data Workers answers whether a table is right, what it feeds, what changed upstream and who has to fix what.
Here is a quarter close at a B2B software company that pays commissions to reseller partners. The partnerships team keeps the commission tier table as a CSV in s3://finance-ref/commission_tiers/ and uploads a new file before each quarter. A Dagster job, partner_commissions_qclose, runs once a quarter: it loads the file into Snowflake REF.COMMISSION_TIERS, then runs dbt Core to build fct_partner_commissions and mart_partner_payouts. Finance pays partners from the partner_payouts Explore in Looker on the first day of the quarter. The data team keeps a daily row-count baseline for the tier table and a context-graph note linking the payout mart to the Explore. In September the security team turned on Varonis Data Lifecycle Management with a staleness policy for the finance buckets: quarantine objects untouched for 90 days. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Jun 24 | Amazon S3 | The partnerships team uploads tiers_2026q3.csv, 36 tier rows, for the quarter ahead. Nobody opens it again until close |
| Sun Sep 28, 03:00 | Varonis | The staleness policy moves the commission_tiers/ prefix to quarantine. The action is logged and reversible, exactly as designed |
| Wed Oct 1, 01:00 | Dagster | partner_commissions_qclose starts. The load step finds no files and finishes in 3 seconds; last quarter it took 41. The step reports success |
| 01:20 | Snowflake and dbt Core | REF.COMMISSION_TIERS is now empty. dbt builds fct_partner_commissions with a left join to the tiers, so 3,640 partner lines get a null commission_amount. The job ends green |
| 01:25 | Data Workers | The null check in run_quality_check fails on fct_partner_commissions: commission_amount is null on every row. The tier table reads 0 rows, and monitor_metrics flags it against its baseline of 36 |
| 01:28 | Data Workers | blast_radius_analysis from the tier table walks the dbt lineage to fct_partner_commissions, mart_partner_payouts and a partner scorecard model; the context-graph note adds the Looker partner_payouts Explore. Finance exports from it at 11:00 |
| 01:30 | Data Workers | It reads the Dagster run and its step timings, and the dbt manifest shows no model changed since last quarter. Its diagnosis: the load step read nothing, so the cause sits upstream of Snowflake, at the source files |
| 01:32 | Slack | The finding goes to #finance-data with the evidence and three named owners: the platform engineer on call, the dbt model owner and the finance analytics lead, who holds the 11:00 export |
| 08:10 | Amazon S3 | The platform engineer checks the bucket: the prefix is gone. Varonis's audit trail shows the lifecycle quarantine on Sunday at 03:00 |
| 08:30 | Varonis | The security owner reverses the quarantine in Varonis, and the file is back in place |
| 08:35 | Spellbook | Data Workers drafts one change set for three owners: for security, an exclusion of commission_tiers/ from the staleness policy, to apply in Varonis if they agree; for the dbt owner, a diff adding a test that fails the build when the tier table is empty; for the platform owner, a rerun of the quarter-close job |
| 08:50 | Spellbook | The platform owner approves the rerun. The security owner applies the exclusion in Varonis. The dbt owner merges the test |
| 08:51 | Dagster | Data Workers queues the job run through Dagster and reads its status |
| 09:40 | Snowflake | The run succeeds. The null check passes on commission_amount, and the tier table is back to 36 rows, inside the baseline |
| 09:45 | Spellbook | Data Workers writes the receipt: the trigger, the Dagster run, the checks before and after, the security owner's restore, each approver and the undo path. The approved fact that commission_tiers/ is a quarter-close source lands in the context graph |
Varonis did what security asked, reversibly. The gap was on the data side. The file was quiet because its pipeline runs quarterly, the load step treated "no files" as success, and dbt's left join turned a missing table into null commissions with every job green. The per-table baseline is what knew the tier table should hold 36 rows; run_quality_check also has a minimum row count, but it is one deployment-wide floor, so the baseline does that job. Finance exported correct payouts at 11:00. Without the check, 3,640 partner lines would have paid nothing, and the first signal would have been partner emails.
| Job | What Varonis does | What Data Workers does |
|---|---|---|
| Sensitive data | Classifies it across Microsoft 365, file shares, AWS and databases, to the column in Snowflake and Databricks | Uses that kind of context next to lineage, runs and usage when a table breaks |
| Exposure | Maps users, roles and data; flags excessive permissions and stale access; predicts the impact of role assignments | Maps what a broken or changed table feeds, through dbt lineage and the context graph |
| Activity | Captures every query with forensic detail and alerts on risky behavior | Reads orchestrator runs and checks the data after each run |
| Shrinking risk | Quarantines redundant and stale data, reversibly; applies dynamic masks | Catches the pipeline that depended on that data and proposes the change for each owner |
| AI | Atlas inventories AI systems and enforces runtime guardrails | Runs its own agents behind approvals, autonomy levels per domain and receipts |
| The fix | Remediation runs in Varonis, owned by the security team | Queues the rerun after approval, sends dbt changes as diffs and verifies the result |
| The proof | An audit trail of data access and AI interactions | A receipt per fix: trigger, evidence, approvers, checks before and after, undo path |
Why doesn't Varonis just do this itself?
Because Varonis is built to see and shrink exposure, and that job is best done by a system whose loyalty is to the security posture, not the nightly load. Athena AI "works with your human analysts" to investigate and respond. The Varonis MCP Server, in private preview, lets ChatGPT, Claude or GitHub Copilot pull alerts, update ServiceNow tickets and run remediations in the Varonis platform. Atlas guards AI agents at runtime and can quarantine the identity behind one. Data Lifecycle Management keeps every action reversible. Each acts on access, exposure and data at rest, inside Varonis's domain: a sensible product decision.
Knowing that a quiet S3 prefix feeds a quarterly Dagster job, that a dbt left join turns the gap into nulls and that finance pays from a Looker Explore at 11:00 is a different kind of knowledge. Acting on it means touching the orchestrator, the warehouse and dbt, each owned by someone else, with an approval, a rollback path and proof the fix held. A security platform that reran pipelines and edited models would carry liability for data it is meant to protect, not produce. Data Workers is the product on that side of the line, and it hands every Varonis change back to the security owner.
Every tool owns a slice. Data Workers covers the whole lifecycle
Varonis owns its slice: data security, meaning who can reach sensitive data, who touched it and how to shrink that exposure. 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 posture Varonis already gives you.
| Stage | Data Workers | Varonis | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | Varonis classifies sensitive data across Microsoft 365, file shares, AWS and databases, to the column in Snowflake and Databricks: security context. Data Workers joins context to lineage, runs, schema changes and usage in one graph. |
| Analytics & Insights | 8 | 3 | Athena AI answers security questions in plain language, such as who accessed the payroll files this week. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 3 | Varonis judges data by sensitivity, exposure and age, not correctness. Data Workers checks nulls and keys after runs, holds row-count baselines and takes failures to the cause. |
| Observability & Incidents | 8.5 | 5 | Behavioral threat models, DAM and an audit trail detect risky touches and security incidents. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Varonis watches who reads what pipelines produce; it does not run them. Data Workers queues reruns through your orchestrator and reviews pipeline changes before they merge. |
| Schema & Migration | 8 | 2 | Configuration drift checks against CIS, ISO, NIST and HIPAA cover the platform's settings. Data Workers reviews schema changes, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 8.5 | Bi-directional maps of users, roles and data, excessive and stale access found, the impact of role assignments predicted. Data Workers proposes the grant a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 9.5 | Varonis's home stage: classification, dynamic masks, agentless database activity monitoring, Atlas for AI security and lifecycle quarantine. Data Workers flags sensitive column names in pull request review and proposes the masking change for its owner. |
| Cost / FinOps | 8 | 3 | Data Lifecycle Management cuts storage by quarantining redundant and obsolete data. Data Workers traces Snowflake credits to the dbt model behind them through query tags and reads AWS Cost Explorer. |
| MLOps & Models | 7.5 | 3 | Atlas inventories AI systems and guards them at runtime. Data Workers keeps the training and feature data under models healthy. |
How Varonis and Data Workers work together
Your people stay in Claude, Cursor or GitHub Copilot, Varonis and Looker. Spellbook Data Catalog (in preview) is where the data team looks: each finding, change, blast radius, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix end to end behind per-domain guardrails.
Where Varonis fits. Varonis connects over its API or MCP server today and stays the system of record for security. Data Workers' agents don't call the Varonis MCP Server; your team's own MCP client can hold both side by side, so an analyst in Claude can ask Varonis who touched a table and ask Data Workers what that table feeds. Data Workers reads natively what sits around Varonis: Snowflake checks, the dbt manifest, pull requests on GitHub and Dagster runs, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis, and for open incidents, get_incident_history.
What Data Workers writes, and where. To Varonis, nothing: lifecycle exclusions, mask changes and permission changes go to the security owner as proposals with the evidence attached. Reruns are queued through your orchestrator after a named person approves. dbt fixes go to the owner as a diff to merge. When a fix needs access, Data Workers dry-runs the grant (effective privileges after role inheritance, sensitive columns it would reach, policy conflicts, a least-privilege recommendation with an expiry), applies Unity Catalog grants after approval and drafts the grant for the owner on Snowflake and other platforms. Masking stays with Varonis and the platform: any masking change arrives as a dry run, and no agent can promote it to run on its own. Data Workers' pull request review flags new columns whose names or annotations look sensitive; it reads names, not values.
Setup today. Data Workers' agents come from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then ask "what reads REF.COMMISSION_TIERS, and did last night's quarter-close run leave nulls downstream?"
One request, L0 to L4. The autonomy ladder is set per domain, so Finance can sit at a different level from Marketing.
- •L0 manual. Engineers find empty loads and null columns by hand, usually after someone complains.
- •L1 observe. Data Workers reports each failed check with its blast radius, cause and owners, and logs what each action would have needed.
- •L2 propose. It drafts the rerun, the dbt diff and the proposals for the security owner. Owners approve before anything runs.
- •L3 act reversibly. For proven change classes, such as queuing a rerun once the source is back, it acts, verifies and records. Code still arrives as diffs.
- •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt. Varonis changes still go to the security owner, and masking always needs a person.
More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations, PII and Immuta vs Cyera. The same pattern holds for Cyera, BigID, Immuta and Dagster.
What changes for your team
Security programs on Varonis lose time at the seam with the data team: the remediation that broke a job, the fix that belongs to an engineer. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A security action that breaks a pipeline arrives traced, with the cause and the owner named.
- •Data quality. Nulls and keys are checked after each run, row counts are held to their baselines, and failures go to the cause.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them through query tags, and the fix goes to that model's owner.
- •Access. A grant a fix needs arrives drafted and dry-run, routed to its owner, with Unity Catalog changes applied after approval.
- •Audits. Each fix links the trigger, the security action, the approver, the checks and the undo path.
- •Migrations. When a platform moves, each wave is planned with its parity checks, and the owner signs off before it closes.
Analysts keep their week for deciding what counts as exposure; engineers stop learning about security changes from failed jobs. The CISO guide covers the leader's side.
Keep Varonis, or consolidate?
Keep Varonis if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most teams keep Varonis as their data security platform, especially where it covers Microsoft 365, file shares and on-prem stores too. What they consolidate is the glue: spreadsheets of which buckets feed which jobs, row-count scripts after a cleanup, and the ticket queue between analyst and model owner. Building it yourself? Calling an MCP server is the easy part; approvals, rollback and receipts are the work. See also AI agents and data access governance risks and audit trail requirements for data agents.
The case for your CFO
The outcome: security shrinks exposure as fast as it wants, and the numbers the business runs on stay right. A Varonis action that reaches a pipeline source gets caught at the next run, mapped and fixed through its owner before anyone pays or reports on bad data.
The risk story is plain. Data Workers changes nothing in Varonis and proposes every Varonis change to the security owner. It never applies a masking policy. Reruns and grants happen only after a named approver says yes, dbt changes land through your Git review, and each fix leaves a receipt. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain from L0 manual to L4 autonomous, an org-wide stop halts all autonomous dispatch, and the admin kill switch takes two people. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: Varonis now acts, not only alerts, and every quarantine or mask changes what pipelines see. The first win is one domain, read-only, with a report of every failed check, its blast radius and its cause. What stays the same: your Varonis licence, policies and analysts. Start with a pilot; the path is on the pricing page, and the pilot is credited in full against the first year. See the ROI guide.
The sentence to repeat upstairs: "Varonis keeps our sensitive data safe; Data Workers keeps it right, and every fix comes with an approval and a receipt."
Getting started
Start with a pilot. Pick the domain where unannounced security changes hurt most, such as finance close, connect Data Workers read-only to its Snowflake checks, dbt project and orchestrator runs, record baselines for the tables that matter, and let it report failed checks with cause and owners before turning on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers connect to Varonis? Varonis connects over its API or MCP server today, and Data Workers changes nothing in it. Your team's MCP client can use the Varonis MCP Server, in private preview, side by side with Data Workers' MCP servers. Proposals for Varonis, such as a lifecycle exclusion, go to the security owner with the evidence attached.
Will Data Workers undo Varonis's remediations? No. Reversing a quarantine, removing a mask or widening a role is the security owner's decision, made in Varonis. Data Workers shows what the action broke downstream and proposes options; the owner chooses.
How does this fit with Varonis Atlas? Atlas inventories AI systems and guards them at runtime, including agent intent-based access control. Data Workers' agents run behind approvals, per-domain autonomy levels and receipts, so Atlas can watch them like any other AI system.
Does Data Workers mask data? No. Masking stays with Varonis and the platforms. Data Workers flags the column that needs it and drafts the masking change as a dry run for the owner, which always needs a person to approve.
Where does our data go? The agents run in your infrastructure and hold the credentials. Your data stays in your systems; the hosted Conductor sees workflow metadata only, such as table names, proposals and approvals, never rows, credentials or model keys.
Sources
- •Varonis, Snowflake coverage (role hierarchies, excessive and stale access, impact of role assignments, dynamic masks, audit trail), https://www.varonis.com/coverage/snowflake (checked Oct 3, 2026)
- •Varonis, Databricks coverage, https://www.varonis.com/coverage/databricks (checked Oct 3, 2026)
- •Varonis, AWS coverage, https://www.varonis.com/coverage/aws (checked Oct 3, 2026)
- •Varonis, Database Activity Monitoring, https://www.varonis.com/platform/database-activity-monitoring (checked Oct 3, 2026)
- •Varonis blog, Varonis Acquires Cyral to Reinvent Database Activity Monitoring (Mar 17, 2025), https://www.varonis.com/blog/varonis-to-acquire-cyral-database-activity-monitoring (checked Oct 3, 2026)
- •Varonis blog, Varonis Acquires SlashNext, AI-Native Email Security (Sep 2, 2025), https://www.varonis.com/blog/varonis-to-acquire-slash-next-email-security (checked Oct 3, 2026)
- •Varonis blog, Varonis Launches Atlas to Secure AI and the Data That Powers It (May 28, 2026, general availability), https://www.varonis.com/blog/atlas-ai-security, and Atlas page, https://www.varonis.com/platform/ai-security (checked Oct 3, 2026)
- •Varonis blog, Introducing Agent Intent-Based Access Control (Aug 10, 2026), https://www.varonis.com/blog/agent-intent-based-access-control (checked Oct 3, 2026)
- •Varonis blog, Varonis Introduces Athena AI (Nov 15, 2023), https://www.varonis.com/blog/varonis-introduces-athena-ai, and Athena AI page, https://www.varonis.com/platform/athena-ai (checked Oct 3, 2026)
- •Varonis blog, Introducing Varonis Data Lifecycle Management (Sep 15, 2026), https://www.varonis.com/blog/introducing-data-lifecycle-management; solution page, https://www.varonis.com/solutions/data-lifecycle-management; changelog, https://www.varonis.com/changelog (checked Oct 3, 2026)
- •Varonis blog, Introducing the Varonis MCP Server (Jun 9, 2025; private preview), https://www.varonis.com/blog/mcp-server (checked Oct 3, 2026)