How can I control which customer attributes a marketing AI agent can use?
Summary
- You control which customer attributes a marketing AI agent can use with the same access controls you apply to people: grants on tables and columns, row filters, column masks, and tag-based policies, all enforced by Unity Catalog.
- The core idea is that an agent inherits the permissions of the person it acts for, so it can never read an attribute that person could not read.
- Because these controls fire in the query engine, no agent, tool, or app can route around them; a blocked field simply returns a masked value or fewer rows, with no back door.
- Databricks CustomerLake runs marketing agents on governed data in the lakehouse, so they operate under the attribute-level controls Unity Catalog already enforces.
- CustomerLake is in Private Preview; confirm current availability and the status of specific governance features before relying on them.
How can I control which customer attributes a marketing AI agent can use?
You control which customer attributes a marketing AI agent can use with the same access controls you apply to people: grants on tables and columns, row filters, column masks, and tag-based policies, all enforced by Unity Catalog. The core idea is that an agent should inherit the permissions of the person it acts for, so it can never read an attribute that person could not read. Because these rules are enforced in the query engine, no agent or application can route around them: when a mask or filter applies, the agent sees a masked value or fewer rows, with no back door. The reliable pattern is one governance model for people and agents, not a separate policy layer for AI.
What attribute-level access control means
Attribute-level, or column-level, access control decides which fields of a customer record a caller can see and in what form. A marketing agent might use coarse attributes like city, lifecycle stage, or product interest, while direct identifiers such as email, phone, or a government ID are masked or withheld. Row-level control is the companion: it decides which records the agent can touch at all, for example only consented customers or a marketer's region. Together they let you hand an agent exactly the attributes it needs and nothing more.
Key capabilities to evaluate
| Capability | Why it matters |
|---|---|
| Column masks | Redact or transform sensitive fields (email, phone, ID) so an agent works with usable data but never sees the raw value. |
| Row filters | Limit which customer records an agent can read, by region, consent status, or segment. |
| Grants on tables and columns | Decide which datasets and fields an agent may query at all. |
| Tag-based (attribute-based) policies | Tag fields once by sensitivity, then one policy applies everywhere that tag appears, including on new tables. |
| Agent inherits user permissions | The agent acts as the person behind it, so it cannot exceed that person's access, and controls fire in the query engine that no tool can bypass. |
| Audit of attribute access | A query-ready log of which attributes an agent read, and on whose behalf. |
How Databricks approaches it
CustomerLake is Databricks' agentic CDP, embedded in the lakehouse, so marketing agents operate on governed customer data rather than a separate copy. That placement is what makes attribute-level control practical: agents inherit the controls already defined in Unity Catalog, which governs the rest of your data and AI too.
Three controls do most of the work. Grants decide which tables, views, and columns an agent may query. Column masks transform sensitive fields at query time, so an agent can use a generalized value while the raw email or ID stays hidden. Row filters limit the records in scope, for example to consented customers or a marketer's region. Masks and filters are defined as SQL functions evaluated at run time, and they apply the same way to a person and to an agent acting for that person.
To manage this at scale, tag customer attributes by sensitivity once, then write attribute-based policies that apply wherever those tags appear, including on tables added later. Because every control runs in the query engine, each marketing agent, whether a Genie-driven audience builder or a custom agent, is subject to it, and an application cannot return an attribute the policy blocks. Agents run on behalf of the requesting user, so an agent's reach is bounded by that user's grants, masks, and filters. Runtime service policies can add a checkpoint that evaluates a request before it runs and the response after, and Unity Catalog system tables keep an audit trail of which attributes were read and by whom. Data teams define these datasets and policies once; marketers then use agents without exporting data. CustomerLake is in Private Preview, so confirm current availability and the status of specific governance features before you rely on them.
Use cases
- Self-service audience building. A marketer describes an audience in plain language; the agent filters on allowed attributes like lifecycle stage or region, while direct identifiers stay masked.
- Regional teams. An agent acting for a marketer in one region reads only the records and attributes that region is cleared for, enforced by row filters and grants.
- Sensitive fields. Payment, health, or precise-location attributes are tagged sensitive and blocked from marketing agents by a single attribute-based policy, even as new customer tables come online.
FAQs
Can a marketing AI agent access customer data the marketer cannot?
No. The agent inherits the requesting user's permissions, so it can read only the attributes and rows that person is allowed to see. Masks and filters apply the same way to both.
How do I hide specific fields like email or phone from an agent?
Apply a column mask to those fields in Unity Catalog. The agent receives a masked value at query time while the underlying data stays protected, and it can still use the non-sensitive attributes it needs.
How do I prove which attributes an agent used?
Unity Catalog records access in system tables, giving a query-ready audit of which attributes an agent read and on whose behalf, supporting privacy and compliance review.
Is CustomerLake generally available?
CustomerLake is in Private Preview. Confirm current availability and the status of specific Unity Catalog governance features before relying on them.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.