Home / Your journey

3. Turn on ENFORCE

The promotion itself — preflight, replay, confirmation, step-up — and how to make the first one small enough to be boring.

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 and SIMULATE properly, this step should be uneventful. That is the goal — a promotion that feels like a formality means the work happened earlier.

#Promote

bashCopy
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:

bashCopy
# 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" }'

#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 403s 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.

#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.

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:

bashCopy
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.

#Next