Service policy examples

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.

These custom service policy examples cover common governance scenarios for AI model and MCP services. They fall into two kinds of custom policy:

Deterministic SQL policies: a SQL function that makes an exact, rule-based decision (a tool name, an argument value, a keyword, a length). Use these when the rule is precise and repeatable.
LLM-as-a-judge policies: a natural-language classifier that an evaluator model applies to the request or response. Use these when the check is semantic (intent, topic, tone) and no exact rule captures it.

For the end-to-end procedure to author and attach a policy, see Create and attach a service policy. For the event fields, the return value, and the supported SQL subset, see Service policy function reference. For the built-in guardrails that cover PII, unsafe content, jailbreak, and hallucination without custom code, see Built-in service policies.

Deterministic SQL policy examples

Each example is a SQL user-defined function (UDF) that you register in Unity Catalog and attach to a service. The policy runs at both evaluation points, so each function branches on event:type::string ('request' for ON CALL, 'response' for ON RESULT) and returns an explicit ALLOW for every path it doesn't block.

Note

Service policies are fail-closed: a missing field, an unsupported function, or any evaluation error results in DENY. Always cast a VARIANT path before comparing it to a literal (for example, event:type::string = 'request'), and end each function with an explicit ALLOW branch. The policy body supports only a restricted subset of SQL. See Supported SQL.

Block requests that contain specific keywords

This policy blocks requests to a Model Service or Model Provider Service whose message contains any term on a blocklist, such as an internal project codename. It lowercases the message with LOWER so the match is case-insensitive.

CREATE OR REPLACE FUNCTION main.governance.block_codenames(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND (
            CONTAINS(LOWER(event:context.message::string), 'projectfalcon')
         OR CONTAINS(LOWER(event:context.message::string), 'bluewidget')
         OR CONTAINS(LOWER(event:context.message::string), 'codename-atlas')
      )
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Your request references a restricted internal or competitor codename.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Block requests about restricted topics

This policy blocks requests to a Model Service or Model Provider Service that mention topics the assistant shouldn't engage on, matched by keyword. This is the deterministic form of a topic block. When the topic is nuanced and a keyword list is too blunt, use an LLM-as-a-judge policy instead.

CREATE OR REPLACE FUNCTION main.governance.deny_restricted_topics(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND (
            CONTAINS(LOWER(event:context.message::string), 'lawsuit')
         OR CONTAINS(LOWER(event:context.message::string), 'legal advice')
         OR CONTAINS(LOWER(event:context.message::string), 'investment advice')
      )
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'This assistant does not handle legal or investment topics.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Note

The policy SQL subset matches on substrings with CONTAINS, LIKE, STARTSWITH, and ENDSWITH; regular expressions (regexp_*) aren't supported. Substring matching can't validate a format that depends on structure or a checksum, such as a national ID or an account number. For those checks, use a built-in guardrail where one applies. See Supported SQL.

Limit prompt length

This policy denies requests to a Model Service or Model Provider Service whose message exceeds a character limit. Very long prompts are often pasted dumps or prompt-stuffing attempts, and they raise latency and cost.

CREATE OR REPLACE FUNCTION main.governance.deny_oversized_prompt(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND LENGTH(event:context.message::string) > 8000
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Your prompt exceeds the 8000-character limit for this service.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Require approval when an agent acts on behalf of a user

This policy uses the on-behalf-of (OBO) actor context to hold a write action for human approval when an agent, rather than a person, calls a sensitive tool on an MCP Service. The ASK outcome pauses the call until a person approves it.

CREATE OR REPLACE FUNCTION main.governance.ask_when_agent_writes(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.actor.context.is_on_behalf_of::boolean = true
      AND event:context.tool.name::string IN ('create_issue', 'push_files', 'merge_pull_request')
    THEN to_variant_object(named_struct('result', 'ASK', 'reason', 'An agent is attempting a write action on your behalf. Please confirm.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

For how Azure Databricks delivers the ASK approval prompt to an external agent, see Write a decision policy.

Block responses that expose internal URLs

This policy runs ON RESULT: it inspects the model's response on a Model Service or Model Provider Service and blocks answers that reference an internal-only host. Because it branches on event:type::string = 'response', it evaluates the response rather than the request.

CREATE OR REPLACE FUNCTION main.governance.block_internal_links_in_response(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'response'
      AND (
            CONTAINS(LOWER(event:context.message::string), 'wiki.internal.example.com')
         OR CONTAINS(LOWER(event:context.message::string), 'admin.example.com')
      )
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'The response was blocked because it referenced an internal-only URL.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Block a tool call by its arguments

This policy inspects a tool's arguments and blocks calls that target a protected resource, while allowing every other call. It applies to an MCP Service. The published deny a GitHub push example blocks a tool by name; this one goes a level deeper and checks an argument value.

CREATE OR REPLACE FUNCTION main.governance.block_protected_repo(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.arguments.repo::string = 'prod-infra'
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Actions on the prod-infra repository are not permitted through the agent.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Allow only approved tools

This policy is a default-deny allowlist for an MCP Service: it permits a fixed set of read-only tools and blocks every other tool call. Default-deny is the safer pattern because a tool added to the server later is blocked until you add it to the list.

CREATE OR REPLACE FUNCTION main.governance.tool_allowlist(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.name::string NOT IN ('search_issues', 'get_file_contents', 'list_commits')
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', CONCAT('Tool is not on the approved allowlist for this service: ', event:context.tool.name::string)))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

LLM-as-a-judge policy examples

An LLM-as-a-judge policy uses an evaluator model to classify the request or response against criteria you describe in natural language. Use it for semantic checks that a deterministic rule can't express, such as whether a message is on topic or whether a response stays professional.

To create one, follow the attach a policy procedure, but in Guardrail type select Custom, then set Type to LLM-as-a-judge. Enter your classifier in the Prompt field and select an Evaluator model service (you need CAN QUERY on the model you choose).

You write only the criteria that describe what to flag. Azure Databricks appends a structured output contract to your prompt, so the evaluator returns a JSON decision (a flagged boolean and a confidence score) rather than free text. Don't write ALLOW or DENY in the prompt, and don't specify an output format. When the evaluator flags content, Azure Databricks blocks the interaction.

Note

The examples in this section run on model services and block flagged content. To hold an interaction for human approval instead of blocking it, use the ASK outcome, which applies to MCP services. See Require approval when an agent acts on behalf of a user.

Keep an assistant on topic

This policy runs ON CALL on a Model Service. It flags requests that fall outside the assistant's supported scope, so an assistant built for one purpose isn't used as a general-purpose chatbot.

Prompt:

You are reviewing messages sent to a customer-support assistant that may only help with the company's products, orders, billing, and account support. Flag the message if it asks for something outside that scope, such as general coding help, writing essays, unrelated trivia, or using the assistant as a general-purpose chatbot. Do not flag a genuine product or support question.

Enforce a professional tone

This policy runs ON RESULT on a Model Service. It flags responses that are off-brand or unprofessional, complementing the built-in block_unsafe_content guardrail, which targets harmful content rather than tone.

Prompt:

You are reviewing responses drafted by a public-facing assistant. Flag the response if it is rude, sarcastic, dismissive, condescending, uses profanity, or would embarrass the company if a customer saw it. Do not flag a response that is professional, respectful, and on-brand.

Block regulated advice

This policy runs ON RESULT on a Model Service. It flags responses that give individualized regulated advice, distinguishing them from general, non-advisory information, which a keyword rule can't do reliably.

Prompt:

You are reviewing responses drafted by a financial-services assistant. Flag the response if it provides individualized investment, tax, or legal advice, or a specific recommendation to a person. Do not flag a response that gives only general product information, education, or non-advisory content.

This example blocks flagged responses. Holding an interaction for human approval instead of blocking it uses the ASK outcome, which applies to MCP services, as in Require approval when an agent acts on behalf of a user.

Feedback

Was this page helpful?

Last updated on 2026-07-30

Service policy examples

Deterministic SQL policy examples

Block requests that contain specific keywords

Block requests about restricted topics

Limit prompt length

Require approval when an agent acts on behalf of a user

Block responses that expose internal URLs

Block a tool call by its arguments

Allow only approved tools

LLM-as-a-judge policy examples

Keep an assistant on topic

Enforce a professional tone

Block regulated advice

Related

Feedback

Additional resources