Data privacy levels
Measured Cloud runs checks and profiles against your data. The results always keep counts, pass or fail and statistics. The data privacy level decides whether any values from your data are stored alongside them: the failing values a rule found, and the most frequent values in a profiled column.
A super admin sets the level for the whole organization in Settings → Privacy. A data asset can be made stricter than the organization, never less strict.
The three levels
| Level | What is stored | Good for |
|---|---|---|
| Metadata only | No values from your data. Results keep counts, percentages, pass or fail and numeric observed values; profiles keep row counts, null rates, distinct counts, means and text lengths, but no top values and no minimum or maximum of number or date columns. | Confidential data, and the default for new organizations. |
| Masked samples | Failing values and top values, with sensitive values masked before they are stored: emails, phone numbers, card numbers, national ids and similar values keep their shape (j***@example.com), and every value of a column whose name marks it as personal data (first_name, email, date_of_birth, …) is masked whole. Other values are kept. | Triage without keeping personal data. |
| Full samples | Failing values (up to 20 per rule), failing rows for custom SQL rules, and the top 10 values per profiled column, exactly as found. | Debugging non-sensitive data. |
Masking is the same masking that runs before anything is sent to an AI model; AI features lists every detector. The rule configuration stored with a result (the rule's column and allowed values) is kept as it is.
At Metadata only, a number or date column's minimum and maximum are not stored: they are real values from your data (a lowest salary, an earliest date of birth). Statistics that aren't individual values (row count, null rate, distinct count, mean, standard deviation, and the minimum and maximum length of text columns) are kept at every level, so the profile page stays useful. So are a column's sensitivity suggestions, which hold only the share of values that matched each detector. Profiles taken before the level was tightened keep what they already stored.
Defaults
- New organizations start at Metadata only.
- Organizations created before privacy levels existed were set to Full samples, so nothing changed for them. A super admin can tighten the level at any time.
Per-asset setting: Retain samples
Each data asset has a Retain samples setting (on the asset page, Edit). It can only make that asset stricter:
- Retain samples off: the asset stores metadata only, whatever the organization level.
- Retain samples on: the asset follows the organization level.
The asset page shows the level that applies to that asset next to its name (Stores: Metadata only, for example). When the organization stores metadata only, an asset can't be switched to retain samples, because it would store nothing anyway.
Changing the level
Only a super admin can change the level. The change asks you to confirm your password (or sign in with your identity provider again) and is recorded in the audit log with the old and new level. Everyone else who can open Settings sees the level with the options disabled.
A change applies to runs and profiles from then on. What happens to what is already stored depends on the direction:
- Tightening rewrites stored values. Moving to a stricter level (Full samples → Masked samples or Metadata only, Masked samples → Metadata only) also rewrites every result and profile already stored, whatever its age, to the new level. Before saving, Settings asks you to confirm that stored values will be rewritten. The rewrite runs in the background about a minute after you save, in small batches; Settings → Privacy shows it as in progress until it finishes. At Metadata only the values are removed; at Masked samples they are masked. Counts, pass or fail, statistics and health scores are kept, and no execution run, result or profile is deleted. It can't be undone.
- Loosening applies from now on. Moving to a less strict level stores more for new runs and profiles only. Values already removed or masked can't come back.
The rewrite is recorded in the audit log with the number of results and profiles it checked and rewrote. If the background job can't be queued, the daily retention job (below) finishes it.
Sample retention
Run history is kept forever. Sample retention decides how long the values inside it are kept. A super admin sets Keep sample values for in Settings → Privacy: Forever (the default), 7, 30 or 90 days, or a custom number of days from 1 to 3650.
Every day at 04:30 UTC, a background job applies Metadata only to every stored result and profile older than that: failing values, failing rows, non-numeric observed values, top values, and the minimum and maximum of number and date columns are removed. Everything else stays:
- Kept: counts, percentages, pass or fail, statistics, health scores and trends, the rule configuration, and every execution run, result and profile. Nothing is deleted.
- Removed: the values listed above, from results and profiles older than the retention. Removed values can't be restored.
It works with any privacy level. At Full samples with a 30-day retention, for example, you can debug last month's failures with their values while older runs keep only their counts.
Each scrubbed row is marked, so the job only reads rows that have aged past the retention since its last run, and it works in batches of a few hundred rows so it never holds up runs. Each daily run is recorded in the audit log for the organization, with the number of results and profiles scrubbed; Settings → Privacy shows when stored values were last scrubbed. Setting a shorter retention takes effect at the next daily run.
Where your data goes
- Direct mode. The worker connects to your data source, runs the checks and applies the privacy level before anything is written. If it can't tell which data asset a run belongs to, it stores metadata only.
- Agent mode. The Privacy Agent runs the checks inside your network. Validation results it sends back carry counts and pass or fail only, whatever the level. The agent also receives the organization level on every heartbeat and shows it on its status page, so jobs that could return values apply it before anything leaves your network. A profile computed on the agent leaves it at the stricter of this level and the asset's sample retention: under metadata only with no top values and no minimum or maximum that is a value from the data.
- AI features. AI features read what was stored, and the level is applied again before any value reaches a prompt, so a result or profile stored before you tightened the level doesn't leak values the level now forbids.
- MCP. The MCP tools that hand stored data to your own LLM (
mc_profile_get;mc_result_get,mc_result_listandmc_execution_run_resultswith the detailed format; and the rule-suggestion context tool) apply the level the same way. If the level can't be read, they return metadata only.
API
GET /api/v1/organizations/{org_id}/privacy returns {"data": {"privacy_level": "metadata_only"}} to any member of the organization. PUT with {"privacy_level": "metadata_only" | "masked" | "full"} changes it: it needs a super admin and a recent password or SSO proof. A stricter level also queues the rewrite of stored values.
GET /api/v1/organizations/{org_id}/privacy/sample-retention returns {"data": {"sample_retention_days": 30, "samples_scrubbed_at": "…", "privacy_rewrite_pending_since": null}} to any member. PUT with {"sample_retention_days": 30} (or null for forever) changes it, with the same super admin and step-up rules. See the API reference.