1. Start in OBSERVE

Learn what your agent actually does before you decide what it should be allowed to do.

New environments start in OBSERVE so that adding Veefore to a running system cannot break it on day one. Everything executes exactly as before, and Veefore records what enforcement would have decided.

OBSERVE protects nothing

Actions execute. An action that ENFORCE would block runs in OBSERVE and reaches your downstream system. This mode is instrumentation. Do not leave production in it.

#What to do first

Wire the agent up and let it run normally

Protect your agent, register the tools it calls, and then just let it do its job for a few days. Do not write policy yet. You are collecting evidence about what the agent actually does, which is reliably different from what you think it does.

bash
veefore dev

streams every decision live with the policy and rule behind it.

Look at the tool inventory

bash
veefore status

The first useful surprise is usually here: a tool nobody remembered the agent could reach, or a destination nobody expected. Open the Agents page in the console and read the agent's tool list and its recent actions.

Find the divergences

A divergence is a decision where the effective outcome and the shadow outcome disagree:

json
{
  "mode": "OBSERVE",
  "decision": "ALLOW",
  "outcome": "OBSERVED",
  "shadow": { "decision": "BLOCK", "reason": "…" }
}

bash
veefore logs --limit 200

Every divergence is one of three things, and sorting them is the actual work of this phase:

	What it means	What to do
Correct refusal	The agent is doing something it should not	Fix the agent, or keep the rule
Over-broad rule	The rule is right in spirit, wrong in scope	Narrow the rule
Legitimate pattern you did not anticipate	The agent is fine; your model of it was wrong	Change the policy

Watch the risk signals

Open the Risk Center. In the first days a new agent trips every "new" signal — NEW_TOOL, NEW_RESOURCE, UNUSUAL_DESTINATION — because it has no baseline yet. That is correct and it will settle.

What matters is what is still firing after a week. A signal that fires on nearly every action is not discriminating and its weight needs lowering. A signal that never fires is either weighted too low or genuinely irrelevant to your traffic. Both are tuning information you cannot get any other way.

Record what you learn as test cases

Every divergence you decide is a correct refusal becomes a Given/Then case on the policy. Every legitimate pattern becomes a case asserting it is allowed.

By the time you leave OBSERVE you want a test suite built from real traffic rather than imagination. That suite is what will stop a future policy edit from breaking something you already reasoned about.

#How long

Long enough to see your traffic's variety. Concretely, long enough to have seen:

A normal working day and a quiet weekend
Your month-end or batch pattern, if you have one
At least one failure the agent recovered from
Every tool it is authorized for, actually used

For most teams that is one to two weeks. The honest signal is not elapsed time — it is divergences going quiet. When new divergences stop appearing and the ones you have are all deliberate, you are ready.

#What not to do

Do not write a comprehensive policy before you have data. You will write rules for things that never happen and miss the ones that do. Start from a template, then let the traffic tell you what to add.

Do not treat OBSERVE as a staging gate. It does not refuse anything, so "it worked in OBSERVE" tells you nothing about whether it works under enforcement. SIMULATE is the mode for that.

Do not leave it running indefinitely. An environment in OBSERVE for a month is an environment nobody is going to promote. veefore doctor and the Security Center both flag a production environment sitting in OBSERVE, because that is a finding and not a configuration.

#Next

2. Simulate

Run the full pipeline with real refusals and no side effects.

Write your first policy

Build the rules your OBSERVE data told you you need.