How do I prevent coding agents from accessing sensitive data?

Summary

• Coding agents need data access to work, but unrestricted access violates compliance requirements and puts sensitive information at risk.
• Access control begins with authentication (verifying the agent's identity) and authorization (defining what data each agent can reach).
• Unity Gateway enforces access policies at the connection level, checking agent credentials against data governance rules before queries execute.
• Role-based access control (RBAC) and attribute-based access control (ABAC) are two patterns for managing agent permissions at scale.
• Monitoring and audit trails let you track which agents accessed what data, when, and from where.

How do I prevent coding agents from accessing sensitive data?
Coding agents (whether they run SQL queries, call APIs, or browse tables) need data access to function. The challenge is granting just enough access for their intended purpose without exposing sensitive customer records, financial data, health information, or other protected content. Unrestricted agent access opens the door to data leaks, regulatory violations, and accidental exposure of information agents don't need.
The answer lies in layered access controls: authentication verifies which agent is running; authorization defines what that agent can reach; and audit trails log every action for compliance review.

What is agent access control?

Agent access control is the practice of enforcing policies that determine which datasets, rows, columns, and operations an agent can perform. It sits between the agent and the data store, intercepting requests and checking them against policy before allowing or denying access.
Without access control, an agent granted a database connection can query any table on that connection. With access control, you can restrict that same agent to a subset of tables, specific rows (like only records for a particular customer ID), and specific columns (like hiding Social Security Numbers or credit card numbers).
Access control also covers operations: an agent might be allowed to read a customer profile but forbidden from deleting records or modifying schema.

Key capabilities to evaluate

Effective agent access control platforms provide:

Capability	Why it matters
Authentication & identity	The system must know which agent (or user) is making the request. This is often tied to service accounts, API keys, or OAuth tokens that uniquely identify the caller.
Attribute-based policies	Policies define access based on the agent's attributes, data sensitivity, time, location, and context. A coding agent might access customer data only during business hours, or only for customers in a specific region.
Column and row-level filtering	Access control can hide entire columns (PII never reaches the agent) or restrict rows by predicate (agent sees only transactions from the past 30 days, not historical archives).
Real-time policy evaluation	Policies must be checked at query time, not pre-computed. If a policy changes, the next request reflects the new rule without delays or redeployment.
Audit and compliance logging	Every access grant or denial must be logged with context (who, what, when, from where). This trail is essential for compliance audits and forensics.
Performance with policies	Enforcement cannot add unacceptable latency. Real-time access checks must complete in milliseconds so agent queries respond promptly.

How Databricks approaches agent access control

Unity Gateway sits between coding agents and the Databricks lakehouse, enforcing access policies defined in Unity Catalog. When an agent makes a request, Unity Gateway authenticates the agent using its service account or API key, then checks Unity Catalog to determine what the agent is allowed to access.
Unity Catalog provides role-based access control (RBAC) primitives: you create roles, assign permissions to those roles, and assign agents to roles. For example, you might create a data_analyst_agent role that grants read access to a specific catalog and schema. Any agent assigned that role inherits those permissions.
For more granular control, you can use dynamic access policies that filter data at query time. A policy might state: "This agent can only read rows where department='sales'". Databricks evaluates this filter on every query, so the agent never sees other departments' records.
Unity Gateway also enforces network and transport security. Agents connecting through Unity Gateway can be restricted to specific IP ranges or required to use TLS encryption. This prevents rogue agents from spoofing legitimate ones.
All access checks are logged in audit tables within Unity Catalog. You can query these logs to understand who accessed what, when, and whether access was granted or denied. This audit trail is critical for compliance frameworks like SOC 2, HIPAA, and GDPR.

Use cases

Analytics coding agents: A data scientist's agent needs to analyze customer behavior but shouldn't access PII like email addresses or phone numbers. Unity Gateway filters out those columns automatically, so the agent never sees them.
Financial reconciliation agents: An agent that reconciles transactions across systems needs access to transaction records but must be restricted to the current fiscal month. Row-level policies enforce this window, and the agent can't query historical data outside the policy.
Multi-tenant SaaS platforms: Different customers' agents run on the same platform but must see only their own data. Attribute-based policies (e.g., customer_id=N) ensure each agent sees only its tenant's records.
Compliance-sensitive workflows: In healthcare or finance, any data access is audited. Every query an agent runs is logged, showing which agent, which table, which rows, and the result. This audit trail supports compliance certification.

FAQs

Can I change access policies without restarting agents?

Yes. Unity Catalog policies are evaluated at query time, not cached or baked into agent startup. When you grant or revoke a role or update a row-level policy, the change takes effect immediately on the next query. Agents don't need to restart or reconnect.

What happens if an agent tries to access data it doesn't have permission for?

Unity Gateway denies the request and returns an error to the agent. The agent's code can handle this error (e.g., log a warning, try a fallback query). The access denial is also logged in Unity Catalog's audit table for compliance review.

How do I know if my policies are working as intended?

Query the audit logs in Unity Catalog to see which agents have accessed which tables and whether access was granted or denied. You can also test policies before deploying them by creating a test agent and running queries against it, checking both what it can and cannot access.

Can I use the same agent across different environments (dev, staging, prod) with different policies?

Yes. Assign the agent to different roles in each environment, or use attribute-based policies that reference the environment. For example, agents in the dev environment can access the dev catalog; agents in prod can access the prod catalog. The agent's code stays the same; policies govern access.