Service policies for AI securables
This feature is in Beta. Account admins can control access to this feature from the account console Previews page. See Manage 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 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: 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 a type of attribute-based access control (ABAC) policy scoped to AI services. ABAC policies fall into two groups: access control policies (such as grants) decide whether a principal can reach an object, while content policies govern what happens after they do. Service policies are content policies for AI services, the same role that row filter and column mask policies play for tables. As with those, 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 (ON CALL) and after the service responds (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. The caller receives a structured error with an optional reason.
- 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
Databricks evaluates a service policy at two points in every interaction:
- ON CALL: before 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.
- 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 CALL and hallucination detection only ON RESULT).
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. Databricks evaluates policies in ascending rank order at ON CALL (lowest rank first) and in the reverse order at ON RESULT. Use rank to control which checks run first.
The following diagram shows where the two phases sit around a service and what each decision does:
Built-in service policies
Databricks provides built-in service policies in the system.ai catalog. These cover common governance scenarios without custom SQL. The Databricks AI guardrails are built-in service policies: preconfigured, Databricks-managed policies (such as PII and unsafe-content detection) that you attach the same way as a custom policy:
system.ai.block_pii: denies interactions that contain personally identifiable information.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.
To use a built-in policy, attach it to a service. You must have the EXECUTE privilege on the policy function and MANAGE on the target service.
How built-in service policies work
Built-in service policies are LLM-as-a-judge checks: each runs a 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. 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.
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, 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 a request (ON CALL), the last user message on a model service or the tool call and its arguments on an MCP service; for a response (ON RESULT), the model's reply.
The evaluator sees only that single extracted item. It doesn't see the system prompt of the protected service, earlier turns in the conversation, or image and audio content. Because each evaluation is scoped to one message, a built-in service policy can't detect patterns that span multiple messages, such as gradual escalation across a conversation.
Output contract
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, Databricks blocks the interaction by default. If the policy is attached to an MCP service and configured to ask, a flagged result instead pauses the call for human approval. Because Databricks applies the contract for you, built-in service policies need no configuration beyond the phase and rank.
Evaluation cost
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, 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); they don't transform request or response content during the beta.
- Supported services: Service policies apply to MCP Services, Model Services, and Model Provider Services. Agent Services are not supported.
- Single-message evaluation: A built-in service policy evaluates one message at a time, so it can't detect patterns that span multiple messages in a conversation. 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, Databricks skips them when running the evaluation. This prevents recursion.