How to Connect an AI Agent to Your Data Warehouse Without Exporting PII

You can connect an AI agent to a data warehouse safely for audience segmentation without exporting PII, on one condition: the agent's role must be unable to return a row about a single person. Where the data is stored matters less than what a query hands back, because every result a tool returns lands in the model's context. So the agent writes segment logic and reads group counts, the warehouse runs the logic, and a separate role builds the audience table. If agents are new to your team, start with our explainer on what agentic AI is.

Why is a zero-copy connection only half the answer?

To connect an AI agent to a data warehouse safely for audience segmentation without exporting PII, a common starting point is a zero-copy setup: the agent sends SQL through a protocol such as the Model Context Protocol (MCP), the warehouse executes it, and no extract is loaded into the agent vendor's storage. Snowflake offers a managed route: "The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastructure."

Zero-copy governs storage and leaves the result set open. The same page truncates SQL tool responses at 250 KB, a limit it ties to LLM context window saturation, so it works as a sizing rule. At an assumed 60 bytes per row, 250 KB still holds roughly 4,000 email addresses, and if the agent's role can select an email column, they go into the prompt.

Two defaults on that page decide how far the agent reaches. An OAuth session uses the connecting user's DEFAULT_ROLE as its primary role, so the agent's service user needs a narrow default role of its own, with secondary roles left off, the default the page recommends for MCP. Server access also grants nothing by itself: "Access to the MCP Server does not give access to the tools. Permission needs to be granted for each tool."

Five ways to keep raw rows away from the agent

The latency and cost entries are our assessment, with vendor requirements where the documentation states them; we ran no benchmark. The options stack: a scoped role first, a threshold on top, a token as the join key, and a clean room only when a partner's data is involved.

What should the agent's role be allowed to do?

Privacy-preserving audience segmentation in a data warehouse begins with access control on the agent's own role, before anyone writes a policy. Grant it SELECT on a single feature table at customer grain: recency, order count, spend band, category affinity, region, lifecycle stage and a marketing-eligibility flag. Leave out names, emails, phone numbers, street addresses and every free-text column, since notes fields and support transcripts can carry names that a rule written for identifier columns will miss. Our first-party data playbook is a further resource on the data underneath, and our piece on the governance layer for multi-agent stacks covers role design across several agents.

How do aggregation thresholds keep an LLM away from individuals?

Privacy-preserving audience segmentation with an LLM in the data warehouse works when every result the model reads describes a group. Snowflake builds this into an aggregation policy, under which queries against a table must "aggregate data into groups of a minimum size in order to return results". Groups below the minimum are combined into a remainder group whose GROUP BY key is NULL, and a query too small to fill a remainder group returns NULL in every field. Spell that out in the agent's instructions, or it may read a suppressed group as zero.

BigQuery reaches the same end through a view. Google Cloud says an aggregation threshold analysis rule "enforces the minimum number of distinct entities that must contribute to an output row of a query", counted on a privacy unit column whose values cannot be directly projected. Attaching the rule costs nothing extra, and standard BigQuery pricing for analysis applies.

The failure mode to plan for is differencing, where two overlapping counts are subtracted to isolate one person. Snowflake says so plainly: "With enough query attempts, a malicious actor could potentially work around the aggregation requirements to ascertain a value from an individual row." An agent narrowing its filters over dozens of calls can produce those attempts with no bad intent, so cap the queries per run and set the minimum high enough to double as a floor on segment size.

Do tokenized identifiers take the data out of privacy scope?

Tokenized identifiers lower the exposure if a result leaks, but they do not take the data out of privacy scope. Snowflake describes External Tokenization as tokenizing data before it is loaded and detokenizing it at query runtime, and notes that a token is unique for a given value, so records can be grouped by it without revealing the sensitive information. That makes a token a workable join key.

The ICO, the UK regulator, states: "Pseudonymised data is personal data in the hands of someone who holds the additional information." Your company holds the key, so a list of customer tokens in an agent's output is still personal data on your side, which is why the reference design below keeps tokens out of the agent's results too. The ICO adds that this guidance is under review because of changes made by the Data (Use and Access) Act.

When does a clean room belong in the design?

