Use cases / Databricks

Let Databricks
agents work.
Keep control.

Let agents put your data to work. Keep consequential changes within your business limits, with the right approvals and a record of the outcome. Even in one Databricks workspace.

Request a briefing Try a decision

One Databricks workspace. Three decisions.

Sample data

HOLD/ production-change

The right owner decides.

Changing 2,800 production rows needs Sales Operations approval. The exact change waits before dispatch—even though the work never leaves Databricks.

01 / Agent + data

Databricks

Reads via Unity Catalog
Approved account summary

Native access controlsPreserved

02 / Independent authority

GovernorAI

Governed tool adapter
Production change policy

Before dispatchHOLD

03 / Action

Production table

table.update_many

2,800 rowsAwaiting approval

Data context: prod.crm.account_health_summary
Sensitivity: Internal · approved summary
Business purpose: Revenue planning
Decision reason: Bulk change requires Sales Operations approval

Business limits, not session limits

The limit follows the change set.

SESSION 01

Already committed1,600

This request2,800

Total if executed4,400

Change-set ceiling5,000

Within the change-set ceiling. Above the 100-row approval threshold.

Inspect this decision

WORKSPACE revenue-prod / AGENT revenue-opsON BEHALF OF maya.chen

DATABRICKS-ONLY WORKFLOW

Same Databricks workspace. Native permissions preserved. Your business policy stays in charge.

A new session cannot reset the production-change allowance. The same Q4 change set stays under the same 5,000-row-change ceiling.

Inspect the policy behind these decisions

{
  "native_authorization": "required",
  "data_movement": {
    "deny_sensitive_unapproved_destination": true
  },
  "production_change": {
    "approval_above_rows": 100,
    "change_set_limit": 5000,
    "approver_role": "sales-operations-owner"
  },
  "stopped_agents": "deny_new_governed_calls"
}

Illustrative configuration used by this example. Reviewed policy stays connected to the action it governs.

Follow the decision, not just the trace.

SHA-256 · sample chain

Preparing sample record…

Synthetic events. Hashes are computed in your browser; no backend is contacted.

✓ Limits that follow the work✓ The right owner approves✓ Decisions tied to outcomes

One workspace. Real business consequences.

Try a routine update, a sensitive copy or a consequential production change.

Native controls stay in place

All inside Databricks. The business still needs boundaries. Useful work proceeds; a consequential step gets the right decision.

In the product

See a consequential action held for its owner, in the console.

Recorded on a demo tenant: decisions at the action boundary, a held action with its reason, what each enforcement point can execute, and the record every decision leaves.

Inside GovernorAI/ Runtime enforcementRecorded demo tenant

Governed actions, step by step

Real product screens from a demo tenant with seeded activity: the outcome, the rule and the reason for each governed action.

Watch the full 2-minute walkthrough →

Recorded against a demo tenant with seeded activity. Real product screens, not a mock-up.

Works with the Databricks foundation
your teams already rely on.

Unity CatalogUnity GatewayAgent BricksMLflow

Why GovernorAI—even in one workspace?

Give agents more autonomy.
Keep business authority.

Keep your Databricks foundation. Bring business limits, accountable owners and production operations into one repeatable governance workflow.

01 / Business continuity

The limit follows the work.

Keep the same business allowance across agent sessions, retries and cooperating agents. A restarted conversation is not a fresh permission slip.

Same change set · Same limit · New session

02 / Approval hold

Hold the change for its owner.

Put the responsible owner in the decision and record it. An approval does not release the held change, and whatever the agent asks to do next is a new request.

Named owner · Recorded decision · No release

03 / Independent authority

Your business owns the boundaries.

Separate agent development from policy approval, exceptions and evidence review. Give the right people authority to set and enforce the rules.

Developer ≠ policy owner ≠ approver

04 / Scoped intervention

Stop one agent. Not the business.

Deny an agent’s next governed calls when it goes off course. Keep unrelated work moving and preserve the history of what already happened.

Stop the agent · Preserve useful work

05 / Release to runtime

Assure before release. Govern in production.

Keep the reviewed agent, tools and policy connected to runtime behavior. Make release decisions and operational control part of the same process.

Reviewed snapshot → governed execution

06 / Accountable outcomes

Know why. Know what happened.

