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

# Enforcement Modes

> The three enforcement modes — dry-run, audit, and enforce — and how to stage a policy safely from preview to live blocking.

Every Nyx policy runs in one of three enforcement modes. Together they let you take a policy from "what would this do?" to "this is now blocking traffic" in deliberate stages — against your real traffic, before anything breaks.

## The three modes

| Mode      | In the datapath? | Drops traffic? | What it gives you                                                                    |
| --------- | ---------------- | -------------- | ------------------------------------------------------------------------------------ |
| `dry-run` | No               | No             | A hypothetical preview — what the policy would match, without touching live traffic. |
| `audit`   | Yes              | No             | Real findings against live traffic, logged; nothing is dropped.                      |
| `enforce` | Yes              | Yes            | Live enforcement — traffic that violates the policy is dropped.                      |

**`dry-run`** evaluates the policy without entering the enforcement datapath. It reports what the policy would match as a hypothetical preview, so you can check a policy's logic before it touches anything live.

**`audit`** loads the policy into the kernel datapath, where it evaluates live traffic in real time and logs every connection it *would* block — but lets all of it through. This is the mode that tells you the true impact of a policy: real traffic, real findings, zero drops.

**`enforce`** is the same as audit, except matching traffic is actually dropped. This is live enforcement.

## Staging a policy safely

The three modes form a progression. Each step gives you more confidence before the next:

```mermaid theme={null}
flowchart LR
    A[dry-run<br/>validate logic<br/>no datapath] --> B[audit<br/>live traffic<br/>logged, no drops] --> C[enforce<br/>violating traffic<br/>dropped]
```

You don't have to use all three — but the path from `audit` to `enforce` is the one that prevents outages. Run a policy in `audit`, review what it would have blocked, add explicit allow rules for the legitimate traffic you find, and only flip to `enforce` once the audit findings are clean.

## Where enforcement is set

Each policy carries its own `enforcement` field, set to `dry-run`, `audit`, or `enforce`. You control the mode per policy, so different policies can be at different stages at the same time — some enforcing, others still in audit.

The cluster-wide [`NyxClusterConfig`](/reference/nyxclusterconfig) also has an `enforcement` field. This sets the mode for the baseline policies that Nyx generates from `defaultMode` — it does not override the modes on your own policies.

## Staging a cluster-wide default deny

This is where modes and `defaultMode` work together. Setting `defaultMode: deny-cross-namespace` generates baseline policies that deny cross-namespace traffic — and `NyxClusterConfig.enforcement` decides whether those run in audit or enforce.

So you can stage even a cluster-wide default deny:

```yaml theme={null}
apiVersion: nyx.tracenyx.io/v1alpha1
kind: NyxClusterConfig
metadata:
  name: cluster
spec:
  defaultMode: deny-cross-namespace
  enforcement: audit
  excludedNamespaces:
    - kube-system
    - kube-public
    - nyx-system
```

With `enforcement: audit`, every cross-namespace connection that *would* be denied is logged, and nothing is dropped. Review those findings, add explicit allow policies for the cross-namespace traffic that's meant to flow, and once the log is clean, change `enforcement` to `enforce`. Cross-namespace traffic is then denied unless a policy explicitly allows it — and you got there without a single surprise outage.

## The same on Linux and Windows

All three modes behave identically whether a workload runs on a Linux node, enforced through eBPF, or a Windows node, enforced through a WFP callout driver. A policy in `audit` logs the same way on both; a policy in `enforce` drops the same way on both. A mixed Linux/Windows cluster runs one security model, not two.