Configuring Detection Policies and Severity Levels

The policy model in one paragraph

Every Zeuslock policy is a matrix of finding types (what was detected) crossed with actions (what to do about it). For each finding type, you pick one of three actions: Monitor logs the event and forwards the prompt untouched; Anonymize rewrites the sensitive value in place using format-preserving redaction before the prompt leaves the device; Block refuses the request and shows the user an inline explanation. Actions are assigned per finding type, per group, and optionally per destination. There is no global on/off switch — that is intentional.

Finding categories you can act on

Out of the box Zeuslock ships detectors in five families. You assign an action to each one independently.

• Credentials — api_key (AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, Bearer tokens), password, jwt, private_key, connection_string, env_variable.
• Financial — credit_card (Luhn-validated), IBAN, crypto_wallet.
• PII — email, phone, US SSN, French NIR (Sécurité Sociale), passport, postal address, ip_address.
• Source code — heuristic detection of pasted proprietary code, with language fingerprinting.
• Organizational identifiers — your custom detectors (project codenames, internal customer IDs, M&A targets). See the developer guide on custom detectors for the full authoring flow.

Severity levels and how they are assigned

Severity is computed at detection time from three signals: the finding type's intrinsic risk, contextual heuristics around the match (surrounding tokens, prompt structure, destination), and the detector's confidence score. You can override the default mapping per finding type, but we recommend keeping the defaults for the first month.

The rollout we recommend

Do not start with Block. The first two weeks of any DLP deployment teach you what your organization actually pastes into ChatGPT, Claude, and Gemini — and the answer is almost always more varied than the security team predicted. Stage the rollout in three phases.

1. Weeks 1-2 — Monitor everything. Set every finding type to Monitor. Watch the Incidents dashboard daily. Tune custom detectors. Identify the noisy finding types specific to your environment.
2. Weeks 3-5 — Anonymize finance and PII. Flip credit_card, IBAN, email, phone, passport, SSN, NIR, and address to Anonymize. Format-preserving redaction means the downstream LLM still gets a structurally valid value, so user workflows do not break.
3. Week 6+ — Block credentials and source code. Flip api_key, password, jwt, private_key, and source code to Block. By this point users have seen enough Anonymize banners that they understand why Zeuslock refuses, and your false-positive rate is low enough that blocks land cleanly.

Per-group overrides

One policy rarely fits the whole company. Developers paste API keys and code into Copilot all day; sales pastes customer lists into ChatGPT to draft outreach; finance pastes IBANs into Gemini for reconciliation. Each group needs a different posture.

1. Go to Settings → Policies → Groups.
2. Pick the SCIM group (or create a manual group) and click Override default policy.
3. You see the same matrix as the default policy, with inheritance arrows next to every cell. Cells you do not touch keep inheriting from the default — so when you change the default later, those cells update automatically.
4. Save the override. It takes effect on the next prompt; no client restart needed.

A common pattern: developers get Anonymize on api_key (with structurally valid fake keys so their code samples still parse), while everyone else gets Block.

Time-of-day exceptions

Risk is not constant across the day. After-hours prompts to consumer AI tools are statistically more likely to be exfiltration or careless side-projects. In Settings → Policies → Schedules, attach a stricter policy variant to non-business hours — for example, escalate Anonymize to Block on credentials between 20:00 and 07:00 local time, and on weekends. Schedules respect each user's timezone from their SCIM profile.

Per-destination overrides

Not every AI tool deserves the same trust level. We recommend three tiers.

• Vetted internal LLMs (a self-hosted Mistral, an Azure OpenAI deployment inside your tenant) — loosen to Monitor on PII and finance, keep Block on credentials.
• Vetted commercial tools (ChatGPT Enterprise, Claude for Work with a signed DPA) — apply your default policy.
• Unsanctioned or high-risk tools (DeepSeek, Poe, any tool flagged by Shadow AI detection) — escalate everything one level. Anonymize becomes Block, Monitor becomes Anonymize. Zeuslock auto-reports the first use of any unsanctioned tool to the CISO.

Custom detectors

Custom detectors let you catch organizational identifiers — internal project codenames, M&A target names, employee ID formats, customer reference numbers. They participate in the same severity model as built-in detectors and can be assigned any of the three actions. The full authoring workflow, including backtest tooling against the last 30 days of traffic, lives in the developer guide.

Test every policy change with dry-run

Before you activate a policy change, run it in dry-run mode. Zeuslock replays the last 24 hours of prompts through the proposed policy and shows you exactly what would have been blocked, anonymized, or logged — by user, by group, by destination. If dry-run shows 400 new blocks on the legal team because of a Bearer token false positive in their contract templates, you find out before they do. Activate only when the dry-run report matches your intent.

What to watch in the first month

• The Incidents dashboard, daily, filtered by Critical and High.
• The False Positive queue — anything flagged here gets fed back into detector tuning.
• Shadow AI report — new tools appearing in your environment.
• Per-group block rates — if one group is generating 10x the blocks of another, the policy probably needs an override, not a lecture.