You're on SailPoint: SailPoint Certifies Who Should Have Access. Data Workers Makes Sure the Warehouse and the Data Still Match
On SailPoint Agentic Fabric and Human Fabric? Keep them as your identity governance. Data Workers keeps warehouse grants and data in line with each certification decision and proposes the changes, behind approvals.
Your access decisions run through SailPoint. Every quarter a certification campaign goes out, and managers and source owners approve or revoke each entitlement on their list. Human Fabric, the evolution of Identity Security Cloud, now auto-certifies low-risk access, recommends roles from peer groups and remediates revoked access through its connectors (or a task for the source owner). Agentic Fabric, generally available since August 4, 2026, discovers AI agents and machine identities and ties each one to a human owner. Through its MCP server, access requests can start in Claude Desktop. SailPoint certifies who should have access. Data Workers makes sure the warehouse and the data still match that decision: it catches the job a revoke just broke, traces what the missing data reaches, proposes the narrow grant the pipeline actually needs and keeps the record, behind approvals.
Key takeaways
- •SailPoint keeps its job. Certifications, requests, provisioning, Data Access Security and Agentic Fabric stay where they are. Data Workers works with SailPoint from day one.
- •Revokes stay revoked. When a campaign pulls a role a pipeline needed, Data Workers proposes a narrower grant for the platform owner instead of putting the old role back, and the assignment goes back through a SailPoint access request.
- •The data side gets caught early. Data Workers flags the empty period from a
monitor_metricsrow-count baseline and the failed run, and traces the models and reports that depend on it before the business opens them. - •Every grant has a record. Data Workers records each grant with its justification and expiry date in its access-grants ledger. Nothing revokes it at that date: the owner reviews it, and SailPoint certifies it next quarter.
- •Every change leaves a receipt: the certification decision, the diff, the approvers, the checks and the undo path.
- •Start with a pilot on one domain, read-only first, from L0 manual toward L4 autonomous.
SailPoint certifies who should have access. Data Workers makes sure the warehouse and the data still match.
SailPoint answers the identity question: should this person, service account or agent hold this entitlement, and who vouches for it? Data Workers answers the data questions around it: what ran under that entitlement, what stopped when it changed, which reports now carry stale numbers, and what smallest grant puts the pipeline right without undoing the decision?
Here is a month-open at a software company. Finance actuals land from the ERP into Snowflake RAW_ERP. An AWS Step Functions state machine, fpa-month-open, runs on the first business day: one task loads the period's GL balances, the next runs dbt Core to build the FP&A models in the FPA schema, including fct_forecast_vs_actuals. The dbt step connects as Snowflake service user SVC_FPA_ETL, which holds the role FPA_TRANSFORM, built three years ago for convenience: write on FPA, read on RAW_ERP, and an inherited HR_READ for a headcount model that was retired last year. The CFO's staff review the Forecast vs Actuals report in Power BI at 08:30. SailPoint's Snowflake connector manages Snowflake entitlements as roles. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Fri 16:40 | SailPoint | In the Q3 Snowflake role certification, SVC_FPA_ETL has no manager, so its items go to the campaign owner on the IAM team. One line reads FPA_TRANSFORM: no owner, no description, and its access includes HR compensation tables. The campaign owner revokes it, a reasonable call on what the line showed |
| 18:05 | SailPoint and Snowflake | The campaign owner signs off. Human Fabric remediates through the Snowflake connector and removes FPA_TRANSFORM from SVC_FPA_ETL, exactly as decided |
| Mon 02:00 | Step Functions | fpa-month-open starts. The load task writes September's GL balances to RAW_ERP.GL_BALANCES, as it always has |
| 02:14 | Step Functions and dbt | The dbt task fails and the execution ends FAILED. No FP&A model is built for September |
| 02:20 | Data Workers | Data Workers reads the execution status: failed. monitor_metrics flags fct_forecast_vs_actuals at 0 rows for the new period against the row-count baseline the team records, near 18,400. run_quality_check on RAW_ERP.GL_BALANCES passes: keys present, no nulls, row count above the floor. The data arrived; the build did not run |
| 02:24 | Spellbook and Slack | blast_radius_analysis walks the dbt manifest from fct_forecast_vs_actuals to mart_variance_by_cost_center and mart_opex_by_department, and a context-graph note the team recorded adds the Power BI report and its 08:30 review. A card goes to #fpa-data naming the platform on-call and the FP&A analytics owner |
| 07:10 | Step Functions and Snowflake | The on-call engineer opens the failed task: insufficient privileges on schema FPA for SVC_FPA_ETL. SailPoint's history shows Friday's revoke. The engineer pastes the old role's grants into the incident |
| 07:25 | Spellbook and email | Data Workers proposes one change set to three named owners. For the platform owner: a new role, FPA_DBT_WRITER, with write on FPA and read on the three RAW_ERP tables the dbt project selects from, per the manifest, for the owner to create and grant in Snowflake. The access dry run on the proposed grant shows its effective privileges after inheritance and no sensitive columns. For the IAM lead: make the new role requestable and name the FP&A platform owner as owner of SVC_FPA_ETL in SailPoint. For the FP&A analytics owner: a heads-up that the 08:30 numbers will be late, with the cause |
| 07:50 | Snowflake | The platform owner reviews the proposal and creates the role. HR_READ is not part of it, so Friday's decision stands |
| 08:02 | Claude Desktop | The platform owner asks SailPoint's MCP server for the requestable FPA_DBT_WRITER entitlement and files an access request for SVC_FPA_ETL, with the incident link as the reason |
| 08:12 | SailPoint | The IAM lead approves the request, and SailPoint provisions the role through the Snowflake connector. SailPoint stays the record of who holds what |
| 08:15 | Spellbook and Step Functions | The platform owner approves the rerun in Spellbook. Data Workers queues the fpa-month-open execution through Step Functions and reads its status until it succeeds at 08:33 |
| 08:36 | Data Workers | monitor_metrics shows 18,390 rows for September, inside the baseline. run_quality_check passes on the three models |
| 08:40 | Power BI | The report owner refreshes the dataset. The review starts at 08:45 instead of 08:30 |
| 08:50 | Spellbook | Data Workers records the grant in its access-grants ledger with its justification and a 90-day expiry date, and writes the receipt: the certification decision it followed, both approvers, the role change, the SailPoint request, the execution runs, the checks and the undo path for the owner (revoke FPA_DBT_WRITER from the user, drop the role) |
SailPoint did its job twice: it carried out the revoke on Friday and provisioned the replacement on Monday. What it could not see was that one identity powered a month-open job whose real needs were three tables and one schema. Data Workers worked that out from the dbt manifest and the run history, proposed the narrow role and handed the assignment back to SailPoint. The reviewer's call held, and next quarter the item routes to an owner who knows what it runs.
| Job | What SailPoint does | What Data Workers does |
|---|---|---|
| The decision | Runs certification campaigns and decides, through reviewers, who should hold each entitlement | Leaves every access decision to SailPoint and its reviewers |
| The remediation | Revokes and provisions through its connectors, such as Snowflake | Checks what the change did to the data: what ran under the role, what stopped, what is now stale |
| The detection | Flags risky access and anomalies for reviewers | Flags the failed run and the empty period against its baseline, and traces the blast radius to models and reports |
| The fix | Approves and provisions requested access | Proposes the narrowest grant the pipeline needs from the dbt manifest, for the platform owner to apply |
| The owner | Ties identities, including agents and machine identities, to accountable humans | Names the data owners of each affected table and report, and routes each part of the fix to them |
| The rerun | Not its job | Queues the approved rerun through the orchestrator and verifies the rebuilt data |
| The proof | Keeps campaign decisions and access history for audit | Writes a receipt per change and records each grant with its justification and expiry date |
Why doesn't SailPoint just do this itself?
Because SailPoint governs identity across every application in the enterprise, and that job rewards breadth and neutrality. A revoke is the correct outcome of a certification when nobody can vouch for the access, and SailPoint is designed to carry out exactly what the reviewer decided. Its newest work follows the same line: Agentic Fabric ties agents and machine identities to human owners, the MCP server files access requests from Claude Desktop, and Data Access Security enforces least privilege on sensitive data. Each makes the identity decision sharper. None rewrites a role around a dbt project's real dependencies, reruns a state machine or checks that September's numbers came back right, and that is a sensible product decision.
Fixing the data behind an access change is a different product with a different liability: context across the orchestrator, dbt, the warehouse and the reports; blast radius; a named owner's approval per change; a rollback path; and proof the fix held. An identity platform that edited pipelines would be certifying access to jobs it had just changed. Data Workers sits on the other side of that line and hands every entitlement decision back to SailPoint.
Every tool owns a slice. Data Workers covers the whole lifecycle
SailPoint owns its slice: identity governance, certifying who should have access and carrying it out. 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 identity governance you run in SailPoint.
| Stage | Data Workers | SailPoint | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | SailPoint's Identity Graph holds identities, accounts and entitlements across your applications. Data Workers joins tables, lineage, runs, owners and usage in one graph, and connects SailPoint's context over its API. |
| Analytics & Insights | 8 | 2 | Human Fabric surfaces risky access patterns for identity teams. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 1 | SailPoint does not check data. Data Workers checks nulls, keys and row counts after runs and takes failures to their cause. |
| Observability & Incidents | 8.5 | 2 | SailPoint feeds identity threats to security operations. Data Workers detects, diagnoses, fixes and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | SailPoint provisions accounts and roles; it does not run pipelines. Data Workers queues approved reruns through your orchestrator and reviews pipeline changes before they merge. |
| Schema & Migration | 8 | 1 | Schema changes sit outside identity governance. Data Workers flags them from the dbt manifest and pull requests, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 9.5 | SailPoint's home stage: access certifications that auto-certify low-risk access, role modeling, access requests (also through its MCP server) and remediation through connectors such as Snowflake. Data Workers proposes the grant a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 8.5 | Data Access Security classifies sensitive data and enforces least privilege; Agentic Fabric (GA Aug 4, 2026) discovers agents and ties each to a human owner. Data Workers flags personal-data columns in pipeline changes and proposes masking for the owner. |
| Cost / FinOps | 8 | 1 | SailPoint 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 | Agentic Fabric governs AI agents' identities and credentials, including Snowflake Cortex agents. Data Workers keeps the training and feature data under models healthy. |
How SailPoint and Data Workers work together
Your people stay where they are: Claude Desktop, Claude Code or Cursor for questions and access requests, SailPoint for certifications, Power BI for reporting. Spellbook Data Catalog (in preview) is where the data team reviews each finding, proposed change, 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 SailPoint fits. SailPoint connects over its API or MCP server today and stays the system of record for identities, entitlements, certification decisions and access requests. Its MCP server is for your team's own client: people search requestable items and file, track or cancel requests from Claude Desktop, side by side with Data Workers' MCP servers. Data Workers' agents don't call it; detection and verification rest on what Data Workers reads natively among 50+ connectors: Snowflake checks, the dbt manifest, orchestrator runs (Step Functions, Airflow, Prefect, Dagster, Azure Data Factory) and Unity Catalog grants. 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 SailPoint, nothing: entitlement and owner changes go to the IAM team as proposals, and assignments go back through SailPoint access requests. On Snowflake and BigQuery, grants and revokes are proposed for the platform owner to apply; on Postgres, Data Workers generates the GRANT for the owner to run. Each comes with an access dry run that shows effective privileges after role inheritance and flags sensitive columns the grant would reach. On Databricks, Data Workers applies Unity Catalog grants and revokes only with an approved request, and re-reads the live grants against the intended set your team keeps. provision_access records each grant in the access-grants ledger with its justification and expiry date. Nothing revokes it at that date: the owner revokes or renews it, and SailPoint certifies it next campaign. request_governance_review opens a trackable review when a change needs one.
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. SailPoint documents its MCP server for clients such as Claude Desktop and n8n; configure it per SailPoint's developer docs.
// 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 ask "what does fct_forecast_vs_actuals feed, and which raw tables does its dbt project read?".
One request, L0 to L4. The autonomy ladder is set per domain, so Finance can sit at a different level from Marketing.
- •L0 manual. Connected, not acting. Engineers find the job a revoke broke when someone asks why the report is empty.
- •L1 observe. Data Workers reports each failed run and empty period with its blast radius and owners, and logs what each action would have needed.
- •L2 propose. Data Workers proposes the narrow role, the SailPoint owner change and the rerun. Owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the approved rerun once the grant lands, 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. Entitlements still go through SailPoint; Snowflake grants still go to the platform owner.
Read more on safety, how approvals work, the autonomy levels, who owns the agents, where your data goes, every integration and the Identity agent. The same pattern holds for Okta, Microsoft Entra and Immuta.
What changes for your team
Teams lose time to the gap between a certification and the warehouse: the job nobody knew ran under a role, and the restore-the-old-role ticket that undoes a good decision. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A job broken by a revoke arrives traced, with owners named and a fix drafted.
- •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. The narrow grant a pipeline needs is proposed, approved and recorded with its expiry date, and the assignment goes through SailPoint.
- •Audits. Each change links the certification decision, the approvers, the grant 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.
Reviewers keep their attention for what only people decide: who should have access, and why. The CISO guide covers the security leader's view, and Data Workers for SOX, HIPAA, GDPR and the EU AI Act covers the evidence your auditors use.
Keep SailPoint, or consolidate?
Keep SailPoint if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Identity governance stays with SailPoint in almost every estate: it spans hundreds of applications, and certifications are an audit commitment. What teams consolidate is the tooling around it: spreadsheets mapping service accounts to jobs and the ticket queue between the IAM analyst who revoked a role and the engineer who owns the pipeline. For Snowflake specifically, see who queried this table in Snowflake access history, generating RBAC policies for Snowflake and the access risks AI agents bring. Building it yourself? Read build it ourselves with Claude Code and MCP servers: calling SailPoint's API is easy; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: access decisions and the data agree. When a certification pulls access, the broken job is caught overnight, fixed with a narrower grant and rerun before the reports open, and the reviewer's decision stands.
The risk story: Data Workers changes nothing in SailPoint and decides no entitlement. Snowflake grants are proposed for the platform owner to apply; Unity Catalog grants change only after a named approver says yes; every grant is recorded with its justification and expiry date, and each change 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: SailPoint is moving certification from quarterly to continuous, and Agentic Fabric brings machine identities and agents under governance. More decisions, made faster, land on more pipelines nobody mapped. The first win: one finance domain, read-only, reporting each failed run and empty period with its blast radius and owners. What stays the same: your SailPoint licence, campaigns, reviewers and provisioning. Start with a pilot (pricing); it is credited in full against the first year. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "SailPoint decides who should have access; Data Workers makes sure our warehouse and our numbers still match those decisions, with an approval and a receipt for every change."
Getting started
Start with a pilot. Pick the domain where a certification has broken something before, often finance, connect Data Workers read-only to its warehouse, dbt project and orchestrator, and let it report failed runs, empty periods and blast radius through one campaign cycle before turning on the first fix class. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers run access certifications or reviews? No. Certifications and entitlement decisions stay in SailPoint. Data Workers works on the data side: what an access change did to runs, tables and reports, and the narrow grant a pipeline needs.
Does Data Workers write to SailPoint? No. Owner and entitlement changes go to the IAM team as proposals, and role assignments go through SailPoint access requests, so SailPoint stays the record of who holds what.
Will Data Workers just restore the role a reviewer revoked? No. It proposes the narrowest grant the pipeline needs, from the tables its dbt project reads and writes, with an access dry run. The platform owner applies it, and the reviewer's decision stands.
Do grants expire automatically? No. Data Workers records each grant with its expiry date in the access-grants ledger. Nothing revokes on its own at that date: the owner revokes or renews it, and SailPoint's next campaign certifies it.
How does this relate to Agentic Fabric? Agentic Fabric discovers agents and machine identities and ties each to a human owner. Data Workers' agents run under the identities and approvals you set, and each change leaves a receipt that owner can read.
Can we use SailPoint's MCP server and Data Workers in the same assistant? Yes, side by side. SailPoint's MCP server handles access requests (SailPoint documents Claude Desktop and n8n as clients), and Data Workers' MCP servers handle lineage, checks and governance (documented for Claude Code and Cursor). Data Workers' own agents don't call SailPoint's server.
Sources
- •SailPoint, press release: SailPoint eliminates blind spots with unified protection across human, non-human, and AI agent identities (Agentic Fabric GA, Human Fabric; Aug 4, 2026), https://www.sailpoint.com/press-releases/sailpoint-identity-security-solution (checked Oct 3, 2026)
- •SailPoint, press releases list (Entro intent Jun 15 and completion Jun 29, 2026; Cursor Enterprise connector Jul 29; CrowdStrike Falcon Next-Gen SIEM integration Aug 31), https://www.sailpoint.com/press-releases (checked Oct 3, 2026)
- •SailPoint, Human Fabric product page (access certifications, access modeling, Identity Graph), https://www.sailpoint.com/products/human-fabric (checked Oct 3, 2026)
- •SailPoint, Agentic Fabric product page (discovery, human ownership, agent registration), https://www.sailpoint.com/products/agentic-fabric (checked Oct 3, 2026)
- •SailPoint, Data Access Security product page, https://www.sailpoint.com/products/data-access-security (checked Oct 3, 2026)
- •SailPoint documentation, Certifications ("SailPoint Human Fabric remediates the revoked access"), https://documentation.sailpoint.com/saas/help/certs/index.html (checked Oct 3, 2026)
- •SailPoint documentation, Understanding certifications (campaign owner when no manager; automated or manual remediation), https://documentation.sailpoint.com/saas/help/certs/understanding_certifications.html (checked Oct 3, 2026)
- •SailPoint documentation, Snowflake SaaS connector supported features, https://documentation.sailpoint.com/connectors/saas/snowflake/help/saas_connectivity/snowflake/supported_features.html (checked Oct 3, 2026)
- •SailPoint Developer Community, SailPoint MCP Server, https://developer.sailpoint.com/docs/extensibility/mcp (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)