An Analytics Agent's Permissions Should Survive a Bad Prompt

When an analytics agent receives an improper command, such as requesting every customer's unmasked payment identifier, it raises critical questions about the system's permissions. The MerchantLens, a merchant analytics lakehouse built using Databricks, Delta tables, and Unity Catalog, serves as a demonstration of this issue. The tool operates within Bronze, Silver, and Gold layers, with an agent querying live catalog metadata and utilizing tools for metrics or SQL operations.

The agent operates under its own service principal, with Unity Catalog applying column masks and row filters based on that principal's permissions before delivering query results. The entitlement decision rests with the query engine, separate from reliability controls.

The repository highlights several layers contributing to controlled agent behavior: certified metrics to maintain consistent definitions and grain, application checks to constrain SQL, schemas, rows, and tool steps, and Unity Catalog policies to enforce identity-based row and column access. Audit records document tool activity independently of the query's output.

While these measures help secure the application, the overall protection depends on correctly configured identities, grants, masks, and filters, as well as every query using the intended principal.

A practical lesson from the documentation emphasizes the importance of testing protected tables using the actual identity, rather than only checking membership expressions. This ensures a thorough understanding of what the mask does, as relying solely on membership expressions can provide an inaccurate picture. The documentation also emphasizes the need to review ambient grants on new service principals, as granting automatic access does not equate to a deny-by-default setup.

Additionally, metric definitions should be explicit and shared across dashboards and agents to maintain consistency, particularly in cases where the definition of a metric can impact results, such as in chargeback incidents.

Before granting an agent access to a warehouse tool, it is crucial to consider several factors, including the principal executing queries, potential retrieval of restricted columns through other tables or grants, testing of results under that principal, logging of tool calls inaccessible to the agent, and explicit metric definitions shared among stakeholders.

Ultimately, the question remains: where does an analytics agent's access control execute—within the prompt, the application, or the database? Understanding the architecture and platform findings can help answer this critical question.