Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
This feature is in Beta. Account admins can control access to this feature from the account console Previews page. See Manage Azure Databricks previews.
Service policies let you govern the content of interactions with AI services registered in Unity Catalog — including external MCP servers and models from any provider, not just Azure Databricks-hosted ones. Unity Catalog grants determine whether a principal can call a service. Service policies govern how that interaction proceeds, based on the content of the request and response and on who is making the call.
Service policies are the mechanisms you use to implement guardrails for AI services. If you're looking to add guardrails, such as blocking PII, prompt injection, or unsafe content, service policies are the mechanism: Azure Databricks has built-in guardrails for common risks, and you can write custom policies for rules specific to your organization.
This matters most when agents act on behalf of users. An agent inherits everything the user can access, and services often reach external systems. Service policies let you set guardrails on that activity. For example, you can require user consent before an agent pushes code to a Git repository, deny a model response that contains personally identifiable information (PII), or block unsafe content.
Service policies are one of three kinds of attribute-based access control (ABAC) policy in Unity Catalog:
- ABAC GRANT policies grant Unity Catalog privileges on securables whose governed tags match a condition. They control whether a principal can reach an object.
- Row filter and column mask policies control which rows and columns a principal sees in a table.
- Service policies govern the content of each request and response to an AI service, to allow, deny, or hold it for approval.
ABAC GRANT policies are access control; row filter and column mask policies and service policies are content policies, which govern what happens once a principal has access. Like a row filter or column mask, a service policy references a Unity Catalog function that contains the governance logic and attaches it to a securable.
How service policies complement Unity Catalog grants
Unity Catalog privileges and service policies address different governance questions and operate at different enforcement points.
| Unity Catalog privileges | Service policies | |
|---|---|---|
| Question answered | Can this principal call this service? | How must this interaction proceed? |
| Inputs | Principal identity and granted privileges | Request content, response content, tool annotations, and actor context |
| Enforcement point | Before the request reaches the service | Before the service is invoked (input phase, ON CALL) and after the service responds (output phase, ON RESULT) |
| Granularity | Per principal, per securable | Per request, based on content and context |
Service policies don't replace Unity Catalog grants. A principal must first have the appropriate Unity Catalog privileges to call a service. Service policies then evaluate the content of each interaction to enforce additional governance rules.
Policy decisions
A service policy evaluates the content of a request or response and returns one of three outcomes:
- ALLOW: the interaction proceeds.
- DENY: the policy blocks the interaction. Instead of an error status, Azure Databricks returns a successful (HTTP 200) response. The assistant turn carries a short message naming the service policy that blocked, and a top-level
databricks_service_policyobject carries the structured detail, including the blockreason. Returning the block as a normal turn keeps conversational clients that resend the full history, such as coding agents, from re-triggering the same block on every later turn. - ASK: the policy holds the interaction for human approval before it proceeds. This approval step enables human-in-the-loop workflows for sensitive operations. For example, an administrator can approve a destructive MCP tool call before it runs. For external agents calling an MCP Service, this approval prompt is delivered through MCP URL elicitation. See Write a decision policy.
A policy is a SQL user-defined function (UDF) that receives the interaction event (which includes the actor and the request or response content) and returns a decision result.
Evaluation points
Azure Databricks evaluates a service policy at two points in every interaction:
- Input (ON CALL): Before Azure Databricks invokes the service, against the request. Use this phase to inspect requests before they reach the underlying service. For example, block a request that invokes a destructive MCP tool, or deny a prompt that contains PII before it reaches a model.
- Output (ON RESULT): After the service responds, against the response. Use this phase to inspect responses before they return to the caller. For example, block a response that contains hallucinated content or sensitive data.
A custom policy function runs at both points. It inspects the current phase (event:type) and decides how to act, so a single policy can govern the request, the response, or both. To act on only one phase, branch on event:type in the function body. Built-in policies are scoped with a phases option instead, and some run in only one phase (for example, jailbreak detection runs only on the input phase and hallucination detection only on the output phase).
Order of evaluation
You can attach more than one service policy to a service. Each attachment has a rank (priority), and the chain stops at the first DENY. Azure Databricks evaluates policies in ascending rank order on the input phase (ON CALL, lowest rank first) and in the reverse order on the output phase (ON RESULT). Use rank to control which checks run first.
Evaluation within a rank
Azure Databricks evaluates policies at the same rank in two stages:
- Blocking LLM-as-a-judge policies run in parallel. These are the built-in policies that block (
DENY) content, such as unsafe-content detection. Because they are the model-backed checks, running them concurrently means their added latency is roughly that of the slowest single evaluation, not their sum. - The remaining policies then run sequentially, but only if every parallel policy in the first stage allowed the interaction. This stage covers custom SQL policies and policies that pause for approval (
ASK), evaluated in the order you attached them.
Evaluation short-circuits at the first DENY in either stage, so later policies at that rank and all higher ranks don't run. Because Azure Databricks parallelizes the slow model-backed checks, stacking several blocking guardrails on a service doesn't multiply their latency.
The following diagram shows where the two phases sit around a service and what each decision does:
To see the policies attached to a specific service and the order they run in, open the service's Policies tab and click See execution flow.
Built-in service policies
Azure Databricks provides built-in service policies under the system.ai namespace. These cover common governance scenarios without custom SQL. The Azure Databricks AI guardrails are built-in service policies: preconfigured, Azure Databricks-managed policies (such as unsafe-content and jailbreak detection) that you attach the same way as a custom policy:
system.ai.block_unsafe_content: denies interactions that contain unsafe or harmful content.system.ai.block_jailbreak: denies requests that attempt to circumvent model safety instructions.system.ai.block_hallucination: denies responses that contain hallucinated content.system.ai.detect_sensitive_data: detects structured sensitive data (such as credit card numbers and Social Security numbers) and either blocks the interaction or redacts the matched values. Unlike the others, it's deterministic (pattern-based, no evaluator model) and can redact rather than only block. See Detect sensitive data with a service policy.
To use a built-in policy, attach it to a service. You need MANAGE on the target service.
Note
During the beta, the built-in policies are Azure Databricks-managed and don't appear as functions you can browse in the system.ai schema in Catalog Explorer. You select and attach them by name through the Unity AI Gateway UI, as described in Create and attach a service policy.
How built-in service policies work
Built-in service policies are LLM-as-a-judge checks: each runs a Azure Databricks-curated prompt against an evaluator model to decide whether the content violates the policy.
The evaluator model service
Each built-in service policy runs its prompt on an evaluator model service, the model that judges the content. Azure Databricks preselects a default evaluator, so no setup is required. To use a different model, expand Advanced options when you attach the policy and select one; you need CAN QUERY on the model you choose. The evaluator is separate from the service you're protecting, so a policy can judge a request to one model service using a different model as the evaluator.
Azure Databricks maintains the policy's prompt, which is read-only. You can view it under Prompt when you attach the policy to see the exact criteria the evaluator applies.
What the evaluator receives
When a built-in service policy runs, Azure Databricks sends the evaluator a request with two parts:
- A system message that contains the policy prompt and an output contract (described in the following section).
- A user message that contains the content under evaluation: for the input, the last user message on a model service or the tool call and its arguments on an MCP service; for the output, the model's reply.
The evaluator sees only that single extracted item. It doesn't see the system prompt of the protected service or image and audio content. By default each evaluation is scoped to one message, so a built-in service policy can't detect patterns that span multiple messages, such as gradual escalation across a conversation.
For input evaluation on model and model provider services, you can increase this window. When you attach the policy, set how many recent conversation turns the evaluator receives, and it sees that window of turns instead of only the latest message. This applies to the input only, and isn't available on MCP services.
Output contract
Azure Databricks automatically appends a JSON output contract to the policy prompt, so the evaluator returns a structured decision instead of free text. The evaluator returns:
flagged(boolean):trueif the content violates the policy's criteria.confidence(float,0.0to1.0, optional): the evaluator's confidence in the decision.reason(string): a short explanation of why the content was flagged. Returned whenflaggedistrue.
When the evaluator returns flagged: true, Azure Databricks blocks the interaction by default. On an MCP service, a policy configured to ask instead pauses the request for human approval before the tool runs. Because Azure Databricks applies the contract for you, built-in service policies need no configuration beyond the phase and rank.
Evaluation cost
Azure Databricks doesn't charge a separate fee for built-in service policies. Each evaluation is billed like any other call to the evaluator model service, so the cost depends on how that model is served. The tokens billed for each evaluation cover the policy prompt, the output contract, the extracted message, and the evaluator's response. To limit overhead, keep the number of policies per phase small and prefer a low-latency evaluator model.
Supported services
During the beta, you can attach service policies to the following Unity Catalog service securables:
- MCP Services: managed, external, and custom MCP servers.
- Model Services: hosted and external LLM endpoints.
- Model Provider Services: governed external model providers.
Fail-closed behavior
Service policy evaluation uses fail-closed semantics. When you attach a policy through the Unity AI Gateway, Azure Databricks validates it at attach time, and any error during evaluation results in DENY. Errors include user errors in the policy function, system errors, missing fields in the request context, and timeouts.
A misconfigured or broken policy blocks the interaction rather than allowing it through.
Limitations
The following limitations apply during the beta:
- Transformation: Service policies return a decision (ALLOW, DENY, or ASK) and don't transform request or response content during the beta. The one exception is the built-in
system.ai.detect_sensitive_datapolicy, which can redact matched values on model services. - Supported services: Service policies apply to MCP Services, Model Services, and Model Provider Services. Agent Services are not supported.
- Single-message evaluation: By default, a built-in service policy evaluates one message at a time. For input evaluation on model and model provider services, you can increase the window to a number of recent conversation turns. Output evaluation and MCP services remain single-message. See How built-in service policies work.
- Nested evaluation: If the evaluator model service you select for a built-in service policy has its own policies attached, Azure Databricks skips them when running the evaluation. This prevents recursion.