How to safeguard AI workloads with Unity AI Gateway Guardrails

No company wants to appear in the next news headline about a security breach caused by AI. Governing and securing AI usage is a multi-faceted endeavor; for example, the latest version of the Databricks AI Security Framework lists 97 industry-vetted AI security risks and 73 available controls for those risks on the Databricks Platform. When deploying AI agents, organizations should implement all necessary controls to ensure safe, secure and compliant use. LLM guardrails are one of the core governance and security controls that apply to the majority of use cases. 

Beyond security, guardrails also serve to protect against the disclosure of a company’s sensitive data - from the user to the model or vice versa. They can protect against harmful or offensive uses of AI, ensure generated content aligns with product branding strategies, and keep chat conversations on topic. 

Today, we are announcing LLM Guardrails in Unity AI Gateway, now in beta! This release builds on an earlier version of guardrails in the Gateway; in particular, it uses LLM-powered guardrails to expand and improve the performance of pre-built guardrails and offers a highly tunable custom guardrail option. In this blog post, we’ll show you how to use these guardrails to mitigate against multiple AI security and compliance risks.  

Scenario: Acme Co. defines guardrails for generative AI 

Acme Co.'s marketing team is launching an AI assistant to help draft campaigns. Acme’s CIO has established some blanket company policies for LLM usage, including:

• No customer PII may leak into model prompts
• All model prompts must be screened for jailbreak and prompt injection attempts
• AI cannot be used to generate harmful or unsafe content

Additionally, the marketing team is very mindful of protecting their brand image and of taking the high road in competition. For this campaign, they have decided to avoid disparaging competitors or even naming them. 

The marketing team secured a budget to use AI for this project and worked with the AI platform team to obtain access to an LLM to power their assistant. Let’s take a look at how the platform team can configure a Unity AI Gateway Endpoint for this project. 

Building a governed AI endpoint with Unity AI Gateway

The teams agreed that a capable, general-purpose model like GPT-5.4 would work well for their use case and budget. They start by configuring an endpoint to use that model. 

They also set up inference tables to monitor the guardrails and ensure they’re working properly. 

As for guardrails, they map their business requirements against the various types of guardrails. 

Setting up the guardrails that require the built-in templates is straightforward:

1. From the AI Gateway page for the endpoint, go to the Guardrails tab. 
2. Click the + Add Guardrail button 
3. In the Create guardrail modal, choose the Guardrail type. In our example, we’ll create one for PII redaction, one for Jailbreak, and one for Unsafe Content. See Databricks documentation for details about each of the types. 
4. Configure the guardrail to meet the business requirement. For the PII guardrail, we want to configure it to redact PII on the input. Each built-in guardrail has a predetermined action (i.e., block vs. sanitize) and prompt. Optional configurations for the built-in guardrails include:
   1. A default evaluator endpoint (e.g., databricks-gpt-5-nano) that can be changed as needed to improve performance or manage costs.
   2. Under Advanced Mode, the option to run the guardrail in Log mode rather than the default Enforce mode. This option is helpful when adding new guardrails to an endpoint that receives live traffic, minimizing disruption to users while testing the guardrail.  
5. Once satisfied with the guardrail configuration, we click Create Guardrail to deploy the guardrail. 

We repeat the same process for the Jailbreak and Unsafe Content Guardrails. For the last guardrail - avoiding references to competition - we will use a Custom guardrail. We give it a name, elect to block outputs that violate the guardrail and fill in the default prompt template to meet the business requirements. 

Now they move on to testing the guardrails with some representative prompts. 

Testing guardrails against jailbreaks, PII, and unsafe outputs

The Acme team begins sending sample prompts to the guardrail-enabled endpoint via a notebook, observing guardrail behavior in both the notebook and the endpoint’s inference table. 

The guardrails all worked as expected, except for the custom guardrail. The Acme team looks at the tips for custom guardrails in the Databricks docs and realizes they might have underspecified the guardrail. For example, 

• They didn’t specify Acme Co’s business (specialty coffee vendor)
• They didn’t list specific competitors (e.g. Highline)
• They didn’t give any few-shot examples

They iterate on the original custom guardrail prompt to address these gaps and come up with a much more specific and thorough prompt:

They try this prompt with gpt-5-nano and gpt-5-mini as the evaluator endpoint, but still don’t get reliable guardrail performance. When they switch to gpt-5-4-mini, they find that the custom guardrail triggers as expected, without degrading any of the other guardrail tests, so they select 5.4-mini as their initial evaluator endpoint. 

As a best practice, they also plan to capture more live traffic via inference tables, curate false positives and false negatives for the custom guardrail and make further adjustments to the prompt and/or model to achieve the right balance of precision, recall, cost and latency. 

Auditing guardrail activity with inference tables

The Acme team sees the guardrail effects in the inference tables of the marketing team endpoint and the evaluator endpoints. 

• On the inference endpoint, usage tracking records one row per request, including blocked ones. Passing and sanitized requests record real token usage with status 200. Input-blocked requests record status 400 with 0 input and output tokens. Output-blocked requests record status 400 with the destination model's actual token counts.
• On the evaluator endpoint, the inference table records one row per guardrail call, with the request body describing what the evaluator receives, the evaluator's raw JSON response, latency, status code, and timestamp. 
• The inference endpoint's inference table and the evaluator endpoint's inference table share the same request_id. They can join this field to trace a guardrail decision back to the originating client call.

They can create reports and dashboards on these inference tables to track and understand guardrail usage in conjunction with the marketing campaign. If users complain about overly sensitive guardrails, the AI platform team can validate individual users’ sessions by analyzing the actions taken within each session. 

Try out LLM Guardrails in Unity AI Gateway today! 

LLM Guardrails in Unity AI Gateway are available in beta today. See our documentation on how to enable them. Start by enabling guardrails for endpoints handling sensitive prompts, external tools, or customer-facing outputs, then use inference tables to monitor and refine guardrail behavior over time.