You're on ALTR: ALTR Masks and Tokenizes Sensitive Data Where It Sits. Data Workers Keeps the Data Around Those Policies Right
On ALTR? Keep it for masking, tokenization and format-preserving encryption in Snowflake and Databricks. Data Workers keeps the pipelines around those policies right and proposes access changes, behind approvals.
Your sensitive columns in Snowflake are protected by ALTR. Classification finds the PHI, PII and PCI. Snowflake object tags connect to ALTR policies, and ALTR enforces masking, access management and row access with native Snowflake objects, so a claims analyst sees the last four digits and a fraud investigator sees the full value. The most sensitive identifiers sit in the warehouse as vaulted tokens, deterministic so joins still work, or as format-preserving encryption that keeps the shape downstream systems expect. On Databricks, ALTR pushes tag-driven policies into Unity Catalog. Since May 2026, the ALTR MCP server lets an assistant manage all of it from a prompt. ALTR masks and tokenizes sensitive data where it sits. Data Workers owns whether the data around those policies stays right: the pipelines that read protected columns, the models that copy them, and the changes a fix needs, proposed to their owners behind approvals.
Key takeaways
- •ALTR keeps its job. Classification, masking, tokenization, format-preserving encryption, activity monitoring and AI Data Cloak stay where they are. Data Workers works with ALTR from day one.
- •ALTR connects over its API or MCP server today. Your engineer's assistant holds the ALTR MCP server and Data Workers' MCP servers side by side.
- •Protected data still has to be right. Data Workers watches the pipelines that read tokenized and masked columns and traces a bad run through dbt lineage to its change.
- •Copies outside a policy get caught. When a model copies a sensitive value into a column ALTR's tags don't cover, Data Workers flags it in the incident and proposes the tag for the ALTR policy owner.
- •Each owner approves their own part. dbt fixes arrive as diffs, Snowflake access and masking as proposals, and reruns are queued after approval, with one receipt per change.
ALTR protects the value. Data Workers keeps the data around it right.
ALTR answers who may see a sensitive value, and in what form. Data Workers answers what comes next: is the pipeline reading it still right, did a change copy it somewhere the policy can't see, and who must change what.
Here is a Wednesday at a regional health plan. A new pharmacy benefit manager (PBM) drops a daily claims file into Azure Data Lake Storage. An Azure Data Factory pipeline, pbm_daily_load, copies it into Snowflake raw_pbm.claims and runs dbt Core to build int_pbm_claims_matched, marts.pharmacy_spend and marts.pbm_claims_unmatched, a research table for claims operations. Member SSNs in core.members.member_ssn are ALTR deterministic tokens: ALTR resolves the real value only for roles its policy authorizes, such as claims investigators; every other role, including the production dbt role DBT_PROD, sees tokens. That fact sits in Data Workers' context graph as an approved team note, with notes naming the Tableau workbooks that read each mart. After every load, the pipeline records the matched-claims rate with monitor_metrics, so Data Workers holds a baseline. Approval requests reach owners by email; incident cards post to the team's Microsoft Teams channel. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 15:30 | GitHub and dbt | Pull request #288 merges. The new PBM's file carries no member ID, so int_pbm_claims_matched now joins the file's cardholder_id, which for this PBM is the member's SSN, to core.members.member_ssn. Unmatched claims go to pbm_claims_unmatched with cardholder_id kept for research. In development the engineer ran it under an investigator role that ALTR detokenizes for, and every claim matched |
| Wed 02:00 | Azure Data Lake Storage | The PBM's first production file lands: 41,900 claims |
| 02:10 | Azure Data Factory and Snowflake | pbm_daily_load copies the file into raw_pbm.claims |
| 02:25 | dbt and Snowflake | dbt builds under DBT_PROD. ALTR does exactly what its policy says: member_ssn returns tokens to this role. Clear SSNs never equal tokens, so 41,300 claims fall to pbm_claims_unmatched, each carrying a clear SSN in cardholder_id. The new table carries no tag, so ALTR's tag-based SSN policy has nothing to apply to it |
| 02:40 | Data Workers | The matched-claims rate recorded by the pipeline drops from a baseline near 98% to 1.4%. Data Workers opens an incident and posts a card to the claims data channel in Teams |
| 02:46 | Data Workers | trace_cross_platform_lineage and blast_radius_analysis follow the dbt manifest from int_pbm_claims_matched to pharmacy_spend and pbm_claims_unmatched; the team's notes add the Tableau workbooks Pharmacy Spend and Claims Research. The change that introduced the join is #288. The context graph's note on member_ssn explains the miss: DBT_PROD reads tokens |
| 02:50 | Data Workers | #288 joins cardholder_id to member_ssn, so Data Workers treats it as SSN data and runs its pull-request privacy check over the research table's columns: cardholder_id is SSN data with no tokenize or mask annotation. It marks the table as a likely exposure and asks the claims data owner to confirm it in the change set |
| 02:55 | Email and Spellbook | One change set goes to four named owners. For the ALTR policy owner: put the SSN tag on raw_pbm.claims.cardholder_id and pbm_claims_unmatched.cardholder_id. For the integration owner: tokenize cardholder_id in the PBM load with the same deterministic ALTR tokenization as member_ssn, so the join compares token to token. For the analytics engineer: a dbt diff that drops cardholder_id from the research table and carries the claim ID and pharmacy instead. For the platform owner: a proposed Snowflake revoke of the claims operations role's SELECT on the research table until the fix lands |
| 07:00 | Tableau | Pharmacy Spend refreshes. Pharmacy cost for the plan shows a 98% drop. Data Workers' Teams card already sits in the channel above the finance team's question |
| 07:45 | Snowflake | The platform owner runs the revoke |
| 08:20 | Snowflake and ALTR | The ALTR policy owner sets the SSN tag on both columns, then checks from Claude Code through the ALTR MCP server that the tag's ALTR policy now covers them |
| 09:10 | GitHub | The analytics engineer reviews the diff and its blast radius and merges |
| 10:05 | Azure Data Factory | The integration owner ships the tokenization step in the load. The raw table is reloaded with tokens |
| 10:20 | Spellbook and Azure Data Factory | The data owner approves the rerun. Data Workers queues pbm_daily_load with trigger_adf_pipeline and reads the pipeline run status until it succeeds at 11:05 |
| 11:10 | Data Workers | The matched-claims rate is back at 98.2%. The research table holds 760 claims with no SSN column. Data Workers writes the receipt: the trigger, pull request #288 and the fix, the tags and revoke each owner applied, the approvers, the rerun and the counts before and after. The exposure window, 02:25 to 07:45, goes to the privacy officer, who checks ALTR's Snowflake query audit for every read of the table in that window |
ALTR did its job twice over. It kept SSNs as tokens for a role with no business seeing them, and it covered the new column the moment it carried a tag. The failure lived in the pipeline: a join tested under one role and run under another, and a model that copied a sensitive value into a table no policy knew about. The cause was in GitHub, the symptom in Snowflake and Tableau, the containment in ALTR and the reload in Data Factory, with five owners. Each approved their own part, and the receipt holds the whole story.
| Job | What ALTR does | What Data Workers does |
|---|---|---|
| The protection | Masks, tokenizes and encrypts sensitive columns, enforced natively in Snowflake and pushed down to Databricks | Leaves every protection decision to ALTR and its policy owners |
| The policy | Ties masking and access to Snowflake tags and per-role rules | Proposes the tag a new sensitive column needs, for the ALTR policy owner to apply |
| The pipeline | Lets analytics and joins run on deterministic tokens and format-preserving values | Watches the runs that read protected columns and catches the one that went wrong |
| The cause | Shows which roles see which form of the value | Traces the failure through dbt lineage to the change behind it, using the team's approved notes on how each column is protected |
| The fix | Applies policy, tokenization and access rules in ALTR | Proposes the dbt diff, the Snowflake access change and the masking for their owners, then queues the rerun after approval |
| The proof | Audits queries and access requests on Snowflake | Writes a receipt that links the trigger, the fix, the approvers and the run |
Why doesn't ALTR just do this itself?
Because ALTR is built to sit between people and sensitive values and do that one job well. Tags drive masking, Snowflake enforces it natively, and original values live in a vault. The open-source ALTR MCP server (GPLv3; altr-mcp 0.6.0 shipped Aug 18, 2026) extends that design to agents, and it is a real step: an agent can connect databases, create masking policies, approve access requests and tokenize values, and when it applies a masking policy, "that policy is applied". Teams can hide the destructive tools and have agents confirm significant changes. All of it acts on ALTR's own objects.
Fixing a dbt join is a different product with a different liability: context across Data Factory, dbt, Snowflake roles and Tableau, blast radius, a named owner's approval per change, a rerun in order, and proof the numbers came back. A security platform that rewrote pipelines would be changing the data it exists to protect. Data Workers is the product on the other side of that line, and it hands every protection decision back to ALTR.
Every tool owns a slice. Data Workers covers the whole lifecycle
ALTR owns its slice: protecting sensitive values where they sit. 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 ALTR.
| Stage | Data Workers | ALTR | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | ALTR's classification builds a report of sensitive columns, and the Atlan integration turns it into governance tags there. Data Workers joins its own context graph to lineage, runs, schema changes and usage. |
| Analytics & Insights | 8 | 2 | ALTR keeps analytics running on protected data; it does not answer business questions. Data Workers answers questions about the data from governed context and checks the numbers behind them. |
| Data Quality | 8 | 2 | ALTR protects values; whether they are right is outside its job. Data Workers checks nulls, keys and row counts and watches the baselines a team records, then fixes failures at the cause. |
| Observability & Incidents | 8.5 | 3 | Database activity monitoring shows who read what and alerts on unusual access. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 2 | ALTR protects what pipelines land and read; it does not run them. Data Workers traces pipelines through dbt lineage and queues reruns through your orchestrator after approval. |
| Schema & Migration | 8 | 1 | ALTR applies policy to the columns and tags it is given. Data Workers reviews the change that adds a column, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 8.5 | Access management and row access policies on Snowflake, per-role masking rules and an access request flow with approve and deny. Data Workers proposes the access change a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 9 | ALTR's home stage: dynamic masking, vaulted deterministic and non-deterministic tokenization, FF3-1 format-preserving encryption native in Snowflake, and AI Data Cloak for agents and copilots. Data Workers flags sensitive columns that land outside a policy and proposes the tag for the owner. |
| Cost / FinOps | 8 | 1 | ALTR 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 | 2 | Deterministic tokens keep training data joinable, and AI Data Cloak governs what agents receive. Data Workers keeps the data feeding features and models healthy upstream. |
How ALTR and Data Workers work together
Your people stay where they are: Claude, Cursor or Copilot for questions and code, ALTR for policy, Tableau for the numbers. Spellbook Data Catalog (in preview) is where the data team looks: each incident, proposed change, blast radius, approver and rollback, with approval requests reaching people in Slack or email and incident cards posting to Teams. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work, and the Autonomous Data-Conductor runs each fix (detect, diagnose, fix, review, verify, remember) behind per-domain guardrails.
Where ALTR fits. ALTR connects over its API or MCP server today and stays the record for classification, tags, masking, tokenization and query audit. Data Workers' agents never call the ALTR MCP server; your engineer's assistant holds both, and the person carries a proposal into ALTR. Data Workers reads natively what sits around ALTR: Snowflake, Databricks, the dbt manifest and pull requests on GitHub, Azure Data Factory, Airflow and Prefect runs and Tableau, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis, with the team's approved notes and their sources.
What Data Workers writes, and where. To ALTR, nothing: tags, policies and tokenization stay with ALTR's owners. dbt fixes go to the owner as a diff to merge. Snowflake access changes are proposed for the platform owner to apply; on Databricks, Data Workers applies Unity Catalog grants and revokes only after approval. Masking is always a dry-run proposal a person approves and applies. Data Workers deletes no rows. Reruns are queued through Data Factory, Airflow, Prefect or Dagster after approval. The privacy check in pull-request review flags SSN, email, phone and birth-date columns a change writes without a tokenize, hash or mask annotation, from names, declared types and annotations, never values. request_governance_review opens a trackable review when a change needs a governance decision.
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. Add the ALTR MCP server next to them per ALTR's README, with an ALTR management API key; its RESTRICTED_TOOLS setting hides the tools you don't want the assistant to call.
// Example: .mcp.json for Claude Code (Data Workers servers; add the ALTR MCP server per ALTR's README)
{
"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 ask "Which dbt models read core.members.member_ssn, and which of them run under a role that only sees tokens?"
One incident, L0 to L4. Autonomy is set per domain, so pharmacy claims can sit at a different level from member enrollment.
- •L0 manual. Connected, not acting. Engineers trace each broken run by hand.
- •L1 observe. Data Workers reports cause, reach and owners and logs what each action would have needed. Nothing changes.
- •L2 propose. Data Workers drafts the dbt diff, the Snowflake access change, the tag proposal and the rerun. Owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the rerun once a fix merges, Data Workers acts, verifies the run and records it. Code still arrives as diffs.
- •L4 autonomous. For a scoped, trusted class in one domain, Data Workers runs the loop end to end and posts the receipt. Masking always needs a person, and ALTR policy stays with ALTR's owners.
Read more on safety, how approvals work, the autonomy levels, where your data goes, how Data Workers handles PII and column masking policies automation. The same build-on pattern holds for Immuta, Privacera, BigID and Snowflake Horizon Context; for the load side, see You're on Azure Data Factory, and for every connector, Data Workers integrations.
What changes for your team
ALTR programs rarely struggle to protect the columns they know. They struggle with the edges: the model that copies a value into a new table, the join tested under one role and run under another. With Data Workers, the data side of those edges runs on autopilot at the level you set.
- •Incidents. A broken run on protected data 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; failures go to the cause.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them through query tags.
- •Access. A sensitive column outside every policy arrives flagged, with the tag and access change drafted for their owners.
- •Audits. Each fix links the trigger, diff, approvers, rerun and the exposure window your privacy officer checks in ALTR's audit.
- •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: which values count as sensitive and who sees which form. The data governance leads guide covers that role.
Keep ALTR, or consolidate?
Keep ALTR if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most ALTR customers keep it as the protection layer, especially where vaulted tokenization and format-preserving encryption carry regulated identifiers: that is a security decision with its own vault, keys and audit. What they consolidate is the tooling around it: the spreadsheet mapping tagged columns to the models that read them, the scripts that grep dbt for a column name, and the tickets that bounce between security and data engineering when a policy breaks a job. For the masking itself, Data masking: AI vs manual tools compares approaches. Building the fix layer yourself? Read build it ourselves with Claude Code and MCP servers: calling the ALTR MCP server is the easy part; lineage across six systems, approvals, rollback and receipts are the work.
The case for your CFO
The outcome: pipelines that read tokenized values produce the right numbers, sensitive copies are caught and handed to ALTR's owners the same morning, and every fix lands at its source with proof.
The risk story is plain. Data Workers changes nothing in ALTR and never applies a masking policy. It 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, 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: ALTR's MCP server and AI Data Cloak bring agents into the policy layer, and agents read protected data every day. More reads under more roles means more joins and copies that behave differently from what an engineer tested. The first win: one protected domain, read-only, with every pipeline that reads a tokenized or masked column mapped to its owner and baseline. What stays the same: your ALTR policies, tags, vault, keys and the people who run them. 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: "ALTR protects every sensitive value in Snowflake; Data Workers keeps the pipelines around it right, and every fix comes with an approval and a receipt."
Getting started
Start with a pilot. Pick the domain where protected data does the most work, such as claims or member data, connect Data Workers read-only to the dbt project, orchestrator, warehouse and BI behind it, record which roles see tokens or masks, and let it watch a few weeks of runs before turning on the first fix class. It is the quickest way to see an agentic data platform next to the security stack 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
Does Data Workers connect to ALTR? ALTR connects over its API or MCP server today. Your engineer's assistant holds the ALTR MCP server and Data Workers' MCP servers side by side, and the person carries a proposed tag or policy change into ALTR. Data Workers changes nothing in ALTR.
Will Data Workers apply masking or tags for us? No. A missing tag or masking policy arrives as a dry-run proposal for the ALTR policy owner, who applies it in ALTR. No agent can promote a masking change to run on its own.
Can Data Workers see detokenized values? Data Workers reads Snowflake under the role you give it, so ALTR's policy decides what it sees. We recommend a role that sees tokens and masks. The agents run in your infrastructure, and the hosted Conductor sees workflow metadata only, never rows, credentials or model keys.
How does Data Workers know a column is tokenized for one role and clear for another? The team records it once as an approved note in the Context Wizard graph, with its source. From then on, every trace and diagnosis that touches the column carries that fact.
ALTR already classifies data. Why does Data Workers check columns too? To catch a copy at the change, before the next classification scan. Pull-request review flags personal-data columns written without a tokenize, hash or mask annotation, from column names, declared types and the team's notes, and an incident diagnosis flags a sensitive copy like the one above. Neither reads values, tags or masks anything; ALTR's classification stays the record.
Sources
- •ALTR, home page, https://altr.com/ (checked Oct 3, 2026)
- •ALTR, Snowflake (no proxies, Free Forever tier), https://altr.com/snowflake/ (checked Oct 3, 2026)
- •ALTR, Tokenization (vaulted, deterministic tokens), https://altr.com/use-cases/tokenization/ (checked Oct 3, 2026)
- •ALTR, Format-Preserving Encryption (FF3-1), https://altr.com/use-cases/format-preserving-encryption/ (checked Oct 3, 2026)
- •ALTR, Databricks, https://altr.com/solutions/databricks/ (checked Oct 3, 2026)
- •ALTR, AI Data Cloak, https://altr.com/use-cases/ai-data-cloak/ (checked Oct 3, 2026)
- •ALTR, "We built the bridge between AI agents and enterprise data security" (May 19, 2026), https://altr.com/blog/we-built-the-bridge-between-ai-agents-and-enterprise-data-security/ (checked Oct 3, 2026)
- •ALTR MCP Server README (GPLv3, tools, RESTRICTED_TOOLS), https://github.com/altrsoftware/altr-mcp-server (checked Oct 3, 2026)
- •PyPI, altr-mcp 0.6.0 (Aug 18, 2026), https://pypi.org/project/altr-mcp/ (checked Oct 3, 2026)
- •ALTR docs, Manage Tags, https://docs.altr.com/data-sources/snowflake/policy-on-snowflake/manage-tags/ (checked Oct 3, 2026)
- •ALTR docs, Policy on Snowflake, https://docs.altr.com/data-sources/snowflake/policy-on-snowflake/ (checked Oct 3, 2026)
- •ALTR docs, Masking types, https://docs.altr.com/features/data-access-controls/data-masking/masking-types/ (checked Oct 3, 2026)
- •ALTR, "Authenticate the agent, authorize the action, minimize the data" (Sep 23, 2026), https://altr.com/blog/authenticate-the-agent-authorize-the-action-minimize-the-data/ (checked Oct 3, 2026)
- •ALTR, news, https://altr.com/news/ (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)