How do we stop an AI agent from accessing data beyond its intended permissions?

Summary

• On Databricks, an AI agent is confined to its intended permissions by making the agent inherit a real user's identity and then enforcing that identity at the data layer — so an agent can never see data the person it acts for could not see.
• On-behalf-of (OBO) execution forwards the invoking user's identity through the agent chain, so if the user cannot access a table in Unity Catalog, neither can the agent acting on their behalf.
• Unity Catalog enforces access at the SQL engine level with four layers that must all pass: workspace bindings, GRANT privileges, attribute-based access control (ABAC) policies, and row filters and column masks.
• ABAC row filters and column masks are transparent — restricted rows simply don't return and masked columns return NULL, with no way for the agent to detect that data was withheld.
• Tools and MCP servers are governed as Unity Catalog objects, the Unity AI Gateway applies real-time guardrails that fail closed, and every action is logged against both the user and the agent identity for audit.

How to stop an AI agent from accessing data beyond its intended permissions

The risk with autonomous agents is that they run continuously and call tools and data on their own, so a shared service account or a broad backend credential would let an agent reach data well beyond what any single user should see. Databricks closes that gap by tying every agent action to a real identity and then enforcing that identity consistently at the data layer. Identity flows end to end — from the user who asks the question to the specific table row the agent retrieves — and the same governance rules apply no matter which service issues the query.

Why Databricks keeps agents within their permissions

• On-behalf-of identity propagation. With on-behalf-of user authentication, an agent inherits the invoking user's permissions rather than operating under a shared service account. The user's identity flows end to end, so if a user cannot access a table in Unity Catalog, neither can the agent acting on their behalf.
• One authorization engine for every service. Unity Catalog enforces access at the SQL engine level and applies the same rules regardless of which service issues the query — assistants, Agent Bricks, model serving, and custom tools ultimately run SQL that passes through Unity Catalog's authorization engine.
• Four layers that all must pass. Access is granted only when workspace bindings (where data can be accessed), GRANT privileges such as SELECT, MODIFY, and EXECUTE (who can do what), ABAC policies (what data by classification), and row filters and column masks (which rows and columns are visible) all allow it.
• Attribute-based access control. ABAC lets you define a policy once and apply it automatically across catalogs, schemas, and tables. Row-filter policies return only the records a user's attributes permit, and column-mask policies mask sensitive columns unless the user belongs to a specific group. These controls are transparent: restricted rows simply do not return and masked columns return NULL, with no indication to the agent that data was withheld.
• Governed tools and MCP servers. External tools and MCP (Model Context Protocol) servers are registered as Unity Catalog securables and governed like any other object, with permissions, credential management, and audit logging in one place. service policies (in beta) evaluate every tool call before execution and can allow, deny, or require user consent based on the tool, its arguments, or the caller's identity — a deny blocks the call.
• Real-time guardrails at the gateway. The Unity AI Gateway enforces policies in real time on every call with full payload logging. Guardrails inspect inputs for personal data and prompt-injection attempts and check outputs for sensitive content, running inline on every request and failing closed. Built-in guardrails cover common risks, and organizations can add custom policies.
• Audit against both identities. Every action is logged against both the real user and the agent identity — which tables were accessed, what operations ran, and when — and Unity Catalog system tables capture queries, data access, and model inference for compliance.

Getting started

• Read how Unity Catalog secures your agent's actions and governing AI agents at scale with Unity Catalog.
• Enable on-behalf-of user authentication so agents run with the invoking user's identity.
• Define ABAC row filters and column masks and add service policies to govern tool calls.
• Review mitigating prompt-injection risk for AI agents for defense-in-depth controls.

FAQs

How does an agent get the right permissions instead of over-broad access?

With on-behalf-of execution, the agent inherits the invoking user's identity, so its access is exactly the user's access. It does not run under a shared service account, and it cannot bypass Unity Catalog with a broad backend credential.

What stops an agent from reading rows or columns it shouldn't?

Unity Catalog ABAC row filters and column masks apply to the agent's queries. Restricted rows do not return and masked columns return NULL, transparently, so the agent cannot detect or work around the restriction.

Can we control which tools an agent is allowed to call?

Yes. Tools and MCP servers are Unity Catalog securables, and service policies evaluate every tool call before execution to allow, deny, or require consent based on the tool, its arguments, or the caller's identity.

How do we prove an agent stayed within its permissions?

Every action is logged against both the real user and the agent identity, capturing which tables were accessed and what operations ran, and Unity Catalog system tables record queries, data access, and model inference for audit and compliance.