How do I make sure an agent never sees data the user isn't allowed to see?

Summary

• Use Unity Catalog to enforce data access control at the query layer: agents inherit the user's permissions, so they can only query data the user has access to.
• Configure row-level and column-level filters in Unity Catalog so sensitive data is masked even from agents using SQL queries or tool integrations.
• Give agents tool access only to functions and APIs you've explicitly registered; restrict agent tool sets per user role so finance agents don't access HR tools.
• Trace and audit all agent data access using Databricks audit logs; log every query, function call, and file access so you can verify permission enforcement.
• Test agent behavior under different user roles before deployment to catch permission leaks; use role-based test cases to ensure agents respect boundaries.

How do I make sure an agent never sees data the user isn't allowed to see?
Data security and permission enforcement are non-negotiable for production agents. An agent must never bypass user access controls, even by accident. The key principle: agents should operate under the same permission model as the user who invoked them. If a user can't query a table, the agent shouldn't be able to query it either.

Permission Enforcement Architecture

Unity Catalog as the Permission Layer Unity Catalog enforces access control automatically when agents query data sources. Every query runs through Unity Catalog's permission checks before returning results. Agents inherit the permissions of the user invoking them, so permission enforcement happens transparently without custom code.
Row-Level and Column-Level Filters Beyond simple grant/deny permissions, Unity Catalog supports row-level filters (show only rows matching a policy) and column-level filters (mask sensitive columns). An agent querying a customer table might see only rows where department matches the user's assigned department, and sensitive columns (salary, social security numbers) are automatically masked.
Tool Authorization and Registration Agents often invoke external tools and APIs (data warehouse queries, microservices, file system operations). Register only the specific tools each agent needs. If an agent doesn't need access to HR data, don't register HR APIs in its tool set. Implement tool-level authorization so agents can only call functions the user has permission to invoke.
Agent Context Awareness When configuring an agent, explicitly pass the user's identity and permissions to the agent's context. The agent should "know" who is invoking it and what that user can access. Use this context to filter tool availability at runtime.

Implementation Pattern

Layer	Control	How
Data Access	Unity Catalog	Agents inherit user permissions; queries blocked at UC layer
Column/Row Level	UC Policies	Sensitive data masked automatically before reaching agent
Tool Selection	Agent Configuration	Register only permitted tools; filter by user role
API Calls	Service Authentication	Pass user identity to external APIs; let them enforce permissions
Audit Trail	Databricks Audit Log	Log all agent queries, tool calls, access attempts for compliance review

Best Practices

1. Never Skip Permission Checks in Tool Code If an agent calls a custom function, don't hardcode data access inside that function. Instead, make the function accept the user's credentials and apply permission checks. The function should fail if the user lacks permission.
2. Use Role-Based Agent Configuration Different users should get different agent instances or agent configurations. A data analyst agent should have broad data access; a junior-level agent should have restricted access. Configure agents per role, not per individual.
3. Audit Everything Enable audit logging in Unity Catalog. Every query an agent runs should appear in the audit log with the user's identity. Audit logs are essential for compliance verification and for debugging. If an agent leaked data, audit logs show exactly what happened.
4. Test Permission Boundaries Before deploying an agent, test it as different user roles. Verify that a "read-only" agent can't write data. Verify that an agent restricted to one dataset can't access another. Permission testing is mandatory.
5. Default to Deny When setting up agent tool access, start with a minimal set of tools. Add tools only as needed. Never give agents broad permissions "just in case."

How Databricks Enforces Agent Permissions

When you create an agent on Databricks, it runs under a service principal or user context. That context determines what data the agent can query. Agent queries automatically go through Unity Catalog's permission layer, so if the user lacks permission to a table, the agent can't query it either.
Agent Evaluation includes permission testing so you can verify that agents respect data boundaries. Register custom scorers to check: can this agent access data it shouldn't? MLflow Tracing logs all agent queries and tool calls, so you have a complete audit trail.
Model serving endpoints that invoke agents also enforce permissions: the endpoint passes the end user's identity to the agent, ensuring permission context flows through the system.

FAQs

What if an agent needs to combine data from multiple sources?

Each source should enforce its own permissions through its native access control (Unity Catalog for Databricks data, IAM for cloud storage, role-based access for APIs). The agent makes requests as the user, and each system checks permissions independently. If the user can't access source A, the agent can't either.

Can I audit which data an agent accessed?

Yes. Enable audit logging in Unity Catalog and query the audit log table. You'll see every query the agent ran, what data it touched, and which user invoked the agent. This is essential for compliance audits.

Should I use a shared service principal for all agents or per-user principals?

Per-user is better for security. If all agents run under a shared principal, you lose the ability to attribute data access to individual users. Use per-user or per-role principals so audit logs show who accessed what.