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.
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, redact personally identifiable information (PII) from a model response, 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.
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.
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.
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.
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 and Model Services only. Model Provider Services and Agent Services are not currently supported.