Skip to main content

How do I prevent AI agents from bypassing user permissions?

Summary

  • Use on-behalf-of (OBO) user authentication so agents inherit the permissions of the end user making the request, not a service principal.
  • Apply Unity Catalog fine-grained access controls (privileges, row filters, and column masks) consistently to all agent tool calls and data access.
  • Implement service policies (guardrails) to control which tool calls succeed at runtime, returning allow, deny, or user consent prompts.
  • Register agents, MCP services, tools, and models as Unity Catalog securables with appropriate grants and permission controls.
  • Enforce governance at the SQL engine level inside the Databricks compute layer, not the network layer, so no application can bypass UC controls.
  • Add serverless egress controls and workspace bindings to prevent data exfiltration and unintended production state changes.

How do I prevent AI agents from bypassing user permissions?

Preventing AI agents from bypassing user permissions requires a multi-layered governance approach built on Unity Catalog. The foundation is on-behalf-of (OBO) user authentication, which ensures agents inherit the invoking user's permissions in real time. Governance is enforced at the SQL engine level inside the Databricks compute layer, not the network layer, preventing applications from circumventing controls. Complement this with service policies, register AI assets as Unity Catalog securables, and add containment controls.

On-Behalf-Of (OBO) User Authentication

When an agent accesses data, it must use the permissions of the end user making the request, not a service principal. The agent inherits the invoking user's permissions in real time, and every action is logged against both the user and the agent.
Critical: Do not place a gateway between the agent and internal Databricks services in the OBO path. If a gateway re-issues its own token, the original user identity is lost and row filters evaluate to the gateway's identity, breaking data governance.

Fine-Grained Access Controls

Control Purpose
Privileges Define what actions agents can perform on tables, schemas, models, volumes.
Row filters Automatically restrict data so users see only rows matching their attributes.
Column masks Hide sensitive columns from users outside specific groups.

These controls apply to agents automatically because agents inherit user permissions. Row filters and column masks protecting data in SQL queries also protect data accessed through agents.

Service Policies for Tool Call Governance

Service policies (guardrails) are Unity Catalog functions that control tool calls at runtime. They evaluate each tool call based on the tool name, arguments, and caller identity, then return allow, deny, or request user consent. This prevents sensitive operations like deleting tables, exfiltrating data, or calling external APIs even if technically permitted by privileges.

Registering AI Assets as Unity Catalog Securables

Govern all AI system components through Unity Catalog:
Agents as Unity Catalog models with standard grants. MCP Services (external tools like GitHub, Jira, Slack) as securables with permissions and audit logging. Custom Tools as Unity Catalog functions governed with the same privileges as data tables. Models with access controls so only authorized users and agents can call them.

Enforcement at the SQL Engine Level

Unity Catalog enforces governance at the SQL engine level, not the network layer:
Universal. Row filters, column masks, and grants apply regardless of which service issues the query (Genie, Agent Bricks, notebooks, or BI tools). No bypass. Applications cannot circumvent UC governance because enforcement happens inside the Databricks compute layer, not the network. Cryptographic. Unity Catalog validates policies to ensure they cannot be bypassed by altering network traffic.

Containment Controls

Serverless egress controls restrict outbound network access and cloud storage writes. Define a deny-by-default posture, explicitly allow only trusted destinations, and prevent writes to non-sanctioned buckets.
Workspace bindings limit catalog access from specific workspaces to prevent agents in development from accessing production data or state.

Implementation Steps

  1. Grant and revoke access to MCP services and models using the same privileges applied to tables.
  2. Attach service policies to model services to allow, deny, or require approval based on tool arguments and caller.
  3. Grant only necessary privileges. Access to an AI asset determines what an agent can reach.

Use Cases

Financial services analysts use agents that inherit their permissions, ensuring they analyze only customers they access. Healthcare organizations use agents that respect patient data permissions and column masks. Multi-tenant platforms use tenant-scoped permissions so each tenant's agents access only their data.

FAQs

What happens if I use a service principal instead of OBO authentication?

The agent gains the service principal's permissions, which usually exceed individual user permissions. Always use OBO authentication.

Can I use row filters with agents?

Yes. Agents inherit user permissions and automatically respect row filters.

What are service policies and when should I use them?

Service policies control which tool calls succeed at runtime. Use them to prevent sensitive operations even if technically allowed by permissions.

How do I prevent data exfiltration through agents?

Combine OBO authentication, row filters, column masks, and serverless egress controls with deny-by-default network policies.

Do I need to rebuild queries for Unity Gateway governance to apply?

No. Governance is enforced at the SQL engine level, so existing code automatically inherits row filters, column masks, and grants.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.