---
title: 3. Turn on ENFORCE
description: The promotion itself — preflight, replay, confirmation, step-up — and how to make the first one small enough to be boring.
label: Turn on ENFORCE
---

`ENFORCE` is the mode Veefore exists for. Full pipeline, real refusals, real
execution for what is permitted, approvals created where policy asks for them.

If you did [OBSERVE](/journey/observe) and [SIMULATE](/journey/simulate)
properly, this step should be uneventful. That is the goal — a promotion that
feels like a formality means the work happened earlier.

## Promote

```bash
veefore deploy --mode ENFORCE --reason "Refund policy reviewed in CHG-4411"
```

Four things happen, in order.

**1. Preflight.** Checks for agents with no policy coverage, dangerous tools
permitted only by a default decision, expired trust evidence, credentials
overdue for rotation, and failing policy test cases. Any of these stops the
deployment.

**2. Replay.** Re-evaluates your recent observed traffic in `ENFORCE` and shows
you precisely which calls start being refused — before anything changes. Read
this list. "Enabling enforcement will refuse 14 of your last 400 actions, and
here they are" is a decision you can make; a surprise at 3am is not.

**3. Confirmation.** The blast radius, then a prompt.

**4. Step-up authentication.** `environment:set_mode` requires it. `--yes`
skips the confirmation prompt; it never skips step-up.

## Make the first one small

The thing `SIMULATE` genuinely cannot tell you is whether execution works — the
credential material, the destination resolution, the downstream's response to
your payload. All of that is exercised for the first time on your first real
`ENFORCE` execution.

So shrink the surface:

:::steps

:::step Promote staging first

Staging in `ENFORCE` exercises real execution against real tools with real
credentials. Surprises happen there, which is what staging is for.
:::

:::step In production, promote one environment, not all of them

If you have several production environments, do one. Watch it for a day.
:::

:::step Keep the pause control one command away

```bash
# Stop all protected execution in the environment. Immediate.
curl -X POST https://veefore.example.com/v1/environments/env_01ABC/pause \
  -H "Authorization: Bearer $VEEFORE_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "reason": "Unexpected refusal volume after enforcement enabled" }'
```

:::warning Pause. Do not drop the mode.
If something goes wrong, the instinct is to put the environment back in
`OBSERVE`. That is the worst option available: it stops refusing anything while
leaving everything running, so a misbehaving agent gets a free pass at exactly
the wrong moment.

Pause the environment, or pause the specific agent. Then diagnose.
:::
:::

:::

## The first hour

Watch four things.

**Refusal rate.** Should match what replay predicted. Materially higher means
the replay window was not representative — look at what is being refused that
replay did not cover.

**The approval queue.** Should be being worked. Approvals timing out at
`APPROVAL_EXPIRED` means nobody is watching, and the fix is a person, not a
config change.

**Agent error handling.** Your agents are now receiving `403`s in production for
the first time. Check their logs for crashes and for retry loops against
refusals.

**Downstream failures.** `EXECUTION_FAILED` and `EXECUTION_TIMEOUT` are not
Veefore refusing — they mea Veefore permitted the action and the downstream
rejected or timed out. The most common cause on a first deployment is credential
material stored under a key the broker does not read for that credential type;
see [Broker a credential](/build/broker-a-credential).

## What is now true that was not before

- A policy refusal stops the action. It does not execute.
- `REQUIRE_APPROVAL` creates a real approval and the action waits on a human.
- Credentials are brokered only for permitted actions.
- Reducing enforcement requires a reason, step-up, and writes a `CRITICAL` audit event.
- A dependency outage refuses protected actions rather than allowing them. See [Fail closed](/secure/fail-closed).

That last one is worth stating plainly: if policy evaluation becomes
unavailable, protected actions get `POLICY_SERVICE_UNAVAILABLE` and stop. Your
agents will be refused during a Veefore outage. That is the design, it is
tested in the chaos suite, and the alternative — allowing everything while the
authorization system is down — is not something a security product gets to do.

## Going backwards

Allowed, and never quiet. Reducing enforcement needs `environment:set_mode`, a
recorded reason, step-up authentication, and writes a `CRITICAL` audit event
that the Security Center surfaces.

If you need to roll back a *policy* rather than the mode, do that instead — it
is narrower:

```bash
veefore policies deploy pol_01ABC --version 3 --reason "Rolling back CHG-4411"
```

Rollback creates a new version with the old content, so the history stays
linear. See [Policy rollback](/operate/runbook-policy-rollback).

## Next

:::cards

:::card 4. Operate it | /journey/operate
Day two: queues, runbooks, rotation, review.
:::

:::card Emergency controls | /operate/emergency-controls
Every control, its blast radius and its preview.
:::

:::