See who can read your sensitive data

Goal

AI copilots, text-to-SQL tools and agents usually connect to a warehouse as service users with broad grants. For each data asset, Measured Cloud lists the accounts the warehouse lets read the table, and flags the ones that look like AI or service accounts. That answers "which AI tools can read our sensitive data?" without touching the data: it reads grants only.

Prereqs

• A data asset on Snowflake, Postgres or Redshift. Other warehouses are coming.
  • Connected directly: Measured Cloud reads the grants with the data source's connection.
  • Connected through a Privacy Agent: the agent reads them inside your network, with its own stored connection, and sends back only the account and role names. The agent must be up to date: an older one can't do this, and the card says to update it.
• The connection's role must be able to read grants:
  • Snowflake: the role needs to see the table's grants (SHOW GRANTS ON TABLE) and its roles' grants (SHOW GRANTS OF ROLE). The owner of the table and roles, or a role with MANAGE GRANTS, can. To show whether each user is a service user or signs in with a key pair, it also needs to see users (SHOW USERS). Without that it still lists them.
  • Postgres, Redshift: nothing extra; any role can ask the database who may read a table.

Steps

1. Open the data asset. Under Who can read this table, Measured Cloud lists every account that can read it, and the roles it reads through (for example ANALYST → BI_ROLE). The list is refreshed after every profile; Scan now (editor role) refreshes it immediately. Through a Privacy Agent, the answer arrives once the agent has run the scan, usually within seconds; refresh the page to see it.
2. Check the Kind column:
   • AI? or Service account? is a suggestion, with the reason on hover. AI is suggested for names such as copilot, gpt, claude, llm and agent. Service is suggested for Snowflake SERVICE users, key-pair sign-in, and names such as svc_*, *_bot and etl.
   • AI, Service account or Person without a question mark is a decision someone made.
3. Confirm or change an account's kind from its ⋯ menu (workspace admin). The decision applies to every table that account reads on that data source, and it's recorded in the audit log.
4. To be told when an AI account can read a data asset that isn't certified AI-ready, turn on the AI usage policy and add an alert rule on its trigger.
5. On the sensitive data map, the Readers column shows how many accounts can read each sensitive table and how many are AI or service accounts. Filter it to Readable by AI, and the summary counts the data assets with sensitive data that an AI account can read.

See who read it

Grants say who could read the table. On Snowflake, Measured Cloud also reads who did, from the warehouse's access history, with the same scan.

• What you see. Under Who read it in the last 7 days, each account that read the table: how many queries, when it last did, and which of the table's sensitive columns it touched. An AI or service account that read a sensitive column is marked Read sensitive data. A read with no column detail (a COUNT(*), for example) counts as reading the whole table.

• What it needs. Snowflake Enterprise edition, and a connection role that can read SNOWFLAKE.ACCOUNT_USAGE:

  GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <your_role>;
  -- or, more narrowly:
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE <your_role>;

  Without it, the grants are still listed, and the card says what to grant.

• How fresh it is. Snowflake adds a query to its access history up to 3 hours after it ran.

• What's kept. For each account: its number of queries, first and last read, and the columns it read. Never the query text and never a value. It's replaced on every scan.

• Through a Privacy Agent. The agent reads the history inside your network and sends back the same summary. It needs a version that supports it; an older one still lists the grants.

• Be told. Add an alert rule on AI or service account read sensitive data to hear when an AI or service account reads a sensitive column it hadn't read before. See Sensitive read alerts.

• On the map. The sensitive data map marks a column an AI or service account read with Read. Filter the Readers column to Read by an AI or service account.

BigQuery and Databricks are planned. Postgres and Redshift keep no history of who read a table unless an audit extension records it.

Verify

• An account you granted SELECT (directly, or through a role it has) appears in the list after Scan now.
• After you mark an account as AI, the map's Readers column counts it as AI.
• On Snowflake, a query you run as an AI-named account against a sensitive column shows under Who read it in the last 7 days after the next scan, once Snowflake has recorded it (up to 3 hours).

Troubleshooting

Symptom	Cause	Fix
"Couldn't read the access history"	The connection's role can't read SNOWFLAKE.ACCOUNT_USAGE, or the account isn't Enterprise edition.	Grant what See who read it lists.
A read you expect isn't listed	Snowflake hasn't recorded it yet.	Wait up to 3 hours, then Scan now.
"Couldn't read the table's grants", or "Privacy Agent: …" with a permission error	The connection's role can't see the grants.	Grant the role what the prereqs list, or connect with one that has it. Until then the card keeps the readers from the last scan that worked.
"This Privacy Agent can't read who can access a table yet"	The agent predates this feature.	Update the agent to the latest version, then click Scan now.
"Privacy Agent: agent offline"	The agent didn't pick the scan up within an hour.	Check the agent under Settings → Privacy Agents, then click Scan now.
Kind is "—" for an AI tool	Its name and the warehouse give no hint.	Mark it as AI from its ⋯ menu.