Databricks Unity Gateway and Contextual Service Policies vs Data Workers Autonomy Guardrails

Your platform team just put every agent on Databricks behind one front door. Unity Gateway (formerly AI Gateway) routes model traffic, caps AI spend per user, and holds agent calls to MCP services against service policies. Since September your engineers can point Claude Code or Codex at it with the ug CLI, and a policy can make a coding agent stop and ask before it merges a pull request. Security is happier than it has been all year.

Then a coding agent's dbt change, approved at the gateway, ships a renamed column. By the afternoon a Genie Agent is reporting null customer tiers and two dashboards are wrong. Every call was logged. Nobody saw what the change would break.

That's the gap this page is about, and it's a narrow one. Unity Gateway governs the traffic: which calls an agent may make, at what cost and with what content. Data Workers governs the data change: how far it reaches, who must approve it at which autonomy level, whether it worked, and how to undo it. Data Workers is the agentic data platform: 20+ specialist agents, one governed context graph and autonomy guardrails set per domain from L0 manual to L4 fully autonomous, with a receipt on every change. Gateway policies are the right control for model and tool traffic. Keep them. Put Data Workers behind them for the changes that touch your data.

Key takeaways

• •Unity Gateway is the control point for AI traffic on Databricks. One API for models and coding agents, routing and fallbacks, rate limits, budgets with hard caps, unified tracing, and service policies that allow, deny or hold a call for approval. The Unity Gateway API went GA on September 16, 2026; service policies (launched as Contextual Service Policies) are Beta.
• •A gateway sees a call, not a blast radius. A policy reads the tool name, its arguments, the content and the caller. It can't see which dbt models, Snowflake tables, Genie Agents and dashboards a change will reach, and it doesn't check the data afterwards or undo the change.
• •Data Workers governs the change itself. It scopes the blast radius across platforms before a write, routes the change to the right approver for that domain's autonomy level, verifies the data downstream, and records a receipt with a rollback path.
• •Autonomy is set per data domain, observe-only to fully autonomous, so freshness reruns can act on their own while schema changes still wait for a named person.
• •Use both. The gateway governs the call into Data Workers; Data Workers governs what that call changes. Your policies, budgets and traces keep applying.
• •Zero migration. Unity Gateway, Unity Catalog and your service policies stay exactly as they are.

Going further. For the full picture on a Databricks stack, read Data Workers on Databricks. For building versus buying the agents behind the gateway, read Agent Bricks vs the Data-Agents Swarm. For the catalog side, read Unity Catalog vs Spellbook Data Catalog.

Your estate, and where the seams are

Most Databricks teams we talk to run more than Databricks. Salesforce and product events land through Fivetran. dbt models build in Snowflake on an Airflow schedule. Databricks reads some of those tables through Lakehouse Federation, and Genie Agents answer questions on top. Tableau or Power BI sits over all of it. Coding agents now open pull requests against the dbt repo, and Agent Bricks agents call tools on behalf of users.

Unity Gateway sits at one seam: between those agents and the models and MCP services they call. It's a good place for a control point, because every agent call passes through it. The incidents that hurt, though, happen at the other seams: a column renamed in dbt that a federated table depends on, a grant that widens access in two systems, a pipeline rerun that double-loads a fact table. Those seams are about data, and they run across systems the gateway never sees.

Six things Data Workers adds on top of Unity Gateway

1. Blast radius before the write. The Data Change Review agent reads lineage across dbt, Airflow, Snowflake and BI, and attaches a report to the change: which models, tables, Genie Agents and dashboards it reaches, and who owns them. The approver sees that report, not a tool name and a JSON blob.

2. Autonomy set per data domain. On the Autonomous Data-Conductor, the dial runs from L0 manual through L1 observe, L2 propose, L3 act on reversible changes, to L4 fully autonomous. You set it per domain: which agents can write, how far a change may spread, and what still comes to a human. Every deployment ships observe-only.

3. Approvals with context, in one inbox. Spellbook Data Catalog (in preview) is a single approvals inbox where every change arrives with its receipt, diff and rollback. A named human approves anything irreversible.

4. Verification after the change. The Conductor runs detect, diagnose, fix, review, verify and remember. After a change lands, it re-runs the checks on the changed tables and the baselines downstream before it calls the work done.

5. Receipts and reversal. Every change carries a receipt with who or what acted, why, what it touched, the blast radius and how to undo it, recorded in a tamper-evident decision trail. No agent can promote its own work to authoritative or canonical.

6. One context graph across every platform. Data Context Wizard joins Unity Catalog grants and metric views with your dbt manifest, Airflow state, Snowflake query history and BI metadata through 50+ connectors. That graph is what makes the blast radius and the verification possible.

One incident, five systems

Here is a scenario many Databricks teams will recognize. It's an illustrative example.

• •14:02. A developer asks a coding agent, connected through Unity Gateway, to tidy up dim_customers. It opens a pull request in the dbt repo that renames cust_tier to customer_tier.
• •14:05. The agent calls the GitHub MCP tool merge_pull_request. A service policy modelled on Databricks' own "ask when agent writes" example holds the call for approval.
• •14:07. An engineer sees the tool name, the repo and the PR number, and approves. The PR merges.
• •15:00. Airflow runs dbt. dim_customers rebuilds in Snowflake with the new column name. A downstream view maps the missing cust_tier to null, so three models built on it write null tiers.
• •15:20. A Genie Agent in Databricks reads the table through federation and reports null tiers to the sales team. Two Tableau dashboards show every account as unclassified.

The gateway did exactly what it should: it made an agent ask before writing to a repo. What it couldn't do was tell the approver what the write would break, notice when it broke, or put it back. That's the data side of the job.

What Unity Gateway covers, as of October 2026

Databricks calls Unity Gateway "an AI Gateway that routes requests, limits AI spend, manages fallbacks, monitors usage, and connects coding agents to model capacity." Here is what its documentation and release notes say ships today.

This is a strong control point. Policies can read request and response content, tool annotations, tool arguments and the actor, including whether the call is on behalf of a user. Databricks' examples include holding push_files and merge_pull_request for approval, blocking pushes to a protected repo, and restricting pushes to approved agents. One documented limit to know: during the Beta, service policies don't attach to Agent Services.

Why doesn't Unity Gateway just do this itself?

Focus, and risk. A gateway sits in the call path, so it has to be fast, neutral about what each tool does, and judged one interaction at a time. Databricks built Unity Gateway to be that control point for models, MCP services and coding agents, and that's the right design for governing traffic. A gateway that tried to understand every tool's side effects would be slow and fragile, and it would sit in front of every call.

Knowing the blast radius of a data change is a different product. It needs lineage across Snowflake, dbt, Airflow and BI, the owners of each asset, checks that run after the change lands, and a way to undo each kind of change in each system. It also means taking responsibility for changes in tools Databricks doesn't own: your dbt repo, your Airflow deployment, your Snowflake account. Data Workers is that product, and it runs behind the gateway.

One platform, not one more tool

AI traffic governance is one slice of a data team's year. The same team keeps the catalog current, writes quality checks, closes incidents, changes pipelines, handles access, cuts spend and produces audit evidence. Every point tool adds another console, another contract and another handoff.

Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score the same ten stages on every comparison page. Unity Gateway leads on two, both home ground: security and privacy, through service policies, and models, through routing and fallbacks.

Unity Gateway vs Data Workers on the guardrails you need

The ten-stage view shows breadth. This view scores eight guardrail outcomes a data leader needs before letting agents change production data. Unity Gateway leads on three, all about traffic. Data Workers leads on the five that decide whether a data change is safe.

These are directional scores of scope, not benchmarks. We've shown the reasoning so you can check every line.

Where Unity Gateway stops

Each limit comes from Databricks' own documentation, and each follows from being a gateway rather than a data-change system.

It judges a call, not a change. A policy's inputs are request content, response content, tool annotations and actor context. A rename in a dbt PR looks like any other merge_pull_request call. What it breaks lives in lineage the gateway doesn't hold.

An ASK holds the call; it doesn't brief the approver. The approval prompt reaches the person through MCP URL elicitation, and the docs don't describe routing it to the owner of the affected data. The approver decides on what the call shows.

Per-domain autonomy is yours to encode. You can write SQL policies on tool names, arguments and caller. Turning that into "freshness reruns act alone, schema changes wait for the domain owner, access grants need two people" across every data domain is design work your team owns.

Traffic that doesn't pass through the gateway isn't seen. Airflow runs, Snowflake jobs and BI refreshes don't go through Unity Gateway. Neither does the damage a change does after it lands.

Logs are not receipts, and nothing is undone. System tables, inference tables and unified tracing record what was called. A record that ties a data change to its reason, diff, blast radius, approver and undo path, and the act of undoing it, sit outside the gateway.

Where the two overlap

What it costs

Unity Gateway has no separate list price we could find. Model traffic bills through Databricks Foundation Model APIs or your provider, and you can set a price multiplier where you've negotiated a discount. The bigger cost of the gap is people: the engineers who would write per-domain SQL policies, lineage lookups, verification jobs and undo scripts, and keep them current.

Data Workers is a flat platform fee. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing.

The fastest first win: a blast radius on every agent PR

Pick the dbt repo your coding agents already push to. Run the Data Change Review agent and register it as an MCP service in Unity Catalog, so Unity Gateway governs calls to it like any other tool. Set the domain that owns that repo to L2 propose. From then on, every PR an agent opens gets a blast-radius report and lands in Spellbook for the domain owner, and your existing ASK policy on merge_pull_request still holds the merge. The approver now says yes or no knowing what the change reaches. After a few weeks of approving reversible fixes as written, open L3 for freshness reruns in that domain and keep schema changes at L2.

What each Data Workers product does

Data-Agents Swarm. 20+ specialist agents for pipelines, incidents, quality, schema, data change review, access and governance, security, identity, cost, migration, observability, streaming, ingestion and MLOps. Each is an MCP server, so each can sit behind Unity Gateway.

Autonomous Data-Conductor. Owns an outcome rather than a step. It runs detect, diagnose, fix, review, verify and remember, scopes the blast radius before acting, and holds the autonomy dial for each domain.

Data Context Wizard. One governed context graph across every platform. It reads Unity Catalog grants, imports metric views and joins them with dbt, Airflow, warehouse and BI metadata, with the source and time of every fact.

Spellbook Data Catalog. The business-user app and control plane for agent work: one approvals inbox with receipt, diff and rollback on every change, and asset pages for the whole estate. Approval requests also reach the team in Slack or email.

Autonomy guardrails and security

Unity Gateway governs agents at the call. Data Workers governs data work at the domain, so trust grows one domain at a time.

• •Every deployment ships observe-only. You open the rope per domain as the receipts pile up.
• •Five levels. L0 manual, L1 observe, L2 propose and wait for approval, L3 act on reversible changes, L4 fully autonomous.
• •Per domain, three settings: which agents can write, how far a change may spread, and what still comes to a human.
• •Propose first, with a sandboxed dry run. A named human approves anything irreversible.
• •Every applied change carries a receipt with its blast radius and a rollback path, in a tamper-evident decision trail.
• •No agent can promote its own work to authoritative or canonical.
• •Least privilege. Data Workers acts with the grants you give it, through each platform's own permissions, including Unity Catalog. Your Unity Gateway policies, budgets and traces still apply to every call into it.

"Our service policies already require approval. Isn't that enough?"

It's the right control for the call, and you should keep it. An ASK on merge_pull_request or a DENY on a protected repo stops the worst surprises at the door. What it can't supply is the judgment behind the approval: how far this change reaches, which domain owner should see it, whether the data is right afterwards, and how to put it back. You could write that logic as SQL policies plus lineage lookups plus verification jobs, and some teams will. Every Data Workers agent is already an MCP server that does it, so registering it behind the gateway gives you both: the gateway decides whether the call may happen, and Data Workers decides whether the change is safe.

How it fits together

Here's the pattern, over MCP today. Data Workers agents run over streamable HTTP in your environment. You register them as MCP services in Unity Catalog, so Unity Gateway's access control, rate limits, budgets, service policies and tracing apply to every call into them, from coding agents connected with ug or from Agent Bricks agents. When a call asks for data work, Data Workers reads its context graph, scopes the blast radius, proposes or makes the change at the level you set for that domain, verifies it, and returns the result with a receipt. People review in Spellbook. Nothing moves; Data Workers stores metadata and scrubbed facts, not copies of your tables.

The case for your CFO

The outcome. Agents can change production data without the change becoming tomorrow's incident. Wrong numbers get caught, reversed and verified the same afternoon, and the approvals your engineers give carry the information they need.

The risk story. Every domain starts observe-only. At L2 agents propose and a person approves; at L3 they act only on reversible changes you've opened for that domain; L4 is for domains that have earned it. Every write is scoped before it runs, a named human approves anything irreversible, and each change leaves a receipt with who or what acted, why, what changed, the blast radius and how to undo it. No agent promotes its own work. Zero migration: nothing is copied or moved.

Why now. Unity Gateway went GA in September and the ug CLI put coding agents on it, so agents are about to write to your repos and tables at volume. The gateway decides which calls they may make. Somebody has to own what those calls change.

The first win. A blast-radius report on every agent PR to the dbt repo, in propose mode, behind your existing gateway policy.

What stays the same. Unity Gateway, service policies, budgets, Unity Catalog, dbt, Airflow and Snowflake. Your policies keep applying.

The pilot path. Start with a pilot; the pilot is credited in full against the first year. See pricing.

The sentence to repeat upstairs: Unity Gateway decides which calls our agents may make; Data Workers decides which data changes they may make, proves they worked, and can undo them.

When Unity Gateway alone is enough

Unity Gateway alone can be enough if your agents only read: they answer questions, summarize documents and draft code that a person reviews and ships by hand. In that world, routing, budgets, content guardrails and call-level approvals cover the risk. Once agents merge, rerun, grant or migrate on their own, the risk moves from the call to the change, and that's where Data Workers runs behind the gateway.

FAQ

What is Databricks Unity Gateway? Unity Gateway, formerly AI Gateway, is Databricks' control point for AI traffic. It gives agents one API to models, MCP servers, coding agents and skills, with access control, rate limits, fallbacks, budgets, tracing and service policies. The Unity Gateway API is GA as of September 16, 2026.

What are Contextual Service Policies? Databricks announced them in June 2026 as policies that allow, deny or require approval for agent actions such as pushing code or touching sensitive data. In the current docs they're service policies (Beta) that return ALLOW, DENY or ASK based on request and response content, tool arguments and the caller.

Can Unity Gateway see the blast radius of a data change? No. A policy sees the call: tool, arguments, content and caller. Which dbt models, tables, Genie Agents and dashboards a change reaches lives in lineage across your platforms. Data Workers computes that before the change runs and shows it to the approver.

Does Data Workers replace Unity Gateway? No. Keep Unity Gateway for routing, budgets, content guardrails and call-level policies. Register Data Workers agents behind it over MCP, so the gateway governs the calls and Data Workers governs the data changes.

Do Unity Gateway policies apply to Data Workers agents? Yes, when you register them as MCP services in Unity Catalog. Every call into them is then subject to your access control, rate limits, budgets, service policies and tracing.

What happens if a Data Workers change goes wrong? Every change is scoped before it runs, approved or reversible at the level you set for the domain, verified afterwards, and recorded with a receipt and a rollback path. For a change another tool made, Data Workers traces it and proposes the revert for approval.

How much does Data Workers cost? A free Apache 2.0 core, a $7,500 one-time pilot, Scale from $1,000 a month and Enterprise from $3,000 a month (billed annually), with unlimited seats and no usage meter. See pricing.

Sources

Unity Gateway capabilities and statuses come from Databricks documentation, release notes and blog posts, checked October 2, 2026:

• •Unity Gateway (updated Sep 29, 2026)
• •AI governance with Unity Gateway (updated Sep 29, 2026)
• •Service policies for AI securables (Beta, updated Sep 22, 2026)
• •Service policy examples (updated Sep 11, 2026)
• •Release notes, September 2026: Unity Gateway API GA, compliance profile, ug CLI, coding-agent tracing and configuration
• •Release notes, February 2026: AI Gateway Beta
• •AI governance at Data + AI Summit 2026: Unity Gateway (Jun 16, 2026): Contextual Service Policies Beta, unified tracing

Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.