Skip to content

SYSTEM Cited by 1 source

Service Policies (Unity Catalog)

Service Policies are Databricks' Unity Catalog mechanism for per-tool-call admission control on registered MCP servers. They are UC functions, managed in UC and attached to registered MCPs in Unity Catalog, that evaluate every tool invocation before execution and return a ternary verdict: allow, deny, or request user consent. On deny, the call is blocked; the layer is fail-closed by design.

Why a separate layer beyond OBO permissions

OBO token passing answers "can this user reach this tool?" but not "should this specific tool call proceed in the context of this request?". The distinction is load-bearing:

"We recognized that the same principle applies at runtime, not just at access time. Knowing that an agent is allowed to call GitHub doesn't tell you whether it should delete a file or merge a pull request." — Source: sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog

The argument: permissions are too coarse to reason about runtime context. A developer authenticated to a GitHub MCP server has the right to commit code; whether this commit should land — to this repo, with this message, on this branch — is a runtime decision keyed on tool name, arguments, and caller identity, not on the static permission grant.

Three load-bearing properties

  1. Policy is code. "Service Policies, which are UC functions, managed in UC and attached to registered MCPs in Unity Catalog." The structural payoff: policies inherit UC's existing policy-as-code lifecycle — versioning, audit, ownership, governance — without a parallel control plane. The same engine that evaluates ABAC + row-filters + column-masks evaluates Service Policies.
  2. Policy is attached to the tool, not the agent. Per the source: "attached to registered MCPs in Unity Catalog." A single policy applies to every agent that calls the MCP, regardless of which framework built the agent. This is the governance-travels-with-resources property — applied to tool admission control.
  3. Verdict is a ternary, not a boolean. "the policy returns allow, deny or asks for user consent." The consent outcome is first-class — a policy can require human-in-the-loop confirmation rather than just blocking. Three outcomes (allow / deny / consent) instead of two are how the runtime control surface absorbs cases that are too risky to allow but too disruptive to outright deny.

Architectural shape

agent
  │
  │ tool call (name + args + identity)
  ▼
Unity AI Gateway (enforcement fabric)
  │
  │ pre-execution policy lookup
  ▼
Unity Catalog (policy substrate)
  │
  │ Service Policy = UC function bound to this MCP
  │   evaluates(tool_name, args, caller_identity) →
  │     allow │ deny │ consent
  ▼
        ├─ allow   → proceed to MCP
        ├─ deny    → fail-closed (call blocked, audit-logged)
        └─ consent → return consent prompt → user → re-eval

Decision inputs (named in the post)

  • Tool name — which MCP function is being called.
  • Arguments — the parameters of the call (e.g. for a GitHub MCP, the file path, branch name, commit message).
  • Identity of the caller — which authenticated user (or service principal) is the OBO subject.

The post does not disclose:

  • Whether the policy sees the request body of the LLM call (i.e. the prompt that produced this tool call) or only the synthesised tool arguments.
  • Whether the policy can mutate the call (modify args, redact fields) vs only return a verdict.
  • Whether policies compose (multiple policies on one MCP) and how their verdicts combine.
  • The policy DSL / function signature in detail.
  • Latency overhead per call.

Position in Pillar 1 (Delegated access)

Service Policies are the middle layer of the three-layer composition the post canonicalises (patterns/three-layer-agent-control):

Layer Granularity What it controls Why it's not enough alone
Permissions (OBO) Per-user-per-resource Who can call what Coarse — ignores runtime context
Service Policies Per-tool-call Whether this specific tool call should proceed in the context of this request Late if model already produced sensitive content
Guardrails Per-request payload What content flows in and out Generic — blind to identity

"In practice, these three layers work together: permissions control who can call what. Service Policies control whether a specific tool call should proceed in the context of a given request. Guardrails control what content flows in and out." — Source.

Relation to existing wiki primitives

  • Generalises concepts/runtime-policy-enforcement to MCP tool calls. The pre-existing wiki canonicalisation of runtime-policy-enforcement (from the 2026-04-27 LangGuard post) frames the synchronous-gate-before-execution contract; Service Policies are the MCP-tool-call instance of that contract, with UC functions as the policy DSL substrate.
  • Sibling to patterns/dynamic-content-filtering-in-mcp-pipeline (Redpanda Connect's HBase-cell-ACL-grade per-call filtering on Bloblang/Starlark/Python). Both treat the MCP boundary as a programmable policy point; Redpanda's instance is in the data-pipeline layer with full programming-language extension, Databricks' is in UC with policy-as-code function-bound-to-MCP shape.
  • Companion to UC ABAC + UC Data Classification. UC is "not just where governance is recorded but where it is expressed, evaluated, and enforced." Service Policies extend UC's enforcement surface from data access to tool-call admission.
  • Mediated by systems/unity-ai-gateway — the enforcement fabric that calls into UC for every tool invocation: "every model call, every tool invocation, every agent interaction flows through the gateway. Each one is evaluated against policies defined in Unity Catalog before it executes."

Linked deeper-dive

The post links to a companion deeper-dive titled Stop Rogue AI: How Unity Catalog Secures Your Agent Actions (databricks.com/blog/stop-rogue-ai-how-unity-catalog-secures-your-agent-actions) — not yet ingested.

Seen in

Source

Last updated · 542 distilled / 1,571 read