Column Masking

Restrict which schema attributes users and groups can see in search results.

Column masking lets administrators restrict which schema attributes specific users or groups can see in search results. Masked attributes are removed from results entirely — the same events are returned, but the sensitive fields are not. It's the right tool for enforcing need-to-know on sensitive fields like raw payloads, PII, or credentials.

Column masking is not row filtering: it controls which fields a user sees, not which events. Every user still sees the same set of matching events.

Because Query normalizes every connected source to a common schema, one rule covers a field across every event type and every connector at once — *.raw_data masks the raw event payload on every event class.

How rules work

Each rule either masks (hides) or unmasks (reveals) a selection of attributes for a user or a group. Attribute selections use the same attribute selectors you use in FSQL queries, so a single rule can cover one field, a whole event class, or a pattern across the entire schema. Note that * selects an event's direct attributes while ** selects nested attributes — EXPLAIN UNMASKED ATTRIBUTES (see the FSQL page) shows exactly what a rule covers.

Rules are layered, and more specific rules win — the same intuition you bring from RBAC and IAM systems:

  1. Everything is visible by default.
  2. Group masks hide attributes at group scope.
  3. Group unmasks reveal attributes at group scope.
  4. User masks hide attributes for a specific user — overriding any group rule.
  5. User unmasks reveal attributes for a specific user — overriding everything above.

The order rules are created in doesn't matter; only a rule's mask/unmask mode and whether it targets a user or a group.

Example: broad mask, targeted carve-out

Alice belongs to all-users (which has a mask on *.raw_data) and to soc-analysts (which has an unmask on dns_activity.raw_data). Alice sees raw_data on DNS activity events, but not on any other event type.

Example: user rule overrides group rule

Bob's group analysts is authorized to see ssn, but an administrator masks ssn for Bob directly. Bob cannot see ssn, even though his peers can.

What masked users experience

  • Masked attributes are removed from query results and from SUMMARIZE grouping keys and aggregation targets.
  • Masked attributes can still be used in filters (WITH clauses) — investigators can filter by a sensitive identifier without seeing its value.
  • If every attribute a query selects is masked, the query returns an error rather than an empty result.
  • Users can run EXPLAIN MASKS at any time to see exactly which rules apply to them, and EXPLAIN UNMASKED ATTRIBUTES <selector> to preview what a query will actually return.

Managing rules

Masking rules are managed with FSQL statements — see Masking Commands for the full syntax:

MASK *.raw_data FROM GROUP all-users
UNMASK dns_activity.raw_data FROM GROUP soc-analysts
EXPLAIN MASKS FOR GROUP all-users
DROP MASK *.raw_data FROM GROUP all-users

Creating, removing, and listing another identity's rules requires the can_mask permission — a tenant-level permission that platform and tenant administrators hold by default. Administrators can delegate it to other users or groups, for example GRANT can_mask TO GROUP compliance-team. See Permission Commands for the full GRANT/REVOKE syntax. Standard users can still view only the rules that apply to themselves.

Guarantees

  • Fail-closed. If the masking rules can't be retrieved when a query runs, the query fails rather than running with weaker masking.
  • Audited. Every rule change is recorded in Query's tamper-proof audit trail, including who made the change and when.

Current limitations

  • Masked attributes may still be referenced in filter predicates. An analyst who can guess a value can confirm it by filtering on it and observing result counts. If this matters for an attribute in your environment, treat the attribute as unsuitable for masked-but-filterable access and contact Query about strict masking.
  • Masking removes attributes from results, which changes the result shape. Downstream consumers pinned to a fixed schema should select attributes explicitly.

Did this page help you?