You're on Cyera: Cyera Finds the Exposure. Data Workers Closes It Where the Data Is Made
On Cyera DSPM? Keep it as your sensitive-data map. Data Workers traces each finding to the model, job and grant behind it and proposes the fix to the owners, behind approvals, with a receipt.
Your security team lives in Cyera. DSPM scans AWS, Azure, Google Cloud, Snowflake and Databricks without agents, its AI-native classification labels what each data store holds, and severity scores weigh sensitivity, business purpose, identities, access activity and exposure. Built-in actions revoke access, mask data or apply a label with previews and an audit trail, and workflows reach Jira, ServiceNow, Tines or Torq. AI Guardian inventories copilots and agents, Agent Guardian watches every agent from discovery to runtime, and since the Oasis acquisition closed in September, Cyera Identity covers non-human identities too. Data Workers owns the data side of the fix: it traces each finding to the model, job and grant behind it, proposes the change to each owner, applies Unity Catalog grant changes only after approval and leaves a receipt.
A finding in a warehouse table is rarely just about that table. Something built it, something reads it, and some grant made it visible.
Key takeaways
- •Cyera keeps its job. Discovery, classification, severity, Remediation Center, DLP, AI Guardian, Agent Guardian and Cyera Identity stay where they are. Data Workers works with Cyera from day one.
- •Cyera finds; Data Workers fixes the cause. A finding arrives traced to the dbt model that builds the table, the orchestrator job that runs it and the grant that exposes it.
- •Grant changes come as proposals. Data Workers diffs live Unity Catalog grants against the intended set and applies a revoke or grant only after a named owner approves. Every other platform's grant is proposed for its owner to apply.
- •Pipeline fixes go to their owners. The model change arrives as a diff with its blast radius; reruns are queued through your orchestrator after approval.
- •Every fix leaves a receipt: the finding, grants before and after, the diff, the approvers, the run and the undo path, for your audit file.
- •Start with a pilot on one catalog, read-only first, from L0 manual toward L4 autonomous.
Cyera is the sensitive-data map. Data Workers is the pipeline fixer that closes each exposure at its source.
Cyera answers where sensitive data is, who can reach it and how bad that is. Data Workers answers what produced the data, what depends on it, and which change, by which owner, makes the finding go away for good.
Here is a Thursday at a consumer lender. Loan applications land in Databricks in prod.lending.loan_applications, with Social Security numbers, bank account numbers and stated income. The credit data science team keeps its models in the shared dbt Core project, run nightly by the Dagster job ds_credit_daily. One of them, loan_apps_snapshot, has rebuilt a full copy of the applications table every night for months in sandbox.ds_credit, a schema only the ds-credit group could read. Workspace grants are managed in Terraform, and the team has recorded that, and the job each model runs in, as notes in Data Workers' context graph. Cyera scans the workspace and routes high-severity findings to Jira. The platform team uses Claude Code with Cyera MCP and Data Workers' MCP servers side by side. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Wed 18:05 | Terraform | To onboard 30 new analysts, a platform engineer merges a change that grants USE CATALOG, USE SCHEMA and SELECT on the whole sandbox catalog to account users, so everyone can try notebooks |
| 18:20 | Databricks | The grant applies. Unity Catalog privileges inherit downward, so sandbox.ds_credit.loan_apps_snapshot is now readable by every workspace user |
| Thu 08:50 | Cyera | The scan classifies US Social Security numbers, bank account numbers and income in the snapshot table and scores it high severity: sensitive data, broad access |
| 09:05 | Jira | Cyera's workflow opens a ticket for the data platform team |
| 09:20 | Claude Code | The on-call platform engineer pulls the finding's access paths through Cyera MCP, then asks Data Workers what builds and reads the table. From the dbt manifest: loan_apps_snapshot is built from prod.lending.loan_applications and feeds one downstream model, ds_credit_features. From the context graph: it runs in ds_credit_daily |
| 09:24 | Databricks | Data Workers reads the live Unity Catalog grants on sandbox and diffs them against the intended set the platform team keeps. One grant falls outside it: account users on the whole catalog. ds_credit was meant for ds-credit only |
| 09:35 | Slack and Spellbook | One change set goes to three named owners. Platform owner: revoke the catalog grant and grant the new analysts' group access to sandbox.scratch only. Data science lead: a dbt diff that builds the snapshot from the tokenized view prod.lending.loan_applications_tok and drops the SSN and account number columns; blast_radius_analysis finds one downstream model, ds_credit_features, which the lead confirms reads neither column. Platform engineer: per the team's note, sandbox grants live in Terraform, so remove the grant there or the next apply puts it back |
| 09:50 | Spellbook and Databricks | The platform owner approves. Data Workers applies the revoke and the scoped grant in Unity Catalog and re-reads the grants to confirm they match the intended set. The platform engineer updates the Terraform file the same morning |
| 10:30 | GitHub | The data science lead opens a pull request with the diff. Data Workers reviews it and posts the impact diff: one downstream model, nothing else touched. The lead merges |
| 10:45 | Dagster | After approval, Data Workers queues a ds_credit_daily run through Dagster and reads its status until it succeeds. The rebuilt table carries tokens, not SSNs or account numbers |
| 11:10 | Databricks | Earlier Delta versions of the table still hold the old columns. Data Workers proposes their cleanup to the platform owner, who runs it under the team's retention policy |
| 11:40 | Cyera | The next scan no longer finds the sensitive classes in the table. The security analyst resolves the finding |
| 12:00 | Spellbook | Data Workers writes the receipt: the Cyera finding, grants before and after, the dbt diff and pull request, both approvers, the Dagster run and the undo path. The privacy team checks the window from the Wednesday grant to the 09:50 revoke against Databricks audit logs. The analyst links the receipt in the Jira ticket and closes it |
Cyera did its job well: it found sensitive data that had become broadly readable and scored it correctly, and its revoke action could have closed access on that table. The cause sat in three other places, each with a different owner: a catalog-wide grant, the Terraform file that would have restored it, and a model that copied raw identifiers into a sandbox every night. Each owner approved their own part, and the next scan came back clean.
| Job | What Cyera does | What Data Workers does |
|---|---|---|
| Finding the data | Scans clouds, SaaS and on-prem stores and classifies what they hold | Leaves discovery and classification to Cyera |
| Scoring the risk | Weighs sensitivity, identities, access activity and exposure | Starts from the finding and asks what produced the data |
| Who can reach it | Maps access paths for people, machines and agents | Diffs live Unity Catalog grants against the intended set and names the grant that drifted |
| The quick fix | Revokes, masks or labels with a preview and audit trail | Proposes the grant change and applies Unity Catalog changes after approval |
| The cause | Routes the finding to the data owner through Jira or ServiceNow | Traces the model and job that built the table and proposes the dbt diff with its blast radius |
| Staying fixed | Rescans and confirms the finding is gone | Queues the rebuild through the orchestrator and re-reads the grants after the fix |
| The proof | Keeps an audit trail of findings and remediations | Writes a receipt per fix: finding, diff, grants before and after, approvers, run, undo |
Why doesn't Cyera just do this itself?
Because Cyera's value is a complete, trusted map of sensitive data across every store you run, and a security platform earns that trust by staying close to classification, identity and access. Its remediation follows the same line: revoke, mask, label or delete, with previews and audit, plus Automation Center workflows that hand the rest to Jira, ServiceNow, Tines or Torq. Its AI does too: Cy for investigation, Cyera MCP for natural-language queries, Agent Guardian for what agents may reach. None rewrites a dbt model or reruns a Dagster job, and that is a sensible product decision.
Changing pipelines is a different product with a different liability. It needs context about dbt, the orchestrator, the lakehouse and the code repository, blast radius for every data change, a named owner's approval per change, a rollback path and proof the fix held. A scanner that rewrote pipelines would be grading its own homework. Data Workers sits on the other side of that line; every Cyera decision stays with your security team.
Every tool owns a slice. Data Workers covers the whole lifecycle
Cyera owns its slice: finding and classifying sensitive data and knowing who can reach it. 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 findings Cyera already produces.
| Stage | Data Workers | Cyera | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Cyera inventories data stores across clouds, SaaS and on-prem and classifies what they hold, which is a rich map of sensitive data. Data Workers joins its own context to lineage, runs and schema changes in one graph. |
| Analytics & Insights | 8 | 2 | Cy and Cyera MCP answer questions about security data in DataPort. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 1 | Cyera classifies data for sensitivity, not for correctness. Data Workers checks nulls, keys and row counts after runs and fixes failures at the cause. |
| Observability & Incidents | 8.5 | 3 | Cyera raises findings with severity scores and routes them to Jira, ServiceNow, Tines or Torq. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Cyera scans what pipelines produce; it does not run or change them. Data Workers queues reruns through your orchestrator and reviews pipeline changes before they merge. |
| Schema & Migration | 8 | 1 | Cyera sees new sensitive data on its next scan. Data Workers reviews the change that adds a column, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 7 | Cyera maps who can reach sensitive data, revokes access with previews and audit, and adds identity through Cyera Identity. Data Workers proposes the access change a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 9.5 | Cyera's home stage: AI-native classification across AWS, Azure, Google Cloud, Snowflake and Databricks, severity scores, 30+ remediation actions, DLP and Agent Guardian. Data Workers fixes the pipeline behind a finding and proposes any masking for the owner. |
| Cost / FinOps | 8 | 1 | Cyera does not manage warehouse spend. Data Workers traces Snowflake credits to the dbt model behind them and reads AWS Cost Explorer. |
| MLOps & Models | 7.5 | 4 | AI-SPM and Agent Guardian inventory agents, models and MCP servers and govern what data they reach. Data Workers keeps the training and feature data under models healthy. |
How Cyera and Data Workers work together
Your people stay where they are: Claude, Cursor or GitHub Copilot for questions and code, Cyera for findings, Jira for the record of work. Spellbook Data Catalog (in preview) is where the data team reviews each finding's cause, proposed changes, 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 with more than 20 specialist agents, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember) behind per-domain guardrails.
Where Cyera fits. Cyera connects over its API today and stays the system of record for classification, findings and security remediation. Cyera MCP, released Mar 24, 2026, lets any MCP client query DataPort for sensitive data locations, access paths, exposure risks and classification insights. Run it in your own client next to Data Workers' MCP servers, as the engineer did at 09:20. Data Workers' agents do not call Cyera MCP; they work from what their own connectors read: live Unity Catalog grants, the dbt manifest, pull requests on GitHub, and Dagster, Airflow and Prefect runs, among 50+ connectors. Agents use explain_table, trace_cross_platform_lineage, blast_radius_analysis and get_incident_history.
What Data Workers writes, and where. To Cyera, nothing: findings stay in Cyera and your ticketing tool, and the receipt is linked from the ticket. On Unity Catalog, Data Workers applies grants and revokes only with an approved request. On Snowflake, BigQuery and other platforms, the grant or revoke is proposed for the platform owner to apply. Terraform and other config stay with their owners: the change set names the file to edit. Masking stays with Cyera, the platform or your policy engine: any masking change arrives as a dry run for the owner, and no agent can promote it to run on its own. dbt fixes go to the owner as a diff to merge, data cleanups are proposed for the owner to run, and reruns are queued through the orchestrator. Data Workers' pull request review flags new columns whose names or annotations look sensitive; it reads names, not values. request_governance_review opens a trackable review, and generate_audit_report assembles evidence for your auditors.
Setup today. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Add Cyera MCP to the same client following Cyera's instructions.
// Example: .mcp.json for Claude Code (Data Workers entries)
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-governance": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-governance"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then paste a Cyera finding and ask "what builds this table, what reads it, and which columns could we drop without breaking anything downstream?"
One finding, L0 to L4. The autonomy level is set per domain.
- •L0 manual. Connected, not acting. Engineers trace each Cyera finding by hand.
- •L1 observe. Data Workers attaches the model, job and drifted grant to each finding and logs what each fix would have needed.
- •L2 propose. Data Workers drafts the grant change, the dbt diff and the cleanup with their blast radius. Owners approve before anything runs.
- •L3 act reversibly. For proven change classes, such as queuing the rebuild after a fix merges, Data Workers acts, verifies and records it. Grant changes still go to their approver.
- •L4 autonomous. For a scoped, trusted class, Data Workers runs the loop end to end and posts the receipt. Masking and data cleanups always need a person.
Read more on safety, how approvals work, who owns the agents, the autonomy levels, where your data goes and how Data Workers handles PII. Choosing between Cyera and a policy engine? See Immuta vs Cyera. The same pattern holds for BigID, Varonis and Securiti; every connector and what it can change is in Data Workers integrations.
What changes for your team
DSPM programs rarely struggle to find exposure. They struggle with the queue after it: tickets that wait for someone who knows which model built the table, and fixes that come undone at the next deploy. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A finding arrives traced to the model, job and grant behind it.
- •Data quality. Keys, nulls and row counts are checked after each run, and failures go to the cause.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them, and the fix goes to that model's owner.
- •Access. Grant drift is diffed against the intended set, and Unity Catalog fixes apply after approval.
- •Audits. Each fix links the finding, the approver, the grants before and after and the undo path.
- •Migrations. Each wave is planned with its parity checks, and the owner signs off before it closes.
Security analysts keep their week for judgment: which risks matter and which exceptions to accept. See the CISOs guide.
Keep Cyera, or consolidate?
Keep Cyera if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most Cyera programs keep it as the sensitive-data map across clouds, SaaS and on-prem, and for DLP and agent security that sit outside the data lifecycle. What they consolidate is the work around it: runbooks for tracing a finding back to a model, spreadsheets of intended grants and the handoffs between the analyst who found a problem and the engineer who owns the pipeline. For background, read automated PII detection in data warehouses and AI agents and data access governance risks. Building it yourself? Read this first: reading findings is easy; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: each sensitive-data finding is closed where it starts, in the grant, the model and the job, so it does not come back with the next deploy.
The risk story is plain. Data Workers changes nothing in Cyera and never applies a masking policy. Unity Catalog grants change only after a named approver says yes, code changes land through your Git review, data cleanups are run by their owners, 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, 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. Zero migration.
Why now: agents read data many times a day, and Cyera has moved to match with AI Guardian, Agent Guardian and Cyera Identity. The first win is one catalog, read-only, with every open finding traced to its cause and owner. What stays the same: your Cyera licence, scans, findings workflow and security team. Start with a pilot; the path is on the pricing page, and the pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Cyera tells us where our sensitive data is exposed; Data Workers closes each exposure where the data is made, with an approval and a receipt for every change."
Getting started
Start with a pilot. Pick the Databricks catalog where Cyera raises the most findings, connect Data Workers read-only to its Unity Catalog grants, dbt project, orchestrator and pull requests, and let it attach a cause and an owner to each finding for a few weeks before turning on the first fix class, usually the grant fixes your platform owner approves. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers write to Cyera? No. Cyera connects over its API today, and Data Workers changes nothing in it. Findings stay in Cyera and your ticketing tool; the receipt for each fix is linked from the ticket.
Cyera can already revoke access. Why add Data Workers? Cyera's revoke closes the access on what it found, and you should keep using it. Data Workers adds the cause: the higher-level grant that opened it and the model that copies the data, each proposed to its owner and verified after, plus a pointer to the config your team says would put the grant back.
Do Data Workers' agents call Cyera MCP? No. Cyera MCP runs in your own client, next to Data Workers' MCP servers. Data Workers' detection and verification rest on what its own connectors read.
What about our Snowflake Cortex agents? Cyera announced Cortex AI agent inventory in AI Guardian on Jun 2, 2026, in private preview from July, and its remediation through Snowflake access governance is generally available. When an agent reaches a view it should not, Data Workers traces what builds and reads the view and proposes the column change or grant for the owner; on Snowflake the grant is proposed for the owner to apply.
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
- •Cyera, home page (The Data, Identity & AI Security Platform; DSPM, Data Loss Prevention, Agent Guardian, Privacy, Identity), https://www.cyera.com/ (checked Oct 3, 2026)
- •Cyera, DSPM, https://www.cyera.com/platform/dspm (checked Oct 3, 2026)
- •Cyera, Enriched Classification, https://www.cyera.com/platform/enriched-classification (checked Oct 3, 2026)
- •Cyera, Remediation (Remediation Center, Automation Center, integrations), https://www.cyera.com/solutions/remediation (checked Oct 3, 2026)
- •Cyera, AI-SPM (part of AI Guardian), https://www.cyera.com/platform/ai-spm (checked Oct 3, 2026)
- •Cyera, Agent Guardian, https://www.cyera.com/platform/agent-guardian (checked Oct 3, 2026)
- •Cyera, Cyera Launches Agent Guardian to Secure the Autonomous Workforce (Aug 3, 2026), https://www.cyera.com/press-releases/cyera-launches-agent-guardian-to-secure-the-autonomous-workforce (checked Oct 3, 2026)
- •Cyera, Latest releases (Cy, Aug 12, 2026; Remediation Center, Jun 16, 2026; AI Guardian, Aug 12, 2025), https://www.cyera.com/latest-releases (checked Oct 3, 2026)
- •Cyera, Cyera MCP (Mar 24, 2026), https://www.cyera.com/latest-releases/cyera-mcp (checked Oct 3, 2026)
- •Cyera, Cyera Completes Acquisition of Oasis Security (Sep 3, 2026), https://www.cyera.com/press-releases/cyera-completes-acquisition-of-oasis-security (checked Oct 3, 2026)
- •Cyera, Make Data Security AI Agent-Ready with Cyera MCP (blog; clients Claude, Cursor, Microsoft Copilot, ChatGPT), https://www.cyera.com/blog/cyera-mcp (checked Oct 3, 2026)
- •Cyera, Cyera Identity, https://www.cyera.com/platform/identity-access (checked Oct 3, 2026)
- •Cyera, Cyera and Snowflake Advance Secure AI Agent Adoption for the Enterprise (Jun 2, 2026; Cortex AI agent visibility in private preview in July, Snowflake access governance remediation GA), https://www.cyera.com/press-releases/cyera-and-snowflake-advance-secure-ai-agent-adoption-for-the-enterprise (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, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)