Using DLP
DLP scans tool arguments and prompts for sensitive data on covered events. A rule's action can block the call, redact the value where supported, or just record a match. Coverage depends on the host, event, and configured surface.
For a custom rule, check availability, publish it, attach it, and verify that the intended surface receives it. Saving a draft alone does not enforce it.
1. Check DLP availability for the organization
Open Governance → Data protection. Check the Off / Monitor / Enforce mode control and the coverage rows for each surface. If the platform reports DLP as unavailable, changing the organization's mode cannot override that gate.
Off disables delivery of the organization's configured DLP rules. Rules saved while it is off remain stored. An enabled organization can still have no configured profile; complete the first-run setup if it is shown.
2. Choose detectors
Under Advanced → Built-in detectors, select the patterns you care about — SSN, credit cards, API keys, EU / Japan / Korea / APAC national IDs. These are maintained by us, so you do not write the regex.
Add a custom rule only for a pattern the built-in catalog does not cover.
3. Write and publish a rule
Under Advanced, New rule opens the form. Set its name, pattern, category, surface scopes, and action:
| Action | What happens on a covered, enforcing event |
|---|---|
block | The call is denied. The tool never runs. |
mask | The value is redacted and the call proceeds — where supported, see below. |
detect | The call proceeds. The match is recorded in the audit trail. |
Use Create & enable to publish and continue to project attachment, or Save as draft and publish from the rule list when ready. A draft is not delivered for enforcement.
4. Attach the rule to its intended projects
Do not stop at publishing. Attach the custom rule on Projects → your project → Data Protection, or bind it to a published policy version in the policy library's DLP binding panel and attach that policy to the project.
Project attachment and policy-version binding both feed project bundles. Deployments with organization-wide rule delivery enabled can also deliver organization-wide rules without an attachment. Check the coverage rows and rule reach indicators rather than assuming that an unattached rule is always inert. Built-in detector profiles are configured separately from custom rules.
Checking it works
Run a tool call on a covered event through a governed agent using a synthetic value that matches your rule. Then look at Audit for the decision, DLP status, and value-free rule summary. Matched values are not sent in that summary. For Antigravity, also confirm an enforcing host mode and that the denied tool call actually stops; an audit deny alone does not establish enforcement.
If the expected result is missing, check whether the rule is live, enabled, scoped to the surface, and attached (where required). Also check availability, the selected detector profile, host/event coverage, and runtime delivery. Dashboard configuration alone does not establish that a gateway or SDK has received the rule. Data protection integrations use their promoted releases; changing an organization mode or rule does not update an already pinned release.
Where mask actually masks
This matters before you test, because the behaviour is correct but surprising.
Masking requires the hook integration to emit rewritten tool arguments through a supported host contract. The integrations below enable this on Claude Code and Gemini CLI; the others return a deny for a mask match, whose enforcement depends on the host mode.
| Agent | A mask rule does |
|---|---|
| Claude Code | masks and proceeds |
| Gemini CLI | masks and proceeds |
| Cursor IDE, Cursor CLI | denies |
| Codex CLI | denies |
| Kiro CLI | denies |
| Antigravity | returns deny; expected to stop the call in default interactive mode, advisory in headless or always-proceed modes |
For these coding-agent hooks, rewriting is supported through the Python
SDK only. On the Node SDK hook path a mask rule returns a deny on every agent;
the host must enforce it.
These rows describe covered tool events, not every prompt or tool a host offers.
Coverage alone does not establish enforcement. Control Zero cannot detect
Antigravity's active mode; in headless or always-proceed mode, the original
secret can still reach the tool despite the deny, because no rewrite occurs.
On an enforcing host mode, a deny is not a failure. The secret does not
reach the tool — you lose the convenience of the call succeeding, not the
protection. Antigravity protection depends on an enforcing host mode. If you test
mask on Kiro or Codex and see a block, that is the system working.
Host coverage and rewrite limitations are described in what works where.
warn and DLP
A policy warn rule allows the call and flags it. DLP still scans a warn
when the scanner is configured and the event supplies scannable input; the DLP
result can still deny it. warn is a policy effect, not a custom DLP action.
If you are on a Python SDK older than 1.13.8, upgrade: before that version a warn
rule silently switched DLP scanning off for every call it matched.
pip install --upgrade controlzero
Circuit breaker
The browser extension can silence a rule in its local as-you-type scan loop. Paste and send-gate enforcement continue. See the browser extension circuit breaker reference for thresholds, audit events, and recovery.
If a rule you expect to fire is silent, check the audit log for circuit-break events on it and tighten the pattern.
Quick reference
1. Governance → Data protection → check mode and coverage
2. Advanced → select built-in detectors
3. New rule → pattern + action + scopes → publish
4. Attach to project, or bind to an attached published policy
5. Confirm delivery → run a covered tool call → check Audit