What are AI guardrails?

Summary

• AI guardrails are runtime policies that control what agents can do, enforcing security and governance rules on model calls, tool access, and data interactions.
• They extend your data governance model to AI workloads, applying familiar controls like column masking, row filtering, and role-based access to agent decisions.
• Guardrails prevent unauthorized data access, enforce compliance boundaries, and stop agents from taking unapproved actions in connected systems.
• They work by intercepting every interaction (model call, tool invocation, data query) and evaluating it against defined policies before it executes.
• Guardrails are especially critical in production AI where agents need to act on behalf of users with sensitive access or work with confidential data.

What are AI guardrails?
AI guardrails are runtime security policies that govern what agents can do, who can use which models, and what data agents can access or modify. They act as a control layer that sits between your agents and your enterprise systems, enforcing rules on every interaction.
Think of guardrails as the enforcement mechanism for your AI governance. They answer operational questions like: Can this agent call this tool? Can it see this sensitive column? What budget limits apply? Has policy been violated? Instead of relying on agent behavior alone or hoping for compliance, guardrails intercept and evaluate every request in real time.

What makes guardrails different from traditional governance?

Traditional data governance controls who accesses data tables. Guardrails extend that model to AI workloads, adding a layer of control over what agents can do with that data or with connected systems.
In a traditional data warehouse, you might mask sensitive columns to certain roles. With guardrails, you can do the same thing for agents acting on behalf of users. If an agent is reading HR data as a user, it sees only the columns that user is authorized for. If an agent tries to call a tool (like GitHub or Jira) on behalf of a user, it runs with that user's permissions, not higher privileges.
Guardrails are also distinct from prompt injection defenses. They're not about preventing a user from tricking an agent into breaking its instructions. They're about preventing an agent (even a correctly functioning one) from taking actions outside its allowed scope.

Key capabilities to evaluate

Capability	Why it matters
Access control (RBAC)	Determine which teams, individuals, or agents can use which models, tools, or data. Essential for preventing unauthorized model usage.
Content protection	Mask, filter, or redact sensitive data before returning it to agents. Prevents accidental exposure of PII or confidential information.
Rate limiting and budgets	Cap how many model calls an agent or team can make, and set hard spend limits. Protects against cost explosions and runaway usage.
Interaction policies	Apply rules to specific actions: require approval before certain tool calls, log agent actions for audit trails, or deny access based on context.
User delegation (OBO)	When agents act on behalf of users, enforce the same row-level and column-level permissions the user would have themselves.
Monitoring and audit	Capture every model call, tool invocation, and policy decision in an audit log. Supports compliance and debugging.

How Databricks approaches guardrails

Databricks implements guardrails through Unity Gateway and the governance model of Unity Catalog. Every agent, model, MCP (Model Context Protocol server), and skill is registered as a securable object in Unity Catalog.
When an agent makes a request, it flows through Unity Gateway, which evaluates it against policies defined in Unity Catalog:

• Asset governance: Models, MCPs, and agents are stored in Unity Catalog with standard privileges (EXECUTE, CREATE SERVICE, MANAGE). You grant or deny access the same way you govern data tables.
• Access policies: Use identity-aware rules to grant teams or users access to approved models and tools. Grant a team EXECUTE on all models tagged "approved" without managing each model individually.
• Service policies: Apply runtime interaction rules. For example, require an ASK policy that prompts for approval before an agent can call certain tools, or apply masking that redacts sensitive columns when the agent acts on behalf of a user.
• Content protection: Use column masking and row filtering. When an agent queries customer data acting OBO a user, it gets only the rows and columns that user can see.
• Cost attribution and limits: Set budgets per team, per agent, or per user. Track spending down to individual model calls and tool invocations in the Unified Trace Table.

Guardrails are enforced consistently across all agents in your workspace, whether they're Genie Agents, Genie Code agents, or external frameworks connected via Databricks Model Serving.

Common use cases

Financial services compliance: A bank deploys customer service agents that need to access account data but must never see unencrypted SSNs or account numbers. Guardrails mask those columns regardless of what the agent requests, ensuring regulatory compliance automatically.
Multi-tenant SaaS: A platform hosts customer-specific agents. Guardrails enforce row-level security so Agent A never sees Tenant B's data, even if the agent logic is identical.
Cost control for coding agents: A company gives engineering teams access to Claude for coding tasks but wants to prevent token runaway. Guardrails set monthly spend limits per team and alert when usage spikes.
Tool governance: Agents need access to GitHub, Jira, and Slack, but not all of them should be able to call all tools. Guardrails grant some agents GitHub access (EXECUTE privilege on the GitHub MCP) while denying others.

FAQs

How do guardrails differ from prompt engineering?

Prompt engineering helps shape what an agent intends to do. Guardrails enforce what it's allowed to do. A guardrail that denies a tool call will block it even if the agent is instructed to call it; that's the point. Guardrails are the safety layer that survives prompt injection and user manipulation.

Can guardrails stop all bad outcomes?

No. Guardrails prevent unauthorized access and enforce policy at runtime, but they can't catch every logical flaw in an agent. If an agent has permission to call a tool and follows the right steps but reaches the wrong conclusion, that's an agent quality issue, not a guardrail failure. Guardrails work alongside monitoring and observability.

Do guardrails add latency?

Guardrails evaluate every request, which adds some overhead. Databricks implements policy evaluation efficiently in the Unity Gateway path, but for extremely latency-sensitive applications, policy complexity should be kept reasonable. Most customers see negligible impact.

Who manages guardrails?

Guardrails are typically managed by platform admins and security/governance teams. Admins define policies in Unity Catalog; agents and teams don't redefine them per application. This centralization is part of what makes guardrails scalable.