Join the rule, approval, action and observed result. Give engineering, security and audit one decision story instead of a manual reconstruction.

Decision → dispatch → observed outcome

The reason to buy

Build agents—not a governance process for each one.

Keep native controls. Add one maintained workflow for business policy, approvals, intervention and evidence. Start with one consequential action; reuse the operating process as you grow.

One export, end to end.

In this example, Unity Catalog and Unity AI Gateway govern the data and the model call, and the outbound connection is governed by GovernorAI.

Databricks In this example, the configured Unity Catalog grants let the job read the contacts table, and the AI Gateway allows the model call.
GovernorAI The egress agent, pinned to the cluster by policy at create, asks GovernorAI for a decision before the outbound connection opens. The destination is not on the configured list, so the connection is refused.
Record The decision record names the cluster, the destination, the rule that decided and the outcome, outside the workspace.

Independent authority. Native integration.

Keep Unity Gateway.
Add business-owned control.

Native governance remains your foundation. GovernorAI brings business owners, agent teams and operators into one independently controlled process around it.

The Databricks foundation

Strong native governance.

Unity Catalog and Unity Gateway govern access, models and tools—including external services. Keep the controls your platform teams already operate.

AccessIdentity, permissions and governed services

Runtime policyRequest and response checks; allow, deny and approval

VisibilityUsage, tracing and cost controls

Explore the native foundation

GovernorAI / Your independent layer

Your rules. Your operating process.

Operate business-case limits, accountable exceptions and decision evidence without assembling that process separately for every agent—even within one workspace.

Own the ruleNamed policy owners, reviewed changes and business-case limits

Hold the actionThe right approver and a recorded decision

Operate and proveScoped intervention; linked decisions and observed outcomes

Independent authority means separately controlled roles and evidence—not a requirement to leave your cloud.

Keep the native controls you trust.
Put your business process around the authority you give agents.

Connect where the work happens

Deep Databricks integration.
Four ways to put policy to work.

Model calls, tool actions and workload egress need different control points. Bring them under one enterprise governance model.

01 / Native gateway · before dispatchUnity Gateway

Bring your rules to the gateway.

Connect enterprise policy to governed model and MCP interactions. Preserve native authorization, use the gateway’s control points, and link its decisions to the wider workflow.

Model services · Model providers · MCP services

02 / Model boundary · before dispatchModel Serving

Govern the model call.

Protect model requests and responses on the governed endpoint path. Start with one endpoint, verify the configuration change, and keep a tested path back.

Inference policy · Response protection · Verified rollout

03 / Workload boundary · before the connection opensNotebooks + jobs

Keep egress on approved routes.

Combine workload configuration, network controls and runtime policy so notebooks and jobs use the routes you govern. A cluster policy pins the egress agent at cluster create, and each outbound connection is checked before it opens. Monitor drift as the environment changes.

Approved destinations · Route verification · Drift detection

04 / Action boundary · before dispatchAgent + MLflow SDK

Decide before the tool acts.

Evaluate the action’s arguments before dispatch. Hold a high-impact change for its business owner, deny an unsafe step, or stop an agent with a kill switch.

Tool arguments · Human approval · Agent kill switch

Start with one consequential workflow. Keep the reviewed policy attached to the decisions that follow.

Usage, not just inventory

Find the activity
your policies are missing.

Connect account-wide inventory with observed usage, traces and governance decisions. See where the trail connects—and where your team needs to act.

One account-level view.

Bring workspaces together with service-principal authentication and a shared policy inventory.

Reconcile activity to decisions.

Find observed calls that lack a matching governance decision, and turn them into a coverage investigation.

Make visibility gaps actionable.

Separate unmatched activity from missing telemetry. Give each finding an owner and a next step.

GOVERNANCE COVERAGEIllustrative data · 24 hours

Model Serving / fraud-scorerLinked decisions

1,248 observed calls · 1,248 matched decisions
Next: review policy outcomes

Notebook / customer-exportNeeds investigation

32 observed calls · no matched decision
Next: verify routing and trace correlation

Workspace / finance-sandboxVisibility gap

Usage feed not connected · coverage unknown
Next: connect telemetry before assessing coverage

The decision is only half the story

One platform.
A complete decision story.

Follow the business context, policy, approval and observed result in one trail. Give the responsible owner a complete decision story—not a collection of disconnected logs.

