What is AI runtime security?

Summary

• AI runtime security refers to real-time protection mechanisms applied to AI interactions (prompts, responses, tool calls, agent actions) as they flow through the platform, enforcing policies before and after model calls.
• Databricks Unity Gateway provides runtime security through Service Policies that make real-time decisions on AI traffic: ALLOW, ASK (human approval), or DENY, catching risks like prompt injection, PII, and hallucinations.
• Built-in guardrails include PII blocking, unsafe content detection, jailbreak prevention, and hallucination detection, while custom policies can be written in SQL, CEL, or LLM-as-judge classifiers.
• Runtime security integrates with Unity Catalog governance so data access controls, row filters, and column masks also govern which users and agents can invoke specific models and tools.
• Comprehensive logging to Delta tables and inference tables enable audit trails and proactive monitoring of all AI model and agent inputs and outputs across the enterprise.

What is AI runtime security?
AI runtime security refers to real-time protection and governance mechanisms applied to AI interactions as they flow through a system. These interactions include prompts sent to models, responses received, tool calls initiated by agents, and actions taken as a result. Effective runtime security operates at two critical moments: before the model call (catching prompt injection and sensitive input) and after (detecting hallucinations and blocking sensitive output). It's the difference between a policy that exists on paper and one that actually stops threats before they reach users or expose data.

How runtime security works

Runtime security functions as an enforcement layer that evaluates AI traffic in real time. Databricks Unity Gateway implements this through Service Policies, which make a decision on every single request: ALLOW it, ASK for human approval, or DENY it. This happens synchronously, so policies block or approve interactions before they propagate.
The timing is critical. Pre-call policies catch risky inputs before they reach the model, preventing prompt injection attempts and stopping PII from being sent to external APIs. Post-call policies inspect the model's response before it reaches the user, detecting hallucinations and preventing sensitive data from being leaked.

Protection capabilities

Unity Gateway offers multiple layers of runtime protection:

Protection Layer	Built-in Guardrails	Custom Policy Options
Input filtering	PII blocking and redaction	SQL/CEL deterministic rules; LLM-as-judge classifiers
Threat prevention	Jailbreak prevention; unsafe content detection	Custom classifiers for domain-specific threats
Output monitoring	Hallucination detection	LLM-as-judge validation; deterministic checks
Tool governance	Logs all tool invocations	Python-based policies (coming August) for custom tool logic

Built-in guardrails require no authoring and run immediately. Custom policies enable organizations to define domain-specific rules in SQL, CEL (Common Expression Language), or by using language models as judges to validate outputs against custom criteria.

Partner ecosystem integration

Databricks integrates leading AI security vendors directly into Unity Gateway's runtime layer. Partners provide specialized threat detection and policy enforcement. Organizations can use these integrations to detect and block threats such as prompt injection attacks, data exposure, unsafe content, and malicious tool use in real time, all without building custom detection logic.
This open partner ecosystem approach means you can layer additional runtime security on top of Databricks built-in guardrails, allowing each organization to configure security depth appropriate to their risk profile.

Access control integration

Runtime security extends Unity Catalog's existing governance model. Data access controls, attribute-based access controls (ABAC), row filters, and column masks that protect data also extend to AI interactions. This means:

• Fine-grained access determines which users and agents can invoke specific models.
• Agents inherit row-level and column-level restrictions when querying data for context.
• Tool access is gated by the same governance policies used for human database access.

This unified approach prevents security from fracturing: instead of data governance in one system and AI governance in another, both flow through the same policy engine.

Monitoring and observability

All requests and responses flow through Unity Gateway and are logged to Delta tables in Unity Catalog. This creates an audit trail for compliance and enables proactive detection. Inference tables provide centralized monitoring of all AI model and agent inputs and outputs across the enterprise, making it possible to identify policy violations, suspicious patterns, and drift in agent behavior.
The monitoring capability transforms runtime security from reactive (responding to incidents) to proactive (spotting threats as they emerge).

FAQs

What is the difference between runtime security and static security?

Static security checks systems before deployment (code review, vulnerability scanning). Runtime security monitors live interactions as they happen. Both are necessary. Runtime security catches what static checks missed and adapts to new threats that emerge after deployment.

Do built-in guardrails cover all security risks?

Built-in guardrails address the most common threats (prompt injection, PII exposure, hallucinations). For domain-specific or industry-specific risks, custom policies let you define additional rules. Most organizations use both: guardrails for baseline protection, custom policies for their specific threat model.

How much latency does runtime security add?

Runtime security policies are enforced at the gateway layer as part of the normal request flow. For built-in guardrails, the latency is minimal. Custom LLM-as-judge policies add latency proportional to the LLM inference time. Organizations typically configure guardrails for latency-sensitive paths and reserve LLM-as-judge for higher-risk operations that can tolerate additional latency.

Can runtime security policies be bypassed?

No. Policies are enforced at the Unity Gateway layer, which is the central control point for all AI interactions. Agents and users cannot bypass the gateway to access models directly (outside the governance perimeter). All traffic flows through the policy engine.

How do I audit what security policies blocked or approved?

All policy decisions are logged to Delta tables and appear in Unity Catalog audit logs. You can query these logs to see which policies approved or denied requests, when, by whom, and why. Inference tables make this data queryable and explorable through SQL or AI interfaces.