# Project controls In **Settings**, open **Projects** and select a project to configure its controls. Select a control’s name or **Details** to expand what it detects, an example and its detection scope. The action selector stays visible. Search includes these explanations and related OWASP tags. ## Choose an action | Action | Explicit scans | Completions | | --- | --- | --- | | No action | Report the detection without requesting enforcement. | Continue normally. | | Alert | Report the detection and alert action. | Continue with the finding in the response. | | Redact | Return redacted text for prompt and output scans, but not document scans. | Remove regex matches from input before model generation. | | Block | Return a block verdict for your application to enforce. | Block input before releasing a response, or withhold generated tool calls. | A blocked completion returns HTTP 403 with its own error code: `input_block` when a regex control stopped the request before any classifier or model call, and `policy_block` when the assessed verdict met a behavioral control set to Block. Both carry the decision in `zaun` (`enforcement: blocked`) so an application can show the finding. `forbidden` is reserved for credential and scope failures and is never returned for a content decision. An assessment that could not complete is not a block: the request fails with HTTP 503 `assessment_unavailable` and `Retry-After`, nothing is generated, and the recorded decision keeps the reason (`incomplete_assessment` or `assessment_mismatch`) for review. New controls default to **No action**, except **Self-harm**, which follows the project's **Risky** setting until you choose an action. When several controls match, precedence is **Block > Redact > Alert > No action**. A separate Block finding still wins after redaction. Select **Save changes** to publish the project’s configuration. The project application context is trusted classifier guidance for that project's workload. It is included in behavioral classification, while submitted content remains untrusted evidence. Use `config_version` and `revisions` in scan results when comparing two classifications: results are directly comparable only when the project configuration, classifier revision and reference revision are the same. ## Behavioral detections and regex checks Behavioral controls classify the intent and context of submitted content. Each control has one action. Related OWASP tags are mappings, not independent detections. Examples explain the category; they are not a guarantee that a specific phrase will always match. Organizations cannot create custom controls or edit definitions. ## Self-harm The **Self-harm** control covers content that puts a person's safety at risk, such as intent or plans to self-harm, an eating disorder, or harm to a child or dependent. Hex v1.3 reports these findings under their own control, so you can set Self-harm to Block while other risky behavior only alerts, or the reverse. Fraud, concealment, violence and help with crimes stay under **Risky**. A project that has never chosen an action for Self-harm follows its **Risky** setting until you choose one, so existing projects behave as before. The console shows that as "Follows Risky". Choosing any action, including No action, gives the control a setting of its own, and a later change to Risky no longer affects it. Without an entry, the configuration's `controls` object has no `self_harm` key, and the effective action is Risky's. Like every behavioral control, Self-harm blocks only when Hex v1.3 rates the finding a threat and the control is set to Block. A lower-confidence finding alerts. When Hex v1.3 finds a safety risk beside other risky behavior, such as violence, the result lists both a `Self-Harm` and a `Risky` finding, so each control acts on its own finding and the stronger action wins. `GET /v1/violations/summary` groups these findings under the `self_harm` category, and a result lists `Self-Harm` among its findings. Regex controls detect email addresses, phone numbers, Social Security numbers, credit card numbers, IP addresses, and recognized API keys or secrets. **Redact** is available only for these controls. Pattern matches do not verify that an address, account, credential or identity exists. Expand each control for supported formats and limitations. Regex checks apply to explicitly submitted scans and completion inputs. Automatic completion output checks assess generated tool calls, not plain assistant text. Use `/v1/scan/prompt` when your application wants to assess output text explicitly. ## Prompt retention Open a project's controls and scroll past the last control to **Enable in-session escalation, behavioral correlation and campaign detection**. It is on by default. Zaun keeps a redacted copy of each request for 30 days. Session escalation, behavioral correlation and campaign detection read that history, and Violations shows the text. Requests sent with `sample: false` are kept but never shown to you. Turn it off to keep no prompt text for the project. Zaun then stops storing and embedding new requests, those features lose the project's history, and Violations shows no prompt text for new requests. Text already kept stays until it expires. Only project admins can change it. The same setting is `retain_activity` in the project configuration. ## Organization settings The **Limits** tab in **Settings** displays the current tier, allowances and model prices. Only a Zaun administrator can change the tier, through **Zaun admin settings**. Organization admins can save **Do not train on my data** on the **General** tab in **Settings**, under **Data privacy**. It is enabled by default for existing and new organizations. When enabled, Zaun will not use the organization’s data to train models. Turning it off records permission; it does not start a training job. Scanning and activity history remain available. This preference does not disable organization-local reference samples or configure external inference providers’ data policies. ## Report an incorrect detection Open a violation and choose **Give feedback**. Anyone who can view that project can select **Incorrect detection** or **Wrong technique**, then optionally add notes. Feedback is stored for review only. It does not change the verdict, project controls, or your organization's training preference. Each completed prompt, output and document scan returns a `scan_uuid`. Completions return the input assessment as `zaun.scan_uuid` and, when tools were scanned, `zaun.output_scan_uuid`. Streaming completions include these in the final event. These IDs match the events in the violations feed and stay the same on an idempotent retry. Plain output text is not scanned and has no output scan ID. Regex-blocked completions return `zaun.scan_uuid` for the stored input check, even though the classifier was not called. Other requests rejected before assessment have no scan event to review. Queued document responses include `scan_uuid` immediately; feedback is accepted after assessment finishes. ### Submit feedback through the API Use a project key with `result:read`. The scan must belong to the same project and its result must still be retained. ```bash curl https://api.zaun.ai/v1/scan/feedback \ -H "Authorization: Bearer $ZAUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"scan_uuid":"3a723044-ed79-43c9-aa03-d74603503a49","reason":"wrong_technique","notes":"This was an extraction request, not execution."}' ``` `reason` is `incorrect_detection` or `wrong_technique`. Notes are optional, up to 2,000 characters. Do not include secrets or personal information. Repeating feedback for the same scan with the same API key updates that key's review. Console reviews are saved per member. Reviews remain until the project is permanently deleted.