Actions

Every rule ends in one of five actions. Choosing between them is choosing what the employee experiences at the moment the rule fires — and how loud the resulting event is.

Action	What the employee experiences	Use for
Block	The paste or upload simply does not go through, with a clear message	Data that must never reach that destination
Redact	The sensitive spans are replaced before the content lands	Letting work continue minus the sensitive part
Coach	A warning with an override — the employee can proceed, and the override is audited	Building judgment without breaking workflows (“are you sure this belongs in ChatGPT?”)
Log only	Nothing visible; the event is recorded	Baselining before you enforce
Allow	Nothing at all	Carve-outs — e.g. an approved internal tool, placed above stricter rules

Notes on each

Block is the proxy’s native action for uploads: in-flight traffic is allowed or blocked, never rewritten (see Why interception). For pastes and form submissions, blocking happens at the destination with a message the employee can act on.

Redact happens at paste/submit time — the reliable moment to edit content — not in-flight.

Coach is the judgment-building action: the warning names the data type and the destination, and proceeding is an explicit, recorded choice. One constraint: Coach is unavailable on copy-time (everywhere-scoped) rules, because a warn-with-override needs a destination to warn about, and at copy time there isn’t one yet.

Log only is also what happens to anything no rule matches — the policy’s implicit floor is visibility, not enforcement.

Allow exists for ordering: an Allow rule above a broad Block rule is how you carve out an approved destination. See Writing rules for first-match-wins ordering.

Severity follows the action

Event severity is driven by the action taken — a block outranks a log-only — never by the data type alone. A rule’s data type says what was detected; its action says how seriously your policy treats it, and the Events page sorts accordingly.