> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Personal Information Guard > Detect and redact personal data (PII) before it reaches a model, on AI workflow nodes or with standalone mask and restore nodes, and restore it afterwards. ## Overview Personal Information Guard (PII Guard) keeps personal data out of the payloads you send to a model. It works two ways: as a configuration block on every AI workflow node, and as standalone **Mask Personal Data** and **Restore Personal Data** nodes you place in a workflow yourself. When the node-level control is turned on, it detects personal data and replaces it with placeholders before the payload reaches the model, then handles the redacted content throughout the node run. Detection and redaction run in the **data-privacy** AI Platform service; the workflow node calls it synchronously and **fails closed** — if the service errors, the node stops and no redacted artifact is produced. The node-level control applies to Custom Agent, Intent Classification Agent, Extract Data from File, and all AI Text, Document, Image, and Data Operations nodes. > [!NOTE] > > PII Guard is the privacy control inside AI workflows. It is distinct from process-level [data anonymization](https://docs.flowx.ai/6.x/setup-guides/flowx-engine-setup-guide/configuring-access-roles-for-processes.md) (`FLOWX_DATA_ANONYMIZATION`), which redacts process data by role. > [!NOTE] > > PII Guard works two ways: as a **node-level** control on an AI node, which redacts a payload before it reaches the model and restores it in the response, and as **separate mask and restore nodes** you place in the workflow yourself. It is distinct from the Knowledge Base **Containing Personal Information** setting, which keeps a Knowledge Base's content on-box by indexing it with a local embedding model. A Knowledge Base does not run PII Guard, and PII Guard does not change how a Knowledge Base is embedded. See [Knowledge Base overview](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/knowledge-base-integration/knowledge-base-overview.md#containing-personal-information). *** ## Configuration The guard is configured per node in the Designer. Turning it on exposes the detection options below. The table describes the node-level control. The **Mask Personal Data** node offers the same detection options in its own **Detection settings** panel. | Field | Description | | - | - | | **Enabled** | Turn the guard on for the node. **Default:** OFF. | | **Detection Algorithm Sensitivity** | One of **Strict**, **Balanced** (default), **Relaxed**, or **Custom**. Maps to a server-side detection threshold. **Custom** exposes a sensitivity slider (`0.00`–`1.00`). | | **Detection Target** | Choose which payloads are scanned: **Node Input**, **Node Output**, or both. At least one must be selected. **Default:** Node Input. | | **Personal Info Types** | Opens the **Customize Entities** modal — the picker for which entity types are detected. All are enabled by default. The catalog is served from `GET /integration/api/workflows/personal-information-guard/entities`. | > [accordion] Supported entity types (24) > > **Universal (8)** > > `EMAIL`, `PHONE`, `CREDIT_CARD`, `IBAN`, `MAC_ADDRESS`, `CRYPTO_WALLET`, `PERSON`, `ADDRESS` > > **Regional — EN (6)** > > `SSN`, `US_PASSPORT`, `US_BANK_ACCOUNT`, `US_ITIN`, `UK_NHS`, `EU_VAT_ID` > > **Regional — RO (10)** > > `CNP`, `CUI`, `RO_IBAN`, `RO_PHONE`, `RO_PASSPORT`, `RO_ID_CARD`, `LICENSE_PLATE`, `HEALTH_CARD`, `POSTAL_CODE`, `LANDLINE` *** ## How it works * **Input scan** runs before the AI request is built, so placeholder substitution and user-message extraction both see redacted data. Values from earlier nodes that the prompt references are redacted as part of the inputs. The static **Instructions** text written on the node is not scanned, so example personal data in it, such as a sample email in a few-shot example, reaches the model unchanged. * **Source-file scan** runs for document and image AI nodes. The data-privacy service uploads the redacted artifact back to the same storage as the source, so the file path used for the request is swapped without changing the data source binding. * **Output scan** runs after the model completes, on a bounded-elastic scheduler so the data-privacy call does not pin the event loop. * **Restoration (deanonymization)** — for the node-level control, when an input scan ran the guard keeps the placeholder-to-value mapping for the duration of that node's run and automatically restores the original values in the model's response, so downstream nodes and the end user see real data rather than placeholders. When an output scan is also on, PII the model newly introduced is redacted first, so only model-introduced values stay masked. Restoration also holds across chat-driven workflows that carry conversation memory. * **Irreversible redaction for async file flows** — asynchronous document-parser flows keep permanent placeholders. Their mapping is never persisted, so values redacted in those flows are not restored. * **System-prompt appender** — for Custom Agent nodes with an input scan, the runner appends a non-editable segment teaching the model to treat indexed placeholders like `` or `` as opaque tokens and copy them back verbatim. It runs after the input and chat-history scans so its literal tags are not mistaken for PII. * **Fail-closed** — any error from the data-privacy service stops execution, including a failed restoration (the node halts rather than let placeholder data reach downstream nodes). The error surfaces on the node run log; redacted artifacts are not produced on failure. This describes the **node-level control**. The standalone Restore Personal Data node behaves differently: see [Masking and restoring across several nodes](#masking-and-restoring-across-several-nodes). *** ## Masking and restoring across several nodes The node-level control redacts and restores inside a single AI node. To keep personal data redacted across several steps, use the **Mask Personal Data** and **Restore Personal Data** nodes instead. Both sit under **Tools** in the workflow node palette. Place **Mask Personal Data** before the steps that must not see real values, and **Restore Personal Data** after them. The masking is reversible later in the same run. ![The Mask Personal Data and Restore Personal Data node panels side by side, with the Input field, detection settings on the Mask node, and the restore outcome banners on the Restore node](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/pii-mask-restore-nodes.png) Each node takes an **Input**, a reference to the text or object it should act on, written as a `${...}` binding such as `${application}`. It is a required field on both nodes. > [!NOTE] > > **Masking does not overwrite your data.** The masked copy is written under the node's response key and the original value is left untouched, so a later step can still read the unmasked source if it is entitled to. **Mask Personal Data** has its own **Detection settings** panel with two of the node-level control's options: **Detection Algorithm Sensitivity**, including the **Custom Sensitivity** slider, and **Personal Info Types**, opened from a **Customize List** link that shows how many of the entity types are selected. Both work exactly as described in [Configuration](#configuration). > [!NOTE] > > There is no **Detection Target** on the Mask node. The node scans the value you point it at, so the direction is fixed rather than offered as a choice. **Restore Personal Data** has no detection settings at all: it matches the reference the Mask step left behind. ### Restoring is optional Nothing requires a Restore node. The placeholder map belongs to the workflow run and is deleted when that run finishes, fails, or is cancelled, so leaving data masked for the rest of the run is a supported outcome. A retention limit clears the map for runs that end without reaching one of those points. ### Restore outcomes **Restore Personal Data** reports one of three outcomes in the run log, along with the placeholders it matched, the ones it did not find, and any it did not recognise. | Outcome | When | Result | | - | - | - | | **Complete** | Every placeholder the run stored was found and put back. | The node succeeds. | | **Partial** | The input carries placeholder-shaped tokens this run never issued. | The node takes its **failure exit**, and still writes the restored payload. | | **Failed** | Nothing could be restored: the input did not resolve, the map could not be read, or the input carries none of the stored placeholders. | The node takes its **failure exit** with no restored payload, only the error. | > [!WARNING] > > The Restore node does not halt on failure the way the node-level control does. A partial or failed restore is routed down the node's failure exit so a branch can react to it. Connect that exit if a failed restore has to be handled; if you leave it unconnected, a restore problem stops the workflow the same way any unhandled node failure does. A placeholder that the run stored but cannot find in the input does **not** make the restore partial. A step in between may legitimately have summarised or dropped the text it sat in, so it is reported and nothing more. Only unrecognised tokens change the outcome. An input that carries no placeholders at all restores as **Complete**. A record with no personal data in it masks nothing, so an empty map is the normal result rather than a lost one. The node writes `restored`, `outcome`, and an `integrity` breakdown under its response key, so a branch can read what happened without parsing the run log. > [!NOTE] > > Use the standalone nodes when the redaction has to span more than one node, and the node-level control when a single AI node's payload is all that needs protecting. The two mechanisms share the same detection settings and the same entity catalog. *** ## Run-log and detections Each enabled scan adds a `personalInformationGuard` block on the node response: | Field | Description | | - | - | | `scanStatus` | `COMPLETED`, `SKIPPED`, or `FAILED`. | | `totalDetections` | Total number of entities detected across `detections`. | | `detections` | List of per-entity detection items (see below). Empty when nothing was detected. | | `errorMessage` | Populated when `scanStatus = FAILED`. | | `sourceType` | `TEXT`, `DOCUMENT`, or `IMAGE`. Identifies what the scan ran against. Null for text-only scans. | | `originalStoragePath`, `redactedStoragePath` | Set for `DOCUMENT` and `IMAGE` scans; both point at the data source bound to the node. | Each item in `detections` carries: | Field | Description | | - | - | | `entityKey` | Entity type detected (for example `EMAIL`, `PHONE`, `IBAN`). | | `confidence` | Detector confidence score, `0.00`–`1.00`. | | `originalValue` | The exact substring matched in the source. | | `replacement` | The placeholder string that replaced `originalValue` before the model call. Input-scan placeholders are indexed, for example ``. A person's name becomes `` or `` when the name indicates gender, and `` otherwise. | | `direction` | `INPUT` or `OUTPUT` — which scan direction produced this detection. | | `sourceType` | `TEXT`, `DOCUMENT`, or `IMAGE` — which payload was scanned. | | `timestamp` | When the detection was made. | | `regions` | Bounding boxes (`x`, `y`, `width`, `height`) for `DOCUMENT` and `IMAGE` detections. Null for `TEXT`. | Document and image scans surface the same per-entity detail as text scans, so the run console shows the matched values, replacements, and confidences regardless of which AI node type produced them. ### Request after PII anonymization When the input scan is enabled, the workflow run log adds a **Request after PII anonymization** entry right after the detections for that node. It shows the request exactly as the model received it, with placeholders in place of the detected values: * **Instructions — system prompt**: the system prompt sent to the model. * **Context and chat message — user prompt**: the context and message sent to the model. If the scan found nothing to mask, the entry says **The model request is unchanged.** so you can confirm the model saw the original text. *** ## Setup The data-privacy service connection is configured with `FLOWX_DATAPRIVACY_BASEURL` and `FLOWX_DATAPRIVACY_TIMEOUTSECONDS` — see the [Integration Designer setup guide](https://docs.flowx.ai/6.x/setup-guides/integration-designer-setup.md#service-communication). *** ## Related resources > [card] [Custom Agent node](https://docs.flowx.ai/6.x/ai-platform/agent-builder/node-types.md#custom-agent) > > Per-node configuration, including the PII Guard toggle > [card] [Extract Data from File](https://docs.flowx.ai/6.x/ai-platform/agent-builder/extract-data-from-file.md#personal-information-guard) > > PII Guard on document and image extraction nodes > [card] [Intent Classification Agent](https://docs.flowx.ai/6.x/ai-platform/agent-builder/intent-classification.md#personal-information-guard) > > PII Guard on intent classification nodes > [card] [Integration Designer](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md) > > AI workflow nodes and their configuration ## Related topics - [Integration Designer](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md) - [Extract Data from File](https://docs.flowx.ai/6.x/ai-platform/agent-builder/extract-data-from-file.md) - [Intent Classification Agent](https://docs.flowx.ai/6.x/ai-platform/agent-builder/intent-classification.md) - [Agent typologies](https://docs.flowx.ai/6.x/ai-platform/patterns/agent-typologies.md) - [FlowX.AI 5.8.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.8.0-may-2026/v5.8.0-may-2026.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.