You're on Privacera, Now Trust3 AI: It Enforces the Policy. Data Workers Keeps the Data Under It Right
Running Privacera, now Trust3 AI, on Apache Ranger? Keep it as your policy layer. Data Workers keeps the data under each policy right and proposes the access changes a fix needs, behind approvals.
Privacera is now Trust3 AI. The company renamed itself on March 9, 2026: privacera.com reads "Trust3 AI by Privacera", trust3.ai is the main site, and the product documentation still carries the Privacera name. If your access policy lives in Privacera, it lives in Trust3 AI, built by the engineers behind Apache Ranger, and you write policy the Ranger way: resource policies on catalogs, schemas and tables, tag policies that follow a classification wherever it lands, row-level filters and masks for the cases in between. PolicySync pushes each decision natively into Databricks Unity Catalog, Snowflake and the rest of the estate, so one policy holds in every engine. Around that core, Trust3 AI now sells agent security: agent discovery and observability, purpose-based access for agents, MCP Security and A2A Security. Trust3 AI enforces access policy consistently across the estate. Data Workers owns whether the data those policies protect is right: it catches the pipeline change that would carry restricted data past a policy, fixes it at the cause and proposes the access changes a fix needs to their owners, behind approvals.
A Ranger policy protects the resources it names. When a dbt model copies restricted columns into a new table in a schema with broad access, the new table is a resource the restrictive policy never named. Catching that copy before it ships, fixing the model and getting the right policy onto the result is the work this guide covers.
Key takeaways
- •Trust3 AI keeps its job. Ranger policies, PolicySync, native row filters and masks, discovery and agent security stay where they are.
- •Policy changes stay with the policy owner. Trust3 AI connects over its API today. Policy items, row filters and tags arrive as proposals; the policy owner applies them in Trust3 AI.
- •Restricted data gets caught where it starts. Data Workers reviews the dbt pull request that would copy governed columns into a broadly readable schema, posts its findings and fails its check. With that check required in GitHub, the merge waits for the fix.
- •Grants are checked live. Data Workers reads the Unity Catalog grants on the schemas involved before the fix and again after PolicySync lands the new policy.
- •Every change leaves a receipt: trigger, diff, approvals, grants before and after, and the undo path.
- •Start with a pilot on one domain, read-only first, from L0 manual toward L4 autonomous.
Trust3 AI is the Ranger policy layer across your estate. Data Workers is the keeper of the data those policies govern.
Trust3 AI answers one question at query time: may this user, group or agent read this resource, and in what form? Data Workers answers the other side: what is about to land in which resource, does the source's policy reach the copy, and what has to change to keep it that way?
Here is a Wednesday at a mobile operator. Network usage lands in Databricks, governed by Unity Catalog. The tables in network, such as network.roaming_sessions, hold customer proprietary network information (CPNI). Marketing may use CPNI only for subscribers who opted in, and Trust3 AI enforces that: a resource policy keeps network to network operations and billing, and a row-level filter shows the campaign team only rows where cpni_opt_in is true. The governance team recorded both facts in the Context Wizard graph. The marketing schema is readable by the 210-person marketing-analysts group. dbt Core models live in GitHub; an AWS Step Functions state machine runs the dbt job; Census, now Fivetran Activations, syncs audiences to Iterable. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Wed 09:40 | GitHub and dbt | An analytics engineer opens a pull request adding marketing.roaming_upsell_audience for a travel-pass campaign. The model joins network.roaming_sessions to subscribers and keeps roaming_days, last_roaming_country and msisdn. A dbt exposure declares the Census sync to Iterable |
| 10:05 | GitHub | A peer approves. Auto-merge is set for the next green check |
| 10:06 | GitHub and dbt | Data Workers reviews the pull request. The lineage diff shows a new edge from network.roaming_sessions into the marketing schema and on to the declared Census exposure. The Context Wizard graph marks the source as CPNI under the opt-in policy, the model has no opt-in condition, and msisdn carries no masking annotation. Data Workers posts its findings on the pull request and fails its check. The team made that check required in branch protection, so auto-merge holds |
| 10:09 | Databricks | Data Workers reads the live Unity Catalog grants on marketing. marketing-analysts holds SELECT on the schema, so every table the model creates would be readable by all 210 analysts, opted in or not |
| 10:15 | Slack and Spellbook | One change set goes to three named owners. For the engineer: a dbt diff that joins the opt-in flag, keeps only opted-in subscribers, replaces last_roaming_country with a frequent_roamer flag and writes a table (Trust3 AI's native row filters on Unity Catalog apply to tables, not views) in a new campaign_cpni schema. For the Trust3 AI policy owner: a policy proposal granting SELECT on campaign_cpni to the campaign team and the Census service principal only, plus a row filter on cpni_opt_in as a second guard. For the governance lead: a review opened with request_governance_review |
| 11:20 | Spellbook | The governance lead approves the campaign's use of the opted-in segment |
| 11:45 | GitHub | The engineer applies the diff. Data Workers re-reviews: the lineage diff now ends in campaign_cpni, the model carries the opt-in join, and no column from network reaches marketing. The engineer merges |
| 12:00 | Step Functions | After the data owner approves the run in Spellbook, Data Workers queues the dbt job execution and reads its status until it succeeds at 12:14 |
| 12:30 | Trust3 AI | The policy owner reviews the proposal, drafts the policy items with the Data Governance Agent and applies them. PolicySync pushes the grants and the row filter into Unity Catalog |
| 12:45 | Databricks | Data Workers re-reads the live grants on campaign_cpni and marketing and diffs them against the intended set: the campaign team and the Census principal on the new schema, nothing new for marketing-analysts |
| 13:00 | Census | The sync owner turns on the activation sync to Iterable |
| 13:10 | Spellbook | Data Workers writes the receipt: the pull request, both reviews, the lineage diffs, the governance decision, the policy owner's confirmation, the grants read before and after, both approvers and the undo path |
Nothing restricted left network. Trust3 AI enforced every policy it had, exactly as written; the gap was a table its policy had never named, about to be created by a pull request two people had already approved. The campaign launched to opted-in subscribers only, with a policy on the new schema before the first sync.
| Job | What Trust3 AI does | What Data Workers does |
|---|---|---|
| The decision | Decides who may read each resource, with Ranger resource, tag and row-filter policies | Leaves every access decision to Trust3 AI and its policy owners |
| The enforcement | Pushes policy natively into Unity Catalog, Snowflake and the rest through PolicySync | Checks the data under the policy: what feeds it, what reads it, what is about to change |
| The new table | Enforces once a policy names the resource or its tag | Reviews the pull request that creates it and fails its check when restricted columns would land outside the policy |
| The policy change | Policy owners write and apply it, now with the Data Governance Agent drafting in plain language | Drafts the policy items as a proposal with the evidence: source, lineage, readers, intended principals |
| The live grants | PolicySync keeps Unity Catalog in step with policy | Reads live Unity Catalog grants before and after, and diffs them against the intended set |
| The pipeline fix | Governs access to what pipelines produce | Proposes the dbt diff, queues the run after approval and verifies it finished |
| The proof | Centralizes access audits across platforms | Writes a receipt per change: trigger, diff, approvals, grants before and after, undo |
Why doesn't Trust3 AI just do this itself?
Because Trust3 AI's value is that one policy means the same thing in every engine, a job best done by a system that doesn't also rewrite the pipelines feeding them. Its newer products follow that line. The Data Governance Agent discovers and classifies sensitive data and helps owners write policy in plain language. Agent discovery and Trustscore (April 1, 2026) inventory AI agents and score each from 0 to 10. MCP Security (May 20, 2026) treats every MCP server as untrusted and limits agents to approved tool calls, and PAIG, its open-source project, guards generative AI applications. None edits a dbt model, reviews a pull request or reruns a state machine, and that is a sensible product decision.
Fixing the pipeline behind a policy gap is a different product with a different liability: context about dbt, the orchestrator and the reverse-ETL syncs, blast radius across systems, a named owner's approval per change, a rollback path and proof the fix held. A policy layer that rewrote pipelines would be enforcing policy on data it had just changed. Data Workers works on the other side of that line and hands every Trust3 AI change back to the policy owner.
Every tool owns a slice. Data Workers covers the whole lifecycle
Trust3 AI owns its slice: Ranger-based access policy, written once and enforced natively across the estate. 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.
| Stage | Data Workers | Trust3 AI | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Sensitive data discovery classifies and tags data so policies can key on it. Data Workers joins that kind of context to lineage, runs, schema changes and usage in one graph. |
| Analytics & Insights | 8 | 2 | Trust3 AI audits who accessed what, for governance teams. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 2 | Trust3 AI 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 | Trust3 AI centralizes access audits across platforms. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Trust3 AI governs access to what pipelines produce; it does not run them. Data Workers reviews pipeline changes before they merge and queues reruns through your orchestrator. |
| Schema & Migration | 8 | 2 | PolicySync picks up resources as they appear for policy. Data Workers reviews the change that creates them, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 9 | Trust3 AI's home stage: Ranger resource, tag and row-filter policies written once and pushed natively into Unity Catalog, Snowflake and more through PolicySync. Data Workers proposes the access change a fix needs and verifies live Unity Catalog grants after it lands. |
| Security & Privacy | 8 | 8 | Discovery, native masking, encryption and AI governance with prompt filtering and MCP Security. Data Workers reviews pipeline changes that would carry restricted data past its policy and proposes the fix for the owners. |
| Cost / FinOps | 8 | 1 | Trust3 AI 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 | Agent discovery, observability and Trustscore govern AI agents and their outputs. Data Workers keeps the training and feature data under models healthy. |
How Trust3 AI and Data Workers work together
Your people stay where they are: Claude, Cursor or GitHub Copilot for questions and code, Trust3 AI for policy, Databricks for analysis. Spellbook Data Catalog (in preview) is where the data team looks: each finding, proposed change, 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 behind per-domain guardrails.
Where Trust3 AI fits. Trust3 AI connects over its API today and stays the system of record for policies, tags and access audits. Data Workers reads natively what sits around it, among 50+ connectors: Unity Catalog grants, the dbt manifest, GitHub pull requests and AWS Step Functions executions. Your governance team records which tables are restricted, and why, once in the Context Wizard graph. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis, and for open incidents, get_incident_history. Data Workers' checks rest on what its own connectors read; any Trust3 AI tooling your team's MCP client uses sits side by side with Data Workers' MCP servers.
What Data Workers writes, and where. To Trust3 AI, nothing: policy items, row filters and tags go to the policy owner as proposals with evidence. Where PolicySync manages Unity Catalog, grants stay with Trust3 AI by design; Data Workers reads them live and diffs them against the intended set. For grants kept outside Trust3 AI, Data Workers applies Unity Catalog changes only with an approved request; 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; runs are queued through Step Functions after approval. PII classification of warehouse columns stays with Privacera's discovery and the data owner; change review flags new columns whose names or annotations suggest personal data before they merge. request_governance_review opens a trackable review.
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 read network.roaming_sessions and write outside network?"
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Connected, not acting. Stewards compare new tables against policy by hand.
- •L1 observe. Data Workers reports each pull request that would carry restricted columns past a policy, and logs what each action would have needed.
- •L2 propose. Data Workers drafts the dbt diff, the policy proposal and the governance review; owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the job run after a fix merges, Data Workers acts, verifies and records it.
- •L4 autonomous. For a scoped class in one domain, Data Workers runs the loop end to end. Trust3 AI 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. The same build-on pattern holds for Immuta, ALTR and, for posture, Cyera. On Databricks, see Unity Catalog and Spellbook.
What changes for your team
Ranger programs lose much of their week at the edges of policy: the derived table nobody named, the schema whose broad grant new models inherit, the ticket to change a model after it shipped. 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.
- •Access. A change that would carry restricted data past its policy fails its review check, with the fix and policy proposal drafted.
- •Audits. Each change links the trigger, approvers, 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.
Policy owners keep their week for what only people decide: who should see what, for which purpose (see the data governance leads guide).
Keep Trust3 AI, or consolidate?
Keep Trust3 AI if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most Ranger shops keep their policy layer, especially across several engines, where one policy has to mean the same thing in Databricks, Snowflake and the lake. The rename added agent security; your policies and PolicySync work as before. What teams consolidate is the tooling around it: scripts that compare new tables against policy resources, spreadsheets of schemas with broad grants, and the ticket queue between the steward who found a gap and the engineer who owns the model. Teams weighing options can read Privacera alternatives and RBAC vs ABAC. Building this layer yourself? Read build it ourselves with Claude Code and MCP servers: approvals, rollback and receipts are the work.
The case for your CFO
The outcome: the data your policies protect stays inside them. A pipeline change that would copy restricted data into a schema with broad access is caught at review, before a dashboard, sync or campaign reads it.
The risk story is plain. Data Workers changes nothing in Trust3 AI and never applies a masking policy. Unity Catalog grants change only after a named approver says yes, every other change goes to its owner, and each leaves a receipt. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: every new agent, model and sync is another reader of what your pipelines produce, so a copy outside policy reaches more of them, faster. The first win: one domain, read-only, reporting every pull request that moves restricted columns. What stays the same: your Trust3 AI licence, Ranger policies, PolicySync and policy owners. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Trust3 AI enforces our access policy everywhere; Data Workers makes sure the data under it is right, and every fix comes with an approval and a receipt."
Getting started
Start with a pilot. Pick the domain whose Ranger policies matter most, record which tables are restricted and why in the Context Wizard graph, and connect Data Workers read-only to the Unity Catalog grants, dbt project and pull requests around it. Let it report risky changes 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
Is Privacera still Privacera? Privacera renamed itself Trust3 AI on March 9, 2026; it is the same company, not an acquisition. privacera.com reads "Trust3 AI by Privacera", trust3.ai is the main site, the product docs still say Privacera (release 9.2.41.1, September 16, 2026), and Ranger-based policy and PolicySync carry on. Data Workers works with it the same way under either name.
Does Data Workers write to Trust3 AI or Ranger? No. Trust3 AI connects over its API today, and Data Workers changes nothing in it. Policy items, row filters and tags go to the policy owner as proposals.
Won't Data Workers fight PolicySync over Unity Catalog grants? No. Where PolicySync manages a schema, Data Workers only reads the grants. It applies Unity Catalog changes only for grants your team keeps outside Trust3 AI, after a named person approves.
Don't tag policies already follow the data? They follow the tag wherever it is applied. A table built by a new dbt model carries a tag only once discovery or an owner applies it. Data Workers covers the moment between: the pull request that creates the copy.
How does this relate to Trust3 AI's MCP Security and AI Governance Agent? They govern AI agents and their traffic: which MCP servers and tools an agent may use, for which purpose. Data Workers' agents work on the data and on proposals, under the approvals you set; the two fit together.
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 (table names, proposals, approvals), never rows, credentials or model keys.
Sources
- •Trust3 AI by Privacera, privacera.com home ("Privacera is now Trust3 AI"; Data Governance Agent, AI Governance Agent), https://privacera.com/ (checked Oct 3, 2026)
- •Trust3 AI, home page (agent discovery, observability and security; MCP and A2A Security; Trust Score 0 to 10), https://trust3.ai/ (checked Oct 3, 2026)
- •Trust3 AI, about page ("Founded by the engineers behind Apache Ranger and Apache Atlas"; privacera.com/about-us/ redirects here), https://trust3.ai/about/ (checked Oct 3, 2026)
- •Trust3 AI, Meet Trust3 AI: The Next Chapter for Privacera in Data and AI Governance (Mar 9, 2026), https://trust3.ai/news/meet-trust3-ai-2/ (checked Oct 3, 2026)
- •Trust3 AI, news (Trustscore Apr 1, 2026; OneLake Sep 29, 2026), https://trust3.ai/news/ (checked Oct 3, 2026)
- •Trust3 AI, Trust3 AI Launches MCP Security to Govern and Secure Enterprise Agentic AI Workloads (May 20, 2026), https://trust3.ai/news/trust3-ai-launches-mcp-security-to-govern-and-secure-enterprise-agentic-ai-workloads/ (checked Oct 3, 2026)
- •Privacera Documentation, Databricks Unity Catalog access (PolicySync; native row filters and masks limited to tables, not views), https://docs.privacera.com/connectors/databricks-unity-catalog/access/index.html (checked Oct 3, 2026)
- •Privacera Documentation, Snowflake native support (native masking and row-level filtering), https://docs.privacera.com/connectors/snowflake/access/config-native-support.html (checked Oct 3, 2026)
- •Privacera Documentation, release notes (9.2.41.1, Sep 16, 2026), https://docs.privacera.com/resources/releases/index.html (checked Oct 3, 2026)
- •PAIG open-source repository, https://github.com/privacera/paig (checked Oct 3, 2026)
- •Trust3 AI Governance documentation (AI Assets Collector), https://docs.trust3.ai/ (checked Oct 3, 2026)
- •Fivetran docs, Census Migration FAQ, https://fivetran.com/docs/activations/census-migration-faq (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)