A clean room architecture for privacy-safe audience segmentation in a data warehouse suits an LLM agent when the segment depends on a second party's data, such as a retailer's purchase history or a publisher's audience. Google Cloud lists audience insights, measurement and activation among the use cases and says: "Data egress controls automatically prevent data clean room subscribers from copying and exporting raw data from a data clean room." It also cautions: "Analysis rules in data clean rooms provide privacy controls, but they might not fully prevent sophisticated queries from extracting unauthorized data." Its pricing table charges a data contributor only for data storage and a subscriber only for compute (analysis) when running queries. For segments built only from your own first-party data, we would skip the clean room and put the threshold on your own tables or views.

Is a semantic layer a privacy boundary?

A semantic layer shapes what the agent asks for, and we would treat it as vocabulary. Snowflake describes a semantic view as a schema-level object holding metrics, dimensions and facts, then adds a caveat that matters for privacy: "Currently, Cortex Agents reads the information captured in the semantic view definition and generates the SQL against the physical tables directly." We read that as a reason to put the policies on the base tables. A direct query differs: Snowflake's page on querying semantic views says a role needs SELECT only on the semantic view, with no SELECT on the tables it uses, so count a grant on the view as access to that data. The semantic view still earns its place for accuracy, the benefit Snowflake claims for it.

A reference design for a segmentation agent

To connect an AI agent to a data warehouse safely and segment audiences with no PII in its results, we would combine the documented pieces above into five parts on Snowflake. This is a proposed design with placeholder names, and we have not benchmarked it.

1. The feature table. segmentation.customer_features holds one row per marketing-eligible customer, keyed by a token, with no direct identifiers and no free text.
2. The threshold. An aggregation policy sits on that table and is lifted only for the role that builds audiences.
3. The agent's role. A service user whose default role can select from that one table reaches it through the MCP server's SQL tool, with the read_only option set to true so that only SELECT queries are allowed.
4. Approval and build. The agent returns a segment spec: a name, the filter logic and the counts behind it. A marketer approves it, and a job running as SEGMENT_BUILDER, a role the agent never holds, writes the audience table. Our guide to a governance operating model covers staffing that approval, and what agents can write back to a CRM covers the write side.
5. Audit. Someone reviews the ACCESS_HISTORY view for the agent's user daily. Snowflake says the view covers the last 365 days and that its latency "may be up to 180 minutes (3 hours)", so it serves as evidence after the fact while the grants do the preventing. We found no statement there that aggregation policies appear in its policies_referenced column, so keep the agent's SQL text in your own run log too.

The policy in part 2 is adapted from the example in Snowflake's documentation, with 50 as a placeholder minimum:

CREATE AGGREGATION POLICY segment_agent_policy
  AS () RETURNS AGGREGATION_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'SEGMENT_BUILDER'
        THEN NO_AGGREGATION_CONSTRAINT()
      ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 50)
    END;

ALTER TABLE segmentation.customer_features
  SET AGGREGATION POLICY segment_agent_policy;

A hypothetical run

Assume 400,000 marketing-eligible customers in the feature table, a minimum group size of 50 and a cap of 25 queries per run. The brief asks for lapsed high-value buyers: last order 180 to 365 days ago, top spend band. The agent's sixth and final query counts them by region.

The agent proposes a segment of 18,473 customers, about 4.6% of the table, and attaches the filter logic. The 73 customers in the NULL row sit in regions too small to report, and the agent learns nothing more about them. A marketer approves the spec, and the builder job writes 18,473 tokens to an audience table. Across six queries, no row about a single person entered the model's context.

Best practices and what to measure

Best practices for connecting an AI agent to a data warehouse safely without exporting PII fit in a short list:

• Give the agent's service user a narrow default role that reads one feature table with no direct identifiers and no free text, and grant each tool separately.
• Enforce the minimum group size in the warehouse, have the data owner approve any change to it, and cap queries per run.
• Keep audience builds and activation with a different role, behind a human approval.
• Review access history daily and log the agent's SQL yourself.

Four numbers show whether the design pays off: hours from brief to approved segment against your analyst baseline, the share of queries that come back NULL (a rising share suggests the agent is querying below the threshold), access-history exceptions outside the segmentation schema (target zero), and revenue per contact for agent-built segments against an analyst-built holdout. Our AI ROI calculator is a further resource for the cost side, and scoping a design like this one is work our agentic AI automation team does.

Sources

• Snowflake, Snowflake-managed MCP server
• Snowflake, Aggregation policies
• Snowflake, Understanding Column-level Security
• Snowflake, Overview of semantic views
• Snowflake, Querying semantic views
• Snowflake, ACCESS_HISTORY view
• Google Cloud, Restrict data access using analysis rules
• Google Cloud, Share sensitive data with data clean rooms
• ICO, Pseudonymisation