> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inferwall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy Profiles: Configure Detection Behavior

> Policy profiles control InferenceWall's enforcement mode, scoring thresholds, and per-signature overrides — configured in YAML with no code changes required.

Policy profiles give you control over how InferenceWall behaves at runtime: which mode it operates in, where the decision thresholds sit, and whether individual signatures are enforced or demoted to monitoring. You configure all of this in YAML — no code changes required.

## Default policy

InferenceWall ships with a built-in default policy:

```yaml theme={null}
name: default
version: "2.0.0"
mode: enforce
thresholds:
  inbound_flag: 4.0
  inbound_block: 10.0
  outbound_flag: 3.0
  outbound_block: 7.0
  early_exit: 13.0
signatures: {}
```

The `signatures` field is empty by default, meaning all signatures run with their built-in settings.

## Enforcement modes

| Mode      | Behavior                                                                                         |
| --------- | ------------------------------------------------------------------------------------------------ |
| `monitor` | All signatures run and log matches, but the decision is always `allow`. Nothing is blocked.      |
| `enforce` | Signatures contribute to anomaly scoring. Scans that exceed thresholds return `flag` or `block`. |

## Thresholds

You can override any of the five thresholds in your policy:

| Threshold        | Description                       | Default | Strict |
| ---------------- | --------------------------------- | ------- | ------ |
| `inbound_flag`   | Score to flag incoming requests   | `4.0`   | `2.5`  |
| `inbound_block`  | Score to block incoming requests  | `10.0`  | `7.0`  |
| `outbound_flag`  | Score to flag outgoing responses  | `3.0`   | `2.0`  |
| `outbound_block` | Score to block outgoing responses | `7.0`   | `5.0`  |
| `early_exit`     | Score to skip downstream engines  | `13.0`  | `10.0` |

The "Strict" column shows values from the built-in strict policy profile, which is appropriate for high-sensitivity deployments.

## Per-signature overrides

Use the `signatures` field to override individual signatures within a policy:

```yaml theme={null}
signatures:
  INJ-D-001:
    action: monitor        # Override to monitor even in enforce mode
    anomaly_points: 3      # Lower the scoring weight
  INJ-D-008:
    action: enforce        # Force enforce even if global mode is monitor
  CS-T-003:
    action: monitor        # Demote this signature to monitor-only
```

### Override precedence

When determining how a signature behaves, InferenceWall applies this order:

1. **Per-signature override** — highest priority; always wins.
2. **Global policy mode** — applies to all signatures not explicitly overridden.
3. **Signature default action** — the `default_action` field set by the signature author; lowest priority.

This means you can force a single high-value signature to enforce even while running the rest of the pipeline in monitor mode — useful when you want to block only the most dangerous attacks while you calibrate thresholds.

## Recommended deployment workflow

<Steps>
  <Step title="Deploy in monitor mode">
    Set `mode: monitor` in your policy. InferenceWall will scan all traffic and log every match, but will not block anything. This lets you see what your real traffic looks like without risk.

    ```yaml theme={null}
    mode: monitor
    ```
  </Step>

  <Step title="Observe for 1–2 weeks">
    Review the logged matches. Look at score distributions, which signatures are firing, and on what content. Identify any signatures that fire frequently on legitimate traffic (false positives).
  </Step>

  <Step title="Configure allowlists for false positives">
    Demote noisy signatures to `monitor` via per-signature overrides, or raise the relevant thresholds. This brings false positives under control before you start enforcing.

    ```yaml theme={null}
    signatures:
      INJ-D-013:
        action: monitor   # Research/Academic Framing — too noisy for this app
    ```
  </Step>

  <Step title="Flip high-confidence signatures to enforce">
    Move your highest-severity signatures to `action: enforce` individually. Start with credential leakage (`DL-S-*`) and coercive injection (`INJ-D-029`, `INJ-D-030`) — these have near-zero false positive rates.

    ```yaml theme={null}
    signatures:
      DL-S-001:
        action: enforce
      DL-S-004:
        action: enforce
      INJ-D-029:
        action: enforce
    ```
  </Step>

  <Step title="Switch global mode to enforce">
    Once you are satisfied with the false positive rate, set `mode: enforce` globally. All signatures will contribute to scoring and threshold-based blocking from this point forward.

    ```yaml theme={null}
    mode: enforce
    ```
  </Step>
</Steps>

## Creating a custom policy

Copy the default policy, modify it, and save it to `~/.inferwall/policies/`:

```bash theme={null}
mkdir -p ~/.inferwall/policies
cp $(python -c "import inferwall; print(inferwall.__path__[0])")/policies/default.yaml \
   ~/.inferwall/policies/my-policy.yaml
```

The pipeline auto-discovers all `.yaml` files in `~/.inferwall/policies/`. To select a policy explicitly — for example in CI/CD or container deployments — set the `IW_POLICY_PATH` environment variable:

```bash theme={null}
export IW_POLICY_PATH=~/.inferwall/policies/my-policy.yaml
```

<Warning>
  If `IW_POLICY_PATH` points to a file that does not exist, the pipeline will fail to start. Verify the path before deploying.
</Warning>

***

For the full policy customization reference, including all available fields and environment variable overrides, see [Custom Policies](/guides/custom-policies).