You're on Okta: Okta Decides Who People and Agents Are. Data Workers Checks What Can Still Reach the Warehouse

Your IAM team runs on Okta. Universal Directory holds every person and group, your HR system drives joiners, movers and leavers through Lifecycle Management, and group push and SCIM provisioning carry those groups into Databricks, Snowflake, Tableau and the rest of the estate. Okta Identity Governance runs access requests through Slack or Teams and the certifications your auditors ask about. Since Oktane on September 22, AI agents are identities too: Okta for AI Agents registers them in Universal Directory and governs what they connect to, and Agent SSO, Agent-to-Agent Connections and Resource Access Certifications are generally available. Okta decides who people and agents are and what they can sign into. Data Workers works the hop inside the warehouse: it reads who has left, diffs live grants against the set you intended, traces what still runs under them and proposes each fix to its owner, behind approvals.

Those two jobs meet at every leaver, every renamed group and every service principal someone created by hand.

Key takeaways

• •Okta keeps its job. Identity, SSO, MFA, lifecycle, group push, Identity Governance and Okta for AI Agents stay with your IAM team.
• •Data Workers checks the hop Okta can't see. It reads users, their status and last sign-in, and groups from Okta, diffs live Unity Catalog grants against the intended set, and traces what each schema feeds through the dbt manifest and the context graph.
• •Fixes go to owners, behind approvals. Unity Catalog revokes and grants are applied after a named person approves and then re-read; changes on other platforms are drafted for their owners; Okta changes stay with the IAM team.
• •Your Okta is the front door to Data Workers too. Data Workers' remote MCP endpoint takes your Okta authorization server as the identity provider and verifies every token against its published keys (JWKS). Data Workers issues no tokens.
• •Every change leaves a receipt: the Okta status read, the grants before and after, the approver and the time.
• •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.

Okta knows who still works here. Data Workers knows what can still reach the warehouse.

Okta answers who someone is, whether they still work here and which apps they can open. Data Workers answers what that identity, or anything created alongside it, can still reach inside the warehouse, what runs under it and who fixes what.

Here is a Friday offboarding at a logistics company. HR data lives in the Databricks catalog hr, governed by Unity Catalog. Okta pushes two groups into the Databricks account, dbx-hr-analysts and dbx-data-eng, and the platform team keeps the intended grants for hr in a reviewed file in Git: those two groups plus sp-dbt-prod, the service principal production dbt runs as. In April a contract data engineer ran a payroll migration. They created a Databricks account group by hand, payroll-migration-tmp, added themselves and a new service principal, sp-payroll-migration, granted the group SELECT on hr.payroll_raw, and scheduled an Airflow 2 DAG, payroll_recon_adhoc, that reconciles pay runs into a scratch bucket. When the DAG was merged, the reviewer recorded a context-graph note that it connects as sp-payroll-migration. The migration finished. The group, the principal and the DAG stayed. This is an illustrative example.

Nothing in Okta was wrong. The account was deactivated within an hour, and every app Okta knew about followed. The gap sat one hop inside the warehouse: a group created in Databricks, a service principal Databricks issued and a DAG that kept running under it. The intended set made the hand-made group visible, the lineage showed the revoke was safe for production, and the owners did the parts that were theirs.

Why doesn't Okta just do this itself?

Because Okta is built to be the neutral source of truth for identity across thousands of apps, and its reach ends at each app's boundary by design. Okta provisions a user into Databricks and pushes the groups it owns. It doesn't read Unity Catalog privileges, can't see a group created inside the Databricks account, and has no record of the service principals Databricks issues or the DAGs that sign in as them. Okta's agent work follows the same line. Okta for AI Agents governs agent identities and their connections to apps, MCP servers and other agents. The open-source Okta MCP server, generally available, lets an assistant manage users, groups, apps and policies, and asks the person to confirm deletes and deactivations through MCP elicitation. Auth0 for AI Agents' Token Vault handles the third-party tokens an agent uses on a user's behalf. Each makes identity sharper inside Okta's domain.

Knowing that a hand-made group still grants payroll to a principal a nightly DAG uses, and that production dbt runs under a different principal so the revoke is safe, is data-engineering knowledge. Acting on it touches Unity Catalog, Airflow and the warehouse, each owned by someone else, with an approval, a re-read and a receipt. An identity provider that edited warehouse grants and paused pipelines would carry liability for systems it is meant to stay neutral across. Data Workers is the product on that side of the line, and every change to Okta itself stays with your IAM team.

