CONCEPT Cited by 1 source
Opt-in PII redaction per session¶
A data-platform governance shape in which PII columns are redacted by default before query results ever reach the user, and legitimate access flips a session-level bit that re-checks permissions, lifts redaction for that session only, and logs the flip + every query that used the lifted state.
The unit of opt-in is the session, not the user, the table, or the query. This is a deliberate granularity choice: too coarse (per-user) and PII access is permanently elevated; too fine (per-query) and the operational burden makes the redaction-by- default posture unusable.
Canonical wiki instance¶
Cloudflare Town Lake, from the 2026-05-28 launch post:
"PII is opt-in per session. By default, Trino redacts sensitive columns before they ever hit your screen. If you have a legitimate need for raw PII (e.g., fraud investigation), you flip the bit on the session, your permissions are checked, and the redaction is lifted. The flip and every query is logged."
Three-step contract¶
The session opt-in shape:
- Default state: every Trino session starts with PII redaction on. Columns flagged as PII (by Skimmer / DataHub classification) return masked values in query results.
- Opt-in: the user explicitly flips a session-level setting declaring legitimate need for raw PII.
- Re-check + lift + log: the platform re-checks the user's permissions for raw-PII access, lifts the redaction for that session, and logs the flip event itself plus every query that runs in the lifted state.
The audit trail is the load-bearing accountability mechanism — the cost of opting in is observability, not friction.
Why session-level (not user-level or query-level)¶
| Granularity | Failure mode |
|---|---|
| Per-user (always-on for some users) | Permanent elevation; "I'm a fraud investigator" becomes "I always see raw PII" even when running unrelated queries — defeats the redaction posture |
| Per-query | Operational burden — flipping the bit on every query that needs raw PII makes the redaction posture unusable for legitimate workflows |
| Per-session (Town Lake's choice) | Bounded elevation; the user's operational intent is captured (this session is for fraud investigation); audit trail naturally clusters all the lifted-state queries together |
The session naturally captures "the user is currently doing work that needs raw PII" — a unit of work that's coarser than a query but finer than a permanent grant.
Composes with default-closed governance¶
PII redaction-by-default is the column-level analogue of default-closed table allowlisting. Both express the same shape — "sensitive data is invisible until you explicitly opt in, and the opt-in is audited." The separation of policy is structurally clean:
- Table allowlist: am I allowed to see this table at all?
- PII redaction opt-in: given that I have access, do I see raw values or masked ones for this session?
Mechanics in the engine¶
Implementation runs through Trino's column-masking + session- property machinery, gated by Lifeguard's JSON policy. The session bit triggers a re-check against Lifeguard for raw-PII authority, separate from the table-level read authority.
Sibling concepts¶
- concepts/audit-trail — the load-bearing accountability substrate for the opt-in.
- concepts/data-classification-tagging — the prerequisite (columns must be classified as PII for the policy to apply).
- concepts/default-closed-table-allowlist — the table-level parallel.
Seen in¶
- sources/2026-05-28-cloudflare-how-we-built-cloudflares-data-platform-and-an-ai-agent-on-top-of-it — canonical wiki instance.
Related¶
- systems/cloudflare-town-lake — the platform.
- systems/cloudflare-lifeguard — the enforcement layer.
- systems/trino — the engine implementing column masking + session properties.
- concepts/default-closed-table-allowlist — the table-level parallel.
- concepts/audit-trail — the accountability substrate.
- concepts/data-classification-tagging — the prerequisite.
- concepts/security-model-as-data-model — the broader Cloudflare framing.