Masking Commands

FSQL includes a family of statements for managing column-masking rules: which schema attributes a user or group can see in results. Rules pair an attribute selector with an identity, so one statement can govern a single field or a pattern across the whole schema.

Note: creating, removing, and listing another identity's rules requires the can_mask permission. Platform and tenant administrators hold can_mask by default; administrators can grant it to other users or groups (see Permission Commands). Rule enforcement applies automatically to every QUERY and SUMMARIZE a masked user runs.

MASK / UNMASK

MASK <attributes> FROM USER|GROUP <identity>
UNMASK <attributes> FROM USER|GROUP <identity>

MASK hides the selected attributes from the identity; UNMASK carves attributes back out of a broader mask (typically one inherited from a group). User-scoped rules override group-scoped rules; see Column Masking for the layering model.

• attributes is any valid FSQL attribute selection, e.g. *.raw_data (the raw payload field on every event class), #iam.**, or %ip.
• identity is USER <email> or GROUP <name>. Group names follow the same rules as other FSQL identity references: quote names containing spaces (GROUP 'SOC Analysts'), and disambiguate with a source prefix (GROUP entra:soc-analysts or GROUP query:soc-analysts) if the same name exists in both sources.
• * selects an event's direct attributes and ** selects nested attributes — check what a selector covers with EXPLAIN ATTRIBUTES before masking.

-- Hide raw payloads from everyone in a group
MASK *.raw_data FROM GROUP all-users

-- Let SOC analysts see raw DNS payloads anyway
UNMASK dns_activity.raw_data FROM GROUP soc-analysts

-- Hide a field from one specific user, overriding their groups
MASK ssn FROM USER [email protected]

Re-issuing an identical rule succeeds without error.

DROP MASK

DROP MASK <attributes> FROM USER|GROUP <identity>
DROP UNMASK <attributes> FROM USER|GROUP <identity>
DROP MASK <rule-id>

Removes a rule. In the first two forms the mode, attribute selection, and identity must match an existing rule exactly — including the attribute selection's exact text as originally written (use EXPLAIN MASKS to see rules verbatim, or drop by ID) — dropping a rule that doesn't exist is an error, and dropping a MASK does not touch an UNMASK on the same selector. The third form drops a rule by the ID shown in EXPLAIN MASKS.

DROP MASK *.raw_data FROM GROUP all-users
DROP MASK f1c2aaaa-bbbb-cccc-dddd-eeeeffff0000

EXPLAIN MASKS

EXPLAIN MASKS
EXPLAIN MASKS FOR USER|GROUP <identity>

The bare form lists the rules that apply to you — your user-scoped rules plus rules from every group you belong to. Any user can run it; it's the first stop for "why can't I see this field?".

The FOR form lists the rules attached to any user or group in the tenant and requires the can_mask permission (see Permission Commands).

EXPLAIN MASKED / UNMASKED ATTRIBUTES

EXPLAIN ATTRIBUTES gains two modifiers for debugging masking:

EXPLAIN MASKED ATTRIBUTES <attributes>
EXPLAIN UNMASKED ATTRIBUTES <attributes>

MASKED shows which of the selected attributes are hidden from you; UNMASKED shows what a query selecting those attributes would actually return. Together they partition the plain EXPLAIN ATTRIBUTES output.

EXPLAIN UNMASKED ATTRIBUTES dns_activity.**

Response:

[
	"dns_activity.answers.type",
	"dns_activity.query.hostname",
	...
]

How enforcement behaves

• Masked attributes are removed from QUERY projections and from SUMMARIZE grouping keys and aggregation targets before the query runs — grouping by a masked field would otherwise reveal its values one row at a time. If every grouping key in a SUMMARIZE is masked, the result collapses to a single ungrouped aggregate.
• Masked attributes are still allowed in WITH filter predicates; only their values are suppressed from results.
• If every attribute a query selects is masked, the query fails with an explanatory error.
• If masking rules can't be retrieved, queries fail rather than running unmasked (fail-closed).