Every tool owns a slice. Data Workers covers the whole lifecycle

Okta owns its slice: who people and agents are and what they can sign into. 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 Okta already gives you.

How Okta and Data Workers work together

Your people stay in Claude Code, Cursor or Claude, in Okta and in Databricks. Spellbook Data Catalog (in preview) is where the data team looks: each finding, grant diff, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work, and the Autonomous Data-Conductor runs each fix end to end behind per-domain guardrails.

What Data Workers reads from Okta. With an Okta API token, Data Workers reads users (by email), a single user with their status and last sign-in, the groups in your org and a user's admin roles. That answers "has this person left, and when did they last sign in?" next to the warehouse evidence. Group membership per user, app assignments and the mapping from Okta groups to warehouse roles stay in Okta and in your intended-grants file; Data Workers writes nothing to Okta. Your team's own MCP client can run the Okta MCP server side by side with Data Workers' MCP servers; Data Workers' agents don't call it.

What Data Workers writes, and where. In Unity Catalog, it reads live grants, diffs them against the intended set you keep, applies the revoke or grant after a named person approves, then re-reads to confirm. On Snowflake, BigQuery and other platforms it drafts the grant or revoke for the owner to run. When a fix needs new access, it dry-runs the grant first (effective privileges after role inheritance, sensitive columns it would reach, policy conflicts, a least-privilege recommendation with an expiry the owner revokes at). Around Okta it reads Unity Catalog grants, Airflow DAG runs, the dbt manifest and pull requests on GitHub, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis.

Okta as the identity provider for Data Workers. Every Data Workers agent is an MCP server, and the product serves the same tools over Streamable HTTP for remote clients. That endpoint runs in OAuth mode with your Okta authorization server as the identity provider. Okta issues the access tokens; before any tool runs, Data Workers verifies each token's signature against the keys Okta publishes (JWKS), plus the issuer and audience you configure, and refuses every token if no keys URL is set. The tenant comes from a dedicated claim you add in Okta, never from the user's ID. Data Workers issues no tokens and registers no clients. Spellbook approvers sign in through Okta too, so every approval carries an Okta identity.

Example: Okta as the identity provider for Data Workers' remote MCP endpoint
Okta authorization server:  custom server, issuer https://<your-okta-domain>/oauth2/<authServerId>
Audience:                   the value you set for the Data Workers API, e.g. api://data-workers
Keys (JWKS):                https://<your-okta-domain>/oauth2/<authServerId>/v1/keys
Claims in the token:        sub, email, and a tenant claim (tenant_id)
Data Workers endpoint:      OAuth mode; verifies signature (JWKS), issuer and audience per call
Who issues tokens:          Okta only

Setup for the open-source agents. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "dw-governance": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-governance"]
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code), then ask "what reads hr.payroll_raw?"

One request, L0 to L4. Autonomy is set per domain, so HR data can sit at a different level from marketing data.

• •L0 manual. After each offboarding, someone compares Okta exports with warehouse grants in a spreadsheet.
• •L1 observe. It reports each grant outside the intended set and logs what each action would have needed.
• •L2 propose. It drafts the revoke, the account-admin change and the DAG retirement for each owner, who approves before anything runs.
• •L3 act reversibly. For proven classes, such as revoking a grant outside the intended set on a schema with no production reader, it applies the Unity Catalog change and re-reads. One approval restores the grant.
• •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt. Okta changes stay with the IAM team.

More on safety, approvals, who owns the agents, where your data goes, the Identity agent and the Data Access & Governance agent. The same pattern holds for Microsoft Entra, SailPoint and Cyera.

What changes for your team

IAM teams on Okta lose time at the seam with the data team: the grant nobody can explain, the leaver whose job still runs, the auditor asking who approved warehouse access. With Data Workers, those jobs run on autopilot at the level you set.

• •Access. Live Unity Catalog grants are diffed against your intended set; fixes are approved, applied and re-read.
• •Audits. Each change links the Okta status, the grants before and after and the approver; generate_audit_report pulls the record together.
• •Incidents. A revoke that breaks a job arrives traced, with its owner named.
• •Data quality. Nulls, keys and row counts are checked after each run.
• •Cloud spend. Snowflake credits are traced to the dbt model behind them through query tags.
• •Migrations. Each wave is planned with its checks, and the owner signs off before it closes.

IAM engineers keep their week for policy and agent governance; data engineers stop hearing about leftover access from an auditor. The CISO guide covers the leader's side.

