Policy and enforcement
Blank starts by watching, and does nothing louder until you decide to. Enforcement is opt-in, and it's designed so you never escalate faster than your data supports.
Enforcement modes
Your organization has one fleet-wide enforcement mode, and it's the ceiling on everything.
Owners and admins manage it in Policy → Rules. Viewers and auditors can read policy but cannot change it. Deployment never changes the mode for you.
- Monitor (the default). Record every finding, coach nothing, block nothing. This is where every deployment begins.
- Coach. Show the employee an in-page note when a medium-or-higher finding is about to be sent. They can remove it or proceed. It's a nudge, not a wall.
- Block. Cancel a send that policy says must not go out.
The effective action is always the quieter of the fleet mode and any rule, so an org in Monitor coaches nothing no matter what a rule says.
The 14-day gate
You can't escalate past Monitor until the org has 14 days of real data. Coaching people about a picture you haven't actually measured is how you lose their trust, so the gate makes sure the baseline is real first. Pulling the brake back down to Monitor is never gated. An admin mid-incident shouldn't have to wait.
Policy rules
Within Coach or Block mode, rules decide what happens to a specific finding. A rule targets any combination of four axes:
- the detector that fired (for example,
credit-card), - the AI tool (for example, ChatGPT),
- the tool's category (for example, chatbot),
- the user group.
When several rules match, the most specific wins (detector beats tool beats category beats group), then an admin priority, then the more restrictive action. A narrow exception can sit on top of a broad rule without deleting either.
Every change is versioned with who changed it and a readable diff, and a 30-day preview shows how many findings a rule would have affected before you turn it on.
In Policy → Rules, choose New rule, set the matching conditions and response, then Preview impact. Every filled condition must match; empty conditions include any value. AI tools and categories use catalog IDs. The outcome panel explains the organization ceiling, while the preview compares the complete proposed ruleset against current policy. Editing any field invalidates the preview, and saving or enabling requires a fresh one. Priority and the stable rule ID are under Advanced settings.
The preview uses the current organization mode. In Monitor, all actions stay in Monitor; a zero-change preview does not predict a later switch to Coach or Block. With no historical findings, the preview has no sample from which to estimate impact.
User-group targeting is not enforced yet. Rules currently apply to everyone matching their other conditions. Existing group-scoped rules show this warning even when no historical findings match them. New rules do not offer group targeting.
Detector health controls
Open Policy → Detectors → Detector health. Review each detector's sample size, precision estimate, and false-positive evidence before changing its responses. A small sample is not proof of accuracy.
Monitor only is a detector-specific safety override: findings are still recorded, but the detector cannot coach or block, even if a Block rule matches. Automatic demotions use the same override. Restore policy responses removes it and returns the detector to normal policy evaluation, limited by organization mode. Changes reach devices on their next bundle update, within 6 hours.
These estimates depend on employee reports, so unreported mistakes can make accuracy appear better than it is. Restoring responses does not clear false-positive reports; a later report can demote the detector again if it remains above the threshold.
The Block precision gate
You can't enable Block on a detector until it has cleared a 95% precision floor: enough real detections to judge, with a low-enough false-positive rate. Blocking on a noisy detector is blocking someone's actual work, so the gate is enforced on the server, not just hidden in the UI. Tool-wide and category-wide Block rules span many detectors and are allowed. A single-detector Block waits until that detector has earned it.
Coaching has a severity floor
Blank records every finding but only interrupts at medium severity and up. Low-risk findings, like a colleague's email address or a phone number, are on your usage picture but never in an employee's face. The vocabulary is closed and ours, so it can't be gamed by an odd value.
Custom detectors
Beyond the built-in detectors, you can add your own patterns, like an internal project codename or a customer-ID format. Each one is safety-checked (including against catastrophic regular expressions) before it's allowed to run on employees' machines.
- Open Policy → Detectors → Custom patterns and select New pattern. Owners and admins can create or change patterns.
- Enter a unique Detector id, Finding category, Severity, regex Pattern, and any Flags. An existing pattern's ID cannot be changed.
- Enter synthetic text in Test against sample text. Review the safety verdict and highlighted matches, including examples that should not match. Sample text stays in the browser.
- Select Save pattern after the safety check passes. Use Edit pattern, Enable pattern / Disable pattern, or Delete pattern on an existing record. Deletion asks for confirmation.
A safety verdict assesses whether the regex is safe to execute; it does not establish detection accuracy. Changes reach devices on their next bundle update. Organization mode and policy rules still limit the response.
Switching between Detector health and Custom patterns keeps an edited draft and sample text in memory. Leaving an edited rule or custom-pattern editor asks Keep editing or Discard changes. A failed save retains the draft; reloading or completing sign-out clears it. See dashboard navigation for the shared behavior.