Custom Guardrail Policies: SQL Rules, LLM Judges, and Evaluation Order

1.Deterministic SQL policies for exact rules

On Databricks, a guardrail is a service policy: a Unity Catalog function attached to an AI service that inspects each request before the model runs (input phase, ON CALL) and each response after it (output phase, ON RESULT). The built-in guardrails handle common risks such as jailbreaks and unsafe content. Some malicious inputs are specific to your organization, though. A user might fish for a confidential project codename, or try to push the assistant onto topics it must not handle. For rules like these you write a custom policy.

The simplest custom policy is a deterministic SQL function. It is a SQL UDF that takes (event VARIANT) and returns a decision, and the message text is read from event:context.message. Use this kind of policy when the rule is precise and repeatable, such as a keyword, a tool name or a length. A custom function runs at both evaluation points, so an input-only rule branches on event:type and acts only when the value is 'request'. The tutorial's codename blocker does exactly that:

CREATE OR REPLACE FUNCTION main.governance.block_confidential_codename(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND contains(lower(event:context.message::string), 'project aurora')
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Requests about confidential projects are not permitted.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

The same pattern covers other kinds of hostile input. A keyword list can deny restricted topics such as legal or investment advice. A length check can deny very long prompts, which are often pasted dumps or prompt-stuffing attempts and also raise latency and cost. Keep in mind how narrow the SQL subset is. Matching is done on substrings with CONTAINS, LIKE, STARTSWITH and ENDSWITH, and regular expressions (regexp_*) are not supported. A format check that depends on structure or a checksum, such as a national ID, belongs to a built-in guardrail.

CREATE OR REPLACE FUNCTION main.governance.deny_oversized_prompt(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string =  ? 
      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;

Sources12

2.Custom LLM-as-a-judge policies for intent

Keywords are a blunt tool against an attacker who simply rephrases. When the check is about meaning, such as intent, topic or tone, and no exact rule captures it, use an LLM-as-a-judge policy. You set it up like any other policy: choose Custom as the Guardrail type, set Type to LLM-as-a-judge, write a classifier in the Prompt field, and pick an Evaluator model service, which needs CAN QUERY. One example input-phase judge flags requests outside a support assistant's scope, so that an assistant built for one purpose isn't used as a general-purpose chatbot.

You write only the classification criteria. Databricks appends an output contract, so the evaluator returns a flagged boolean and a confidence. Don't write ALLOW or DENY in your prompt, and don't specify an output format. This matters for injection in particular: Databricks wraps the content under evaluation and tells the evaluator to treat it as untrusted data, not as instructions, so a prompt cannot simply tell the judge to let it through.

Sources2

3.Stacking guardrails: rank, stages and fail-closed

A service usually carries several guardrails, and each attachment has a rank. On the input phase, policies are evaluated in ascending rank order, lowest first. On the output phase the order is reversed. The chain stops at the first DENY. That is why the tutorial gives the unsafe-content guardrail rank 1 and the custom codename policy rank 10, so a harmful prompt is rejected by the managed check before any custom rule runs.

Policies that share a rank run in two stages. First, the blocking LLM-as-a-judge built-ins run in parallel, so their combined latency is roughly that of the slowest one. The custom SQL policies and ASK policies then run one after another, but only if every parallel policy allowed the interaction. So stacking several blocking guardrails does not multiply latency. To see the actual order on a service, open its Policies tab and click See execution flow.

Policies also fail closed. A missing field, an unsupported function or any evaluation error results in DENY. A SQL policy that compares an uncast VARIANT path, or that has no final ALLOW branch, will therefore block legitimate traffic rather than let it through. Always cast, for example event:type::string = 'request', and end with an explicit ALLOW.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A custom SQL policy can use a regular expression to catch structured identifiers in a prompt.Why is that wrong?

   The policy SQL subset supports only substring matching. For format or checksum checks, use a built-in guardrail.

   Covered in Deterministic SQL policies for exact rules

2. 2.A custom judge prompt should end by telling the evaluator to answer ALLOW or DENY in a fixed JSON format.Why is that wrong?

   Databricks appends the output contract itself. Your prompt should state only the classification criteria.

   Covered in Custom LLM-as-a-judge policies for intent

3. 3.If a policy function errors, the gateway lets the request through so the app keeps working.Why is that wrong?

   Service policies fail closed: any evaluation error results in DENY.

   Covered in Stacking guardrails: rank, stages and fail-closed

Practise it for real

Protect a Model Service against jailbreaks and a confidential-codename probe, then verify both guardrails in the playground.

1. 1.In AI Gateway, open your model service's Policies tab, click New policy, choose Guardrail type Jailbreak, set Rank 1, and create it.

   Why: The managed jailbreak judge covers prompt-injection attempts without code. It runs on requests only. The Unity Gateway beta features must be enabled for your account, and you need MANAGE on the service.

   You should see: The policy is listed on the service's Policies tab.

2. 2.Run CREATE OR REPLACE FUNCTION main.governance.block_confidential_codename(...) from the tutorial in a schema where you hold CREATE FUNCTION.

   Why: The organization-specific rule needs a SQL UDF that branches on event:type::string = 'request'.

   You should see: The function is registered in Unity Catalog.

3. 3.Attach it with New policy, Guardrail type Custom, select the function, set Phase to Input guardrails (Before the Model) only, and set Rank 10.

   Why: It is a request policy, and the higher rank makes it run after the managed check on the input phase.

   You should see: Both policies appear on the Policies tab, and See execution flow shows their order.

4. 4.Wait a couple of minutes, click Chat in playground, and send: Tell me about Project Aurora.

   Why: During the beta, policy changes take a short time to propagate.

   You should see: The request is blocked with the reason: Requests about confidential projects are not permitted.

5. 5.Send an ordinary prompt.

   Why: This confirms the guardrails don't block legitimate traffic.

   You should see: A normal completion is returned.