Keep Okta, or consolidate?

Keep Okta if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

Okta stays your identity provider. Teams consolidate the glue around it: the offboarding spreadsheet, the scripts that list Databricks groups nobody pushed, the ticket ping-pong between IAM and data. Building it yourself? Calling an MCP server is the easy part; the intended-set diff, approvals, re-reads and receipts are the work. See also MCP server security: auth and audit, AI agents and data access governance risks and audit trail requirements for data agents.

The case for your CFO

The outcome: when someone leaves, their warehouse access leaves too, including the parts Okta never knew about, and you can prove it. Every grant outside the set you intended is found, traced and fixed through its owner, with a record for the auditors.

The risk story is plain. Data Workers changes nothing in Okta. It reads users, status and groups, reads warehouse grants and proposes each change to its owner. Unity Catalog revokes and grants happen only after a named approver says yes, and each is re-read. Other platforms get a drafted change their owner runs. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain, an org-wide stop halts all autonomous dispatch, and the admin kill switch takes two people and revokes the tenant's keys, tokens and sessions. People sign in through Okta; Data Workers issues no tokens. 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 are joining your directory as identities, and every agent and pipeline adds principals inside the warehouse one hop from Okta. The first win is one domain, read-only, with a report of every grant outside the intended set. What stays the same: your Okta tenant, groups, policies and IAM team. The ROI guide shows the math.

The sentence to repeat upstairs: "Okta decides who works here; Data Workers checks what can still reach the warehouse, and every fix comes with an approval and a receipt."

Getting started

Start with a pilot. Pick the domain where leftover access worries you most, such as HR on Databricks, write down the intended grants for its catalog, connect Data Workers read-only to Okta, Unity Catalog, your orchestrator and the dbt project, and let it report every grant outside the set 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 connect to Okta? Yes. With an API token it reads users with their status and last sign-in, groups and a user's admin roles from the Okta API. It writes nothing to Okta.

Does Data Workers sync Okta groups to warehouse roles or deprovision leavers? No. Okta's provisioning and group push own that. Data Workers checks the result: it diffs live Unity Catalog grants against the intended set you keep and applies the approved fix.

Can we use Okta to sign in to Data Workers? Yes. Okta is the authorization server for Data Workers' remote MCP endpoint and for Spellbook. Data Workers verifies every token's signature, issuer and audience against the keys Okta publishes (JWKS). It issues no tokens and registers no clients.

How does this fit with Okta for AI Agents? Okta for AI Agents governs agent identities and what they connect to: Agent SSO, Agent-to-Agent Connections and Resource Access Certifications are generally available, and Agent Gateway is planned. Data Workers' agents act through the access you configure per connection, behind approvals, and every change carries a receipt naming the approver.

Does Data Workers replace Okta Identity Governance certifications? No. Certifications stay in Okta. Data Workers adds the warehouse side: which grants sit outside the intended set and a receipt for every change the reviewers can link to.

What about Snowflake? Data Workers drafts Snowflake grants and revokes for the owner to run. Unity Catalog is where it reads live grants and applies approved changes itself.

Sources

• •Okta, New Okta for AI Agents innovations increase visibility into agent behavior, secure connections at runtime, and enforce continuous agent governance (Sep 22, 2026; availability labels), https://www.okta.com/newsroom/press-releases/ai-innovations-oktane-2026/ (checked Oct 3, 2026)
• •Okta Identity Governance (access requests through Slack/Teams, certifications), https://www.okta.com/products/identity-governance/ (checked Oct 3, 2026)
• •Okta, Cross App Access, https://www.okta.com/integrations/cross-app-access/ (checked Oct 3, 2026)
• •Auth0 for AI Agents, https://auth0.com/ai, and Token Vault, https://auth0.com/features/token-vault (checked Oct 3, 2026)
• •Okta Open Source MCP Server README (generally available; CRUD tools by OAuth scope; elicitation for destructive operations) and releases (v1.1.7, Sep 29, 2026), https://github.com/okta/okta-mcp-server (checked Oct 3, 2026)
• •Okta Developer, Authorization servers (issuer format, custom claims and scopes), https://developer.okta.com/docs/concepts/auth-servers/ (checked Oct 3, 2026)
• •Data Workers agent swarm repository: Okta connector (users, status, last sign-in, groups, admin roles), Unity Catalog grant diff and approved write path with re-read, remote endpoint OAuth verification via JWKS (checked Oct 3, 2026)
• •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)