You're on Immuta: Immuta Decides Who Sees the Data. Data Workers Makes Sure the Data It Protects Is Right
On the Immuta Data Authorization Platform? Keep it as your policy engine. Data Workers keeps the data under each policy right, catches untagged columns at review and proposes the access changes a fix needs, behind approvals.
Your access rules live in Immuta. Policy authors write subscription policies that decide who can query a data source, and data policies that mask columns and filter rows, all keyed on tags. Identification classifies new columns in the domains where you have set identifiers. Immuta pushes every decision natively into Databricks Unity Catalog, Snowflake and Starburst. Analysts ask for data in the Request app, stewards decide with Review assist at their side, and Comply keeps the evidence. Immuta now calls itself the Data Authorization Platform, the authorization layer for every human and every agent. Immuta decides who may see which data and enforces it. Data Workers owns whether the data those policies protect is right: it catches the pipeline change that would slip past a tag, fixes the data at its cause, and proposes the access changes a fix needs to the people who own them, behind approvals.
A policy keyed on a tag does exactly what it says, so a column without the tag gets no policy at all. Finding that column, fixing the pipeline that brought it and closing every grant around it is the work this guide covers.
Key takeaways
- •Immuta keeps its job. Policies, masking, row filters, identification, the Request app, Review assist, Intents and Comply stay where they are. Data Workers works with Immuta from day one.
- •Immuta changes stay with the policy owner. Immuta connects over its API today. Tags, identifiers and policies are drafted as proposals for the Immuta policy owner, who applies them in Immuta.
- •New columns get caught where they start. Data Workers reviews the dbt pull request that carries a new column downstream and flags a column whose name reads as personal data with no masking annotation, before it merges.
- •Access changes arrive as proposals. Data Workers diffs live Unity Catalog grants against the intended set, proposes the revoke or grant a fix needs and applies Unity Catalog changes only after a named person approves.
- •Every change leaves a receipt: trigger, diff, grants before and after, approver and undo path, ready for your audit file.
- •Start with a pilot on one domain, read-only first, from L0 manual toward L4 autonomous.
Immuta is the authorization layer. Data Workers is the operator that keeps the governed data right.
Immuta answers one question at query time: may this person, or this agent, see this data, and in what form? Data Workers answers the questions around it: is the data under that policy what everyone thinks it is, did a pipeline just add something the policy can't see, and what has to change, in which system, to put it right?
Here is a Monday at a health plan. Members manage their family's coverage in a mobile app backed by PostgreSQL. Airbyte syncs the app database into Databricks raw_app. dbt Core builds silver and gold models on Unity Catalog, and an Airflow 2 DAG runs dbt every evening. Immuta governs Unity Catalog: the Member data domain carries identifiers, and a data policy masks every column tagged as a phone number for everyone outside Member Services. The raw_app schema sits in an Engineering raw domain with no identifiers, because only engineers were meant to read it. Years ago, before Immuta, the platform team granted SELECT on raw_app to a broad analysts-all group directly in Databricks; Immuta preserves grants made outside it by design, so that grant still stands. The outreach team reads gold.member_outreach in a Sigma workbook, which the team declared in dbt as an exposure. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Mon 14:20 | PostgreSQL | An app release adds guardian_phone to the members table so parents can name a second contact |
| 15:00 | Airbyte | The sync propagates the new column, as configured, into Databricks raw_app.members |
| 15:02 | Immuta | Schema monitoring registers the new column. The data source sits in a domain with no identifiers, so identification doesn't run and no tag lands. The phone masking policy has nothing to key on |
| 16:10 | GitHub | An analytics engineer opens a dbt pull request that adds guardian_phone to silver.member_contacts and gold.member_outreach for a callback campaign |
| 16:13 | GitHub and dbt | Data Workers reviews the pull request. Its privacy check reads the column names and annotations in the changed models and flags guardian_phone: the name says phone number and the column carries no masking annotation. The lineage diff shows it reaching gold.member_outreach and, through the declared exposure, the Sigma workbook. The review marks the change as blocking |
| 16:20 | Databricks | Data Workers reads the live Unity Catalog grants on raw_app and diffs them against the intended set the platform team keeps. It finds the direct SELECT for analysts-all, outside every Immuta policy |
| 16:25 | Slack and Spellbook | One change set goes to three named owners: for the Immuta policy owner, tag guardian_phone as a phone number in raw, silver and gold and add phone identifiers to the Engineering raw domain; for the platform owner, revoke the legacy group grant on raw_app; for the engineer, a diff that adds a masking annotation and a column description in the dbt models' meta |
| 16:50 | Immuta | The policy owner applies the tags in Immuta. The masking policy now covers the column, and Immuta updates its enforcement in Unity Catalog |
| 17:05 | Spellbook and Databricks | The platform owner reviews the grant diff and approves. Data Workers applies the revoke in Unity Catalog and re-reads the grants to confirm only Immuta-managed access remains |
| 17:30 | GitHub | The engineer adds the annotation. Data Workers re-reviews: every personal-data column now carries its annotation. The engineer merges |
| 17:40 | Airflow | After approval, Data Workers queues the dbt DAG run through Airflow and reads its status until it succeeds |
| 18:40 | Spellbook | Data Workers writes the receipt: the trigger, the pull request, the grants before and after, the Immuta owner's confirmation, both approvers and the undo path. The privacy team gets the exposure window, 15:00 to 17:05, to check against Databricks audit logs |
Immuta did its job: it registered the column and enforced every policy it had. The gap sat in three other places, each with its own owner: a domain without identifiers, a grant older than Immuta and a pull request about to copy the column into gold. Each owner approved their part, and the callback campaign launched with masked numbers.
| Job | What Immuta does | What Data Workers does |
|---|---|---|
| The decision | Decides who may query each data source, in real time, for people and agents | Leaves every access decision to Immuta and its policy owners |
| The enforcement | Pushes grants, masks and row filters natively into Unity Catalog, Snowflake and Starburst | Checks the data under the policy: what feeds it, what reads it, what just changed |
| The new column | Schema monitoring registers it; identification tags it in domains with identifiers | Reviews the pull request that carries it downstream and flags a personal-data column without a masking annotation |
| The tag | Policy owners and identification apply tags that drive policy | Drafts the tag and identifier change as a proposal for the Immuta policy owner |
| The grant outside Immuta | Preserves grants made directly in the platform, by design | Diffs live Unity Catalog grants against the intended set and applies the approved revoke |
| The pipeline fix | Governs access to what pipelines produce | Proposes the dbt diff, queues the rerun after approval and verifies it finished |
| The proof | Audits access decisions and answers access questions in Comply | Writes a receipt per change: trigger, diff, grants before and after, approvers, undo |
Why doesn't Immuta just do this itself?
Because Immuta is the neutral decision point for access across your estate, and that job is best done by a system that doesn't also edit the estate. Immuta's own AI follows the same line: its Policy explainer "does not activate, deactivate, or change the content of any policy", and Review assist recommends approve, temporary approve or deny while the steward decides. Its newest work, agentic data access (private preview), vends a short-lived role to an agent through Immuta's API and drops it when the task ends. Each makes the access decision sharper. None edits a dbt model, reviews a pull request or reruns a DAG, and that is a sensible product decision.
Fixing the pipeline behind a gap is a different product with a different liability: context about Airbyte, dbt, Airflow and the BI layer, blast radius across systems, a named owner's approval per change, a rollback path and proof the fix held. A policy engine that rewrote pipelines would be authorizing access to data it had just changed. Data Workers is the product on the other side of that line, and it hands every Immuta change back to the policy owner.
Every tool owns a slice. Data Workers covers the whole lifecycle
Immuta owns its slice: authorization, deciding who may see which data and enforcing it in the platform. 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 run in Immuta.
| Stage | Data Workers | Immuta | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Immuta registers data sources, syncs objects and tags columns through identification, which is the metadata its policies need. Data Workers joins that kind of context to lineage, runs, schema changes and usage in one graph. |
| Analytics & Insights | 8 | 2 | Immuta's Comply answers questions about access, such as who can reach sensitive tables. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 2 | Immuta classifies data for policy, not for correctness. Data Workers checks nulls, keys and row counts after runs and fixes failures at the cause. |
| Observability & Incidents | 8.5 | 2 | Immuta records access decisions and audit events. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Immuta governs access to 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 | Object sync and schema monitoring pick up new columns for policy. Data Workers reviews the change that adds them, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 9.5 | Immuta's home stage: subscription and data policies authored once and enforced natively in Unity Catalog, Snowflake and Starburst, the Request app, Review assist and Intents (public preview for Unity Catalog since Aug 27, 2026). Data Workers proposes the access change a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 7 | Masking, row filters and identification of sensitive columns, enforced at query time. Data Workers flags pipeline changes that add personal-data columns without a masking annotation and proposes the tag for the policy owner. |
| Cost / FinOps | 8 | 1 | Immuta 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 | 3 | Agentic data access (private preview) vends short-lived roles to agents. Data Workers keeps the training and feature data under models healthy. |
How Immuta and Data Workers work together
Your people stay where they are: Claude, Cursor or GitHub Copilot for questions and code, Immuta for policy, Sigma for analysis. Spellbook Data Catalog (in preview) is where the data team looks: each finding, proposed change, blast radius, approver and rollback, with approval requests reaching 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 Immuta fits. Immuta connects over its API today and stays the system of record for policies, tags and access decisions. Its APIs cover data sources, requests and agentic access; its docs list no MCP server. Data Workers reads natively what sits around it, among 50+ connectors: Unity Catalog grants, the dbt manifest, GitHub pull requests and Airflow DAG runs. 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 Immuta, nothing: tags, identifiers and policy changes go to the policy owner as proposals with evidence, and approved facts land in the Context Wizard graph. On Unity Catalog, Data Workers applies grants and revokes only with an approved request, scoped by your team to grants kept outside Immuta, so Immuta's policies stay the source of truth for everything they manage. On other platforms, grants are generated for the owner to apply. 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; reruns are queued through Airflow. 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 when a change needs a governance decision.
Setup today. For your assistant, 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-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-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then ask "which models and dashboards read raw_app.members, and which of their columns look like personal data?"
One request, L0 to L4. The autonomy ladder is set per domain, so the Member data domain can sit at a different level from Finance.
- •L0 manual. Connected, not acting. Stewards find untagged columns by hand.
- •L1 observe. Data Workers reports each risky pull request and grant drift with lineage and owners, and logs what each action would have needed.
- •L2 propose. Data Workers drafts the dbt diff, the grant change and the Immuta proposals. Owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the rerun after a fix merges, Data Workers acts, verifies and records it.
- •L4 autonomous. For a scoped, trusted class in one domain, Data Workers runs the loop end to end and posts the receipt. Immuta changes still go to the policy owner, and masking always needs a person.
Read more on safety, how approvals work, the autonomy levels, where your data goes and how Data Workers handles PII. Weighing Immuta against a posture tool? See the Immuta vs Cyera guide. The same build-on pattern holds for Privacera, now Trust3 AI, Okta and BigID; on Databricks, see Unity Catalog and Spellbook.
What changes for your team
Immuta programs lose much of their week to the edges of policy: the column nobody tagged, the grant that predates Immuta, the ticket asking an engineer to fix a model. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A break in a governed table arrives traced, fixed through its owner and recorded.
- •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. A new column arrives flagged at review, with the tag and grant changes drafted for their owners and Unity Catalog changes applied after approval.
- •Audits. Each change links the trigger, the approver, the grants before and after 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.
Policy authors keep their week for what only people decide: who should see what, and why. The data governance leads guide covers that role.
Keep Immuta, or consolidate?
Keep Immuta if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most Immuta programs keep it as the policy engine, especially across several platforms or in regulated estates where one policy has to hold everywhere. What they consolidate is the tooling around it: scripts that compare tags against new columns, spreadsheets of grants made before Immuta, and the queue of tickets between the steward who found a gap and the engineer who owns the model. Teams looking at open-source options can read Immuta alternatives and automating column masking policies. Building this layer yourself? Read build it ourselves with Claude Code and MCP servers: calling Immuta's API is the easy part; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: the data your policies protect is the data your pipelines actually ship. A new column holding personal data is caught at review, before it reaches a dashboard, and every grant around it is accounted for.
The risk story is plain. Data Workers changes nothing in Immuta and never applies a masking policy. Unity Catalog grants change only after a named approver says yes, every other change lands through your Git review, and each 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. 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 ask for data many times a day, and Immuta is building authorization for exactly that. More consumers means a gap under a policy reaches more people, faster. The first win: one domain, read-only, reporting every pull request that adds personal data and every grant outside Immuta. What stays the same: your Immuta licence, policies, tags and stewards. 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: "Immuta decides who sees our data; Data Workers makes sure the data it protects is right, and every fix comes with an approval and a receipt."
Getting started
Start with a pilot. Pick the Immuta domain your program cares about most, connect Data Workers read-only to the Unity Catalog grants, dbt project and pull requests behind it, and let it report risky changes and grant drift for a few weeks 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 write to Immuta? No. Immuta connects over its API today, and Data Workers changes nothing in it. Tags, identifiers and policy changes go to the policy owner as proposals, and the owner applies them in Immuta.
Won't Data Workers' Unity Catalog grants fight with Immuta's? No. Data Workers applies grant changes only after a named person approves, scoped to grants kept outside Immuta, such as legacy direct grants Immuta preserves by design. Access Immuta manages stays with its policies and the Request app.
Doesn't Immuta's identification already tag new columns? It does, in domains with identifiers, and schema monitoring picks new columns up as schemas change. Tag ingestion from Unity Catalog is in private preview. Data Workers covers the cases around it: a column in a domain without identifiers, a pull request that copies personal data into new models, and grants made outside Immuta.
How does this relate to Immuta's agentic data access? Agentic data access (private preview) gives agents short-lived roles from Immuta for a task. Data Workers' agents work on the data and on proposals, under the approvals you set; the two fit together.
Does Data Workers mask data? No. Masking stays with Immuta and the platforms. Data Workers flags the column that needs it and drafts the tag or masking change as a dry run for the owner 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
- •Immuta, home page (Data Authorization Platform, Agentic Data Access, Govern, Provision, Comply), https://www.immuta.com/ (checked Oct 3, 2026)
- •Immuta, The Authorization Layer launch essay (Sep 22, 2026), https://www.immuta.com/resources/the-authorization-layer-launch (checked Oct 2, 2026)
- •Immuta docs, Agentic data access introduction (private preview), https://documentation.immuta.com/saas/agentic-data-access/introduction (checked Oct 3, 2026)
- •Immuta docs, SaaS release notes (Intents public preview for Unity Catalog, Aug 27, 2026; Request app update, Sep 8, 2026), https://documentation.immuta.com/saas/releases/index (checked Oct 3, 2026)
- •Immuta docs, Features by preview level, https://documentation.immuta.com/saas/releases/preview-levels/features (checked Oct 3, 2026)
- •Immuta docs, Data identification reference guide, https://documentation.immuta.com/saas/configuration/tags/data-discovery/data-identification-reference-guide (checked Oct 3, 2026)
- •Immuta docs, Data discovery, https://documentation.immuta.com/saas/configuration/tags/data-discovery (checked Oct 3, 2026)
- •Immuta docs, Databricks Unity Catalog: protecting data, https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-unity-catalog/databricks-unity-catalog-integration-reference-guide/protecting-data (checked Oct 3, 2026)
- •Immuta docs, Understanding Review assist (approve, temporarily approve or deny; GA), https://documentation.immuta.com/saas/request/review-access-requests/reference-guides/understanding-review-assist (checked Oct 3, 2026)
- •Immuta docs, Immuta's AI features (Policy explainer, Review assist), https://documentation.immuta.com/saas/configuration/application-configuration/reference-guides/immuta-ai-faq/immutas-ai-features (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)