Using the policy engine dry-run mode before you commit
The most common way teams break production with a service mesh is by applying an access policy that is subtly wrong. A rule that denies traffic it should allow, or allows traffic it should deny. The error is usually obvious in retrospect, but by the time it is obvious, something is down. Dry-run mode exists to catch these errors before they reach production.
How the snapshot is taken
When you invoke dry-run mode, the policy engine captures a snapshot of recent traffic from the mesh's routing log. The snapshot covers a configurable window. Default is the last 15 minutes of observed traffic. And represents the actual request patterns your services are producing right now, not a synthetic fixture.
This matters because synthetic test traffic rarely covers the full range of service-to-service calls in a real system. A policy that passes all your integration tests may still deny a legitimate call that only happens during a specific workflow. A background job, a webhook handler, a rarely-triggered reconciliation loop. The live snapshot is more likely to surface these cases.
Reading the diff output
The dry-run output is a diff showing, for each observed request in the snapshot, whether the proposed policy would allow or deny it, and which rule matched. Requests that would be newly denied are flagged. Requests that are currently denied but would be allowed under the new policy are also flagged. Both directions matter.
A common mistake is to focus only on the 'newly denied' entries and ignore the 'newly allowed' ones. If you are tightening policy, newly allowed entries should not exist. If they do, it means your current policy was more restrictive than intended and the new policy has a gap.
Committing after dry-run
Once you are satisfied with the diff, committing the policy is a single command. The policy engine applies the new rules atomically. There is no window where a partial policy is active. The commit also writes an audit log event with the full policy diff, the operator identity, and a timestamp, so the change is traceable.
The policy language reference and a worked example of a dry-run workflow are in the docs under 'Policy engine'. If you have a policy question that the docs do not answer, the community forum is the right place to ask.