Control-ready.Follow the policy, approval and action through the record.

Signed exports, where enabled for the deployment.Verify evidence bundles against the deployment’s public keyring through GovernorAI’s verify endpoint.

Keep your investigation tools.Bring governance context to Lakewatch and your SIEM.

Inspect an example record

GOVERNANCE RECORDSample data

Who acted, and for whom?

revenue-ops → maya.chen · Databricks

What was being attempted?

table.update_many · 2,800 rows → Production table

Which policy decided?

production-change → HOLD

Did the action execute?

Held before dispatch; awaiting the named owner

Matching policyTrace correlationExportable evidence

This card follows the selected example above.

Confidence for the platform team

Start with one endpoint.
Keep a verified way back.

A controlled change, read back from Databricks. Start small, measure the effect, and expand on evidence.

01 / Snapshot

Capture the original.

Record the selected endpoint’s configuration and recovery state before applying a change.

02 / Apply

Make the scoped change.

Apply the agreed configuration without letting concurrent operations collide.

03 / Verify

Read back the result.

Confirm the endpoint state before reporting success. A failed update stays a failed update.

04 / Restore

Prove the way back.

Restore the captured configuration and verify the result against the original snapshot.

Assurance before release

Assess before it ships.
Govern while it runs.

Evaluate the agent snapshot against agreed release criteria. Keep pass, blocked, unreachable and unauthorized outcomes distinct in the pipeline.

Explore agent assurance

Govern everywhere

Strong on one platform.
Ready for the rest.

Start in Databricks. Extend the same business limits, policy ownership and evidence process across clouds, SaaS and private infrastructure—without starting over.

GovernorAIBusiness policy · Accountable owners · Evidence

One governance model

AWSCloud + agents

Google CloudData + agents

AzureEnterprise AI

DatabricksStart here

SaaSBusiness actions

Hybrid + privateYour infrastructure

Any cloud. Any platform. Hybrid by design.
The value starts before your second platform.

See how one policy governs everywhere

Questions worth asking

How it fits
your environment.

We only use Databricks. Why add GovernorAI?

Because business authority matters inside one workspace. Keep a change-set limit intact across sessions, send the exact consequential action to its responsible owner, stop an agent when necessary, and reconstruct the outcome. GovernorAI brings those controls into one repeatable operating process around the Databricks foundation you already use.

Could we build this using native Databricks controls?

You could assemble parts of it, and native governance stays essential. What it does not give you is the maintained operating process around it: policy ownership, business-case continuity, approval holds, release assurance and evidence. GovernorAI is that process, so your team builds agents—not a governance process for each one.

Does GovernorAI replace Unity Catalog or Unity Gateway?

No. Keep your native permissions and runtime controls. GovernorAI adds the business-owned operating process. Approval cannot grant data access or override a native denial.

Does a new agent session reset the business limit?

No. The limit belongs to the trusted business case or change set, not the conversation. Committed work stays counted against that scope. In the example, a new session cannot turn 1,600 committed row changes into a fresh 5,000-row allowance.

Does one approval cover the agent’s next action?

No. An approval records a decision on one held change, and it does not release that change either. The next action is a new request: it must satisfy policy, native permissions and the remaining business allowance on its own.

What happens when we stop an agent?

Governed calls that carry the agent’s id are denied while unrelated work continues. In-flight work needs its own handling; completed actions are not reversed. The record keeps earlier decisions and observed results.

How do we start?

Bring one consequential Databricks workflow. Together we name the policy owner, identify the control points and agree the success criteria for a six-week design-partner evaluation. No second platform is required.

Controls proved on real workAllowed, held and blocked outcomes.

Operating impact measuredReview effort, overhead and useful completion.

A decision story to reviewPolicy, approval and observed outcome.

A scoped production planSuccess criteria and the next deployment.

Your next production workflow

Bring one workflow.
Keep the authority.

Prove business control on Databricks. Keep the platform your team already trusts.

Request a briefing Six-week design-partner evaluation →

Continue

Govern EverywhereOne policy across your AI stack Runtime EnforcementDecide at the action boundary ContainmentAgent-scoped kill switches Evidence & ComplianceHash-chained audit record, mapped to controls Data leakageIn prompts, completions and tool calls AWS BedrockInbound path, guardrail sync

Let Databricks agents work.Keep control.