Data protection

The data rules decide what happens when a run's content carries personal data, financial data, confidential business data or a credential. In the policy editor they are under What data may cross, and routing by data category is the bottom half of Where data may be processed.

Data rules act on what crosses a boundary while a run is happening. What is kept afterwards in traces, history and logs is scrubbed or encrypted whatever your policies say; see Personal data in traces and logs.

Categories and what finds them

What data may cross has one row per category:

The built-in patterns are maintained by Elizon and ship with releases; they cannot be edited, only excluded where they misfire (see Exclusions). Where a format has a check digit (IBAN, payment card, ЕГН, VAT), the detector validates it: a well-shaped but invalid number is not a match and writes no decision.

There is no health data category and no detector for special-category data.

A rule can also name one detector instead of a category: builtin.iban, builtin.vat.de, credential.aws, ner.PERSON, custom.<id>, dictionary.<id>. When a category rule and a detector rule both match a value, the stricter action applies.

Actions

Each row has an action and the boundaries it is checked at (Checked at: all boundaries, or any of Model calls, Tool calls, Agent output, Outbound):

At Outbound only Allow and Deny can be chosen: a workflow step has no reviewer to wait for, and placeholders cannot be sent to a machine (see Outbound workflow steps).

Defaults when a row has no rule

As soon as any policy applies to a run (one policy is enough, whatever it says about data):

• Credentials are denied before any model that is not Local. This holds in every edition.
• On Enterprise, personal data and financial data are redacted before any model that is not Local.

A model whose provider type is not known counts as not Local. With no policy at all, nothing is checked.

Exclusions

An exclusion tells a policy to ignore a known false positive, for example a serial number that happens to pass the payment-card check. Each one names a detector and an RE2 pattern; a match of that detector is ignored when the pattern matches the whole matched value (as written, or with its separators removed). Lookaround and backreferences are refused at save.

A policy can list up to 50. Across policies, only the exclusions every applying policy lists take effect. The editor warns when an exclusion would match every value of its detector, which switches the detector off.

Exclusions do not apply to the scrubbing of traces and logs.

Name recognition

Enterprise. Under the Personal data row, Name recognition turns on Elizon's self-hosted name-recognition model (no external service). Choose which entity types count as personal data (PERSON, ORG, LOCATION; PERSON only by default) and the confidence threshold (50–95 %): a name found below it is not a match. ORG and LOCATION that are not selected are still reported by detector (ner.ORG, ner.LOCATION) and can be targeted by a detector rule.

Name recognition reads at most POLICY_NER_MAX_BYTES (512 bytes by default) of new content per check. For longer content the policy chooses:

• regex only: the patterns still run on everything, and the decision is logged as partial_scan;
• block: the content is denied.

A text is never skipped silently.

Custom patterns and keyword dictionaries

Enterprise. The Detection library tab holds the Organization's own detectors. A policy uses one by ticking it under a category row (Detected by); it then runs only in runs whose policy names it.

• Custom patterns are RE2 regular expressions (linear time: lookahead, lookbehind and backreferences are refused at save, naming the construct and its position), up to 512 characters, with a category, a description and test samples. Saving runs the pattern against its samples: every positive must match and no negative may, or the save is refused listing the failing samples. At least one positive sample is required. An effective policy can use up to 50 custom patterns.
• Keyword dictionaries are term lists (codenames, client names, product names) assigned to one category. Matching ignores case, normalises Unicode, matches whole words, and recognises Bulgarian definite-article and plural endings. Up to 5,000 terms per dictionary and 20,000 per effective policy. This is how confidential business data is found in free text.

Both are versioned: every save is a new immutable version and takes effect at once in every policy that references it. Saving a pattern or dictionary that policies use shows the change and the policies that pick it up first. The decision log records which version matched. Managing the library needs policy.pattern.manage.

Declared sources

A source's owner can declare which categories it holds, in the Data classification field of the source's own settings: a Knowledge Base, an API tool, an MCP server (or one of its tools, which then replaces the server's setting), an app connection or operation, or a Data Table (whole table or by column). Content from that source then carries those categories whether or not a detector fires. A Knowledge Base chunk declared financial is redacted whole, as [FINANCIAL_1].

Classifying a source needs policy.update and the update right on the source. The Classified sources tab lists every classified source with who set it and when. Declaring is available on every edition.

Outbound workflow steps

Workflow steps that send data out with no Agent involved are checked on what they send, after the payload is rendered and before the host is vetted:

• Send Email: subject, body and recipients
• HTTP Request: URL query, the headers you wrote, body and multipart text parts
• FTP / SFTP upload: the file content
• App write operations: the operation's arguments
• MCP Tool: its arguments

The rules that apply are the Workflow's, its Project's and its Organization's: a row's All boundaries action, its Outbound action, and the outbound rule data.outbound.

An All boundaries: Redact or Escalate on a row therefore stops an HTTP Request, FTP, app or MCP Tool step that carries the category. If a workflow needs a person to look before something is sent, put a Human Review node before the send step.

Content the detectors cannot read (a binary attachment, a non-text upload) is sent and logged as partial_scan unless a policy says to block it. That choice (data.outbound.unreadable), the outbound rule's own actions (data.outbound.actions) and the step types it applies to (data.outbound.node_types: send_email, http_request, ftp, app, mcp_tool) are set through the policy rules document (the API, a Package policy_set), not in the editor. Redact in data.outbound.actions is accepted only when node_types is exactly [send_email].

The canvas shows, on each outbound step, which checks apply to it; after a run, a masked or blocked step shows What was sent.

Redaction and restore

Enterprise. A Redact action replaces each matched value with a placeholder that is consistent within the run: the same IBAN is [IBAN_1] everywhere in that run. The model sees placeholders and answers with them. The mapping from placeholders to values lives only in the AI worker's memory for the run; it is never stored, logged or exported, and it is gone when the run ends.

Real values (under the category rows) decides where values come back:

• End user sees real values in the answer (data.redaction.restore_in_output): the placeholders in the Agent's answer are replaced by the values before the user sees it. Off unless a policy turns it on; off in any policy wins.
• Tools that receive the real value (data.redaction.tools): for each tool you tick, the argument fields that receive real values (receives_real_values.fields; none ticked restores nothing), the destination field (destination_field, such as to or url) and the Restore destinations (restore_destinations: recipient domains or hosts, *. for subdomains).

A restore happens only when every destination the call names (the hosts or domains in the destination field and every address or URL in its other arguments) is in the tool's restore destinations. Otherwise the call waits for approval, and the tool gets placeholders until it is approved; on a voice call it is denied. The editor warns, per field, while a ticked tool has no restore destinations.

Across policies, a tool keeps real values only where every policy that sets this list allows it: the fields and destinations they all list, and only when they agree on the destination field.

Routing by data category

Enterprise. Where data may be processed → Rules that depend on the data (routing.data_rules) names, per category, which models may process it: by provider type, region or configuration. A category counts when a detector finds it or a declared source carries it.

When the Agent's configured model is not permitted for a category the call carries, the rule's fallback decides:

The rules of every applying policy apply together: a configuration must be permitted by every rule for the category, and the stricter fallback wins (deny, then redact, then route).

Once a run has been routed, it stays on that configuration: later model calls in the run go there too, a later redact sends placeholders to the same configuration, and a call the configuration can no longer serve is denied (routing.pinned_unavailable). Monitor mode logs the same decisions and changes nothing.

Known limits

• A voice Agent's direct Gemini model is checked by the model allowlist, but not routed or scanned by data category: what is said in the call reaches Gemini whatever the data rules say.
• The routed-value check on tool calls finds what the detectors recognise. A value only a declared source carries, or one the model reformats, is not found in tool arguments. If such a call waits for an approval, the reviewer sees that value as written; under an enforce routing rule, detected routed values show to the reviewer as labels such as [IBAN].
• In a Team run, a lead's own tool call that needs review cannot be reviewed and is denied.

Compliance mappings

Enterprise. The Compliance mappings section of the policy editor, and the same field on a custom pattern, dictionary, built-in pattern or name-recognition type, records which framework article or control you consider it relevant to: GDPR, HIPAA, ISO 27001, SOC 2, NIS2, DORA, PCI DSS, EU AI Act, or Other with your own name, plus your reference and note. Mappings are customer-declared: Elizon stores who added each one and when, does not check or certify them, and shows no standard's text. The evidence export can group decisions by mapping.