DLP rules — Documentation

DLP (data loss prevention) is what lets Cortex give your employees access to external models. Every outgoing message is analyzed before it reaches a provider: sensitive items are replaced by tokens such as [EMAIL_1], the model's reply is checked in turn, and the audit journal records only the type of what was detected, never its value. Everything is set in the console, under "DLP policies".

What Cortex detects

Detection works in three levels that add up.

The gateway patterns are always active. The console calls them "System patterns" (21):

Category	Patterns
Government identifier	"Social insurance number (CA)", "Social Security number (US)"
Financial	"Credit card"
Contact info	"Email address", "Phone (North America)", "Phone (international)"
Network	"IPv4 address", "IPv6 address"
Secret	"AWS access key", "AWS secret key", "JWT token", "Private key block", "Slack token", "GitHub token", "Bearer token", "OpenAI API key", "Anthropic API key", "Stripe API key", "SendGrid API key", "Hugging Face token", "Generic credential"

Social insurance and card numbers are validated by their check digit, which limits false positives. The gateway also flags, in the audit only, text that looks like base64, hexadecimal or a high-entropy string, without blocking or redacting it.

Names, with the AI engine (optional). The node recognizes people's names ("Person") in French and English, as well as opaque secrets that follow a word such as "key" or "password". It does not report organizations, cities, regions or countries.

The local model, with the AI engine and an inference backend configured. A model served by an inference backend you run (Ollama or vLLM, for example) reads the text to find what patterns cannot see: "Person", "Precise place" (addresses, neighbourhoods, buildings), "Secret", "Health", "Financial (personal)" and "Internal identifier". This model reads the original text, so it is meant to run inside your network.

These detections cover known formats and do not guarantee completeness.

Profiles per destination

The "Profiles per destination" tab sets the "Filtering profile" of each destination: "Full DLP" (described in the console as maximum protection for external destinations) or "Light profile" (reserved for the private network). It lists the "Active components": "Upstream redaction", "Pseudonymization", "Downstream filter" and "Audit", the last two being "not disableable". All four switches are on for every destination. For now, the profile is a policy label that the employee sees under the input box: the console states that "All active patterns apply to every destination".

The "Light profile" on a destination whose "Address resolution" is not "Private" requires an approval. In "Edit", the "Network guardrail" shows that resolution ("Public", "Private" or "Unknown") and the "Light-profile approval".

Create the destination with "Full DLP".
Open it with "Edit" and choose "Light profile": the guardrail asks for the approval and offers "Approve…".
Tick the acknowledgement, type "APPROVE" and confirm, then click "Close". The approval is recorded.
Click "Save" to apply the "Light profile".

Once the approval is recorded, you can also close "Edit destination" without saving and choose "Light profile" in the "Profiles per destination" tab of "DLP policies". Changing the "Endpoint" withdraws the approval; saving without changing it keeps it.

Your own patterns

System patterns cannot be disabled or deleted: only their severity changes, between "Warn" (redacted then pseudonymized) and "Block" (the send is refused). Your patterns come on top.

Open the "Detection patterns" tab, then "New pattern".
Optional: choose a "Base pattern". The form suggests the name {name}_derived and copies the category, pattern and severity; the system pattern stays active. Narrow the expression: a pattern identical to an existing one is refused.
Fill in the "Name" (lowercase letters, digits and _), the "Category" (existing, or created on the fly), the "Pattern (regex)" and the "Severity".
Click "Create".

Cortex refuses a pattern longer than 512 characters, with invalid syntax or at risk of ReDoS (backreferences, nested quantifiers). A pattern takes effect on the next request. Under "Custom rules", you can disable it, edit it, change its severity or delete it; "Export patterns" downloads the definitions as JSON.

Cortex screenshot: the DLP policies page, with the pattern and detection counters, the Detection patterns tab and the expanded list of system patterns — The system patterns, with their category, expression and severity.

Test the filtering

The "Filtering test" tab analyzes a "Sample text" without sending or keeping anything. Click "Run the test": the text is shown with its tokens, followed by the number of entities detected, the "Sending blocked" badge when it applies, and, for each detection, the pattern (system or custom) and its severity. The test applies the gateway patterns, yours included, but not the names or the local model.