Concepts

Environments

Every organization has Development, Staging and Production. Each has its own provider connections, API keys, masking rules, limits and MCP servers, so a rule can be tried in Development before it applies to Production. Organization-wide settings (masking failure behavior, end-user messages, notification defaults) are under Settings › Organization security.

API keys

Keys belong to one environment and have a purpose: Gateway keys forward provider traffic (and may mask/unmask), Redaction keys only mask and unmask, EDM keys only upload Exact Data Match hashes. Keys can expire; Maskflare keeps only a hash of each key.

Policies

Masking rules decide what is sensitive. Turn on detector packs (global data, credentials, healthcare, person names and 47 country packs) or add your own patterns and dictionaries; the detector reference lists every detector with an example and the keywords that gate it.

Actions

Each rule has an action: mask (a reversible mf_mask_ token), redact, partial, hash, format-preserving encryption, alert (forward unchanged, count it) or block (refuse the request with `sensitive_data_blocked`).

Shadow rules

A rule in shadow mode is evaluated and counted but changes nothing, so you can see what it would catch on real traffic before enforcing it.

Approvals

Masking changes are proposals. Another owner, admin or security member approves or rejects them under Approvals (maker-checker); a one-admin organization can allow self-approval. Approvers get an email when a change waits for them.

Tokens and re-hydration

A masked value becomes an mf_mask_ token; the value is kept encrypted in the vault, scoped to your organization, environment and key, for 30 days. With response restoration on for a key, Maskflare puts the real values back into the provider's answer before your application sees it, streams included. The SDKs' unmask does the same for text you hold.