How do enterprises enforce AI guardrails?
Summary
- Enterprises enforce AI guardrails by intercepting every model request at a control point between applications and models, checking both the prompt and the response against policy, and blocking, masking, or escalating anything that violates it.
- Enforcement has to live outside the model and the prompt: a guardrail a user can talk the model out of isn't a guardrail, so it runs on every request automatically rather than the ones a developer remembered to check.
- On Databricks, guardrails are applied to model and agent traffic through the Unity Gateway using service policies, which evaluate the request before the model runs and the response after it returns.
- Built-in checks cover sensitive-data detection and masking, jailbreak and prompt-injection defense, unsafe-content filtering, and grounding, each returning an allow, deny, or human-approval verdict; because models, agents, and tools are governed as Unity Catalog objects, one set of policies applies across every agent and every decision is logged.
How do enterprises enforce AI guardrails?
Enterprises enforce AI guardrails by routing every model request through a control point between their applications and their models, checking both the incoming prompt and the outgoing response against policy, and blocking, masking, or escalating anything that breaks a rule. The enforcement has to be external to the model and the prompt. A guardrail you can talk the model out of is not a guardrail, and one that runs only when a developer remembers to call it gets skipped exactly when it matters. On Databricks, that enforcement point is the Unity Gateway, which applies guardrails to model and agent traffic through service policies.
What are AI guardrails?
AI guardrails are runtime checks that govern the content and behavior of AI traffic. They screen for personal data, unsafe or toxic output, prompt-injection and jailbreak attempts, off-topic responses, and answers that aren't grounded in approved sources. They differ from prompt engineering: a system prompt asks a model to behave, while a guardrail enforces the rule whether or not the model complies, so it holds up when a user tries to jailbreak the model.
Capabilities to evaluate
| Capability | Why it matters |
|---|---|
| Request and response screening | Inspect both the incoming prompt and the model's output, since sensitive data and unsafe content can show up on either side. |
| Sensitive-data detection | Detect and mask or block personal data (names, emails, payment card numbers) before it reaches a model or a user. |
| Prompt-injection and jailbreak defense | Catch attempts to override system instructions, using semantic detection that generalizes to new phrasing. |
| Unsafe-content filtering | Block toxic, harmful, or otherwise disallowed output. |
| Grounding checks | Validate a response against approved source material before it goes back to the caller. |
| Enforcement verdicts | Allow, deny, or route to a person for approval, so high-risk actions get a review step. |
| Central management and audit | Define policies once, apply them across every agent, and log every decision. |
How Databricks approaches guardrails with the Unity Gateway
Databricks enforces guardrails through the Unity Gateway, the governed control point for model and agent traffic, using service policies attached to a model service. Models, agents, and tool (MCP) services are registered as Unity Catalog securable objects, so a policy applies to the traffic no matter which application sent it.
A service policy evaluates a request in two phases:
- On call, before the model runs, it inspects the incoming request to catch prompt-injection attempts or personal data in the user's input.
- On result, after the model responds, it inspects the output to catch unsafe content, ungrounded answers, or sensitive data on the way back to the caller.
Each check returns one of three verdicts: allow, deny, or ask (route to a person for approval). The policy chain stops at the first deny, so a blocked request never reaches the model. On a hit, the gateway can reject the request, mask the sensitive values, or require approval, and every decision is logged for audit.
Databricks ships built-in guardrails for the common risks: detecting unsafe content, catching jailbreak and prompt-injection attempts, checking a response for grounding, and detecting sensitive data such as names, emails, and payment card numbers through the built-in system.ai.detect_sensitive_data function. The content guardrails use an LLM-as-judge approach with an editable prompt and a configurable evaluator model, so detection generalizes to novel phrasing instead of matching a fixed keyword list. For rules specific to your business, you can add custom guardrails as an LLM-as-judge classifier or a deterministic SQL function, for example denying a response that gives regulated advice or restricting an agent to approved topics.
Guardrails and service policies are evolving quickly, so confirm the current availability and lifecycle state in the Databricks documentation or with your Databricks account team before you design around a specific behavior. For a hands-on walkthrough, see the tutorial on adding service-policy guardrails to a model service.
Use cases
- Protect personal data: mask names, emails, and card numbers in both prompts and responses so a customer-facing agent cannot leak them.
- Defend against manipulation: block prompt-injection and jailbreak attempts before they reach the model, independent of the system prompt.
- Keep agents on task and reviewed: restrict responses to approved topics, deny off-scope requests, and route high-risk actions to a human approval step.
FAQs
How are guardrails different from a system prompt?
A system prompt shapes what a model intends to do; a guardrail enforces what's allowed. A guardrail that denies a request blocks it even if the prompt, or a user, tells the model otherwise, which is why guardrails hold up against jailbreak attempts and prompt injection.
Do guardrails check the model's output, or only the input?
Both. Service policies evaluate the request before the model runs and the response after it returns, because sensitive data, unsafe content, and ungrounded answers can appear on either side.
What happens when a guardrail is triggered?
Depending on the policy, the gateway rejects the request, masks the offending values, or requires human approval, and it logs the decision.
Can I write guardrails for my own domain rules?
Yes. Alongside the built-in checks, you can add custom guardrails as an LLM-as-judge classifier for nuanced content or as a deterministic SQL function for precise, rule-based decisions.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.