Veefore docs

4. Operate it

What day two looks like — the rhythms, the reviews and the things that rot if nobody owns them.

Enforcement is on. The work now is keeping it correct as your agents, tools and team change. Most of what degrades an authorization system is not an attack; it is drift — a policy nobody revisited, evidence nobody renewed, a queue nobody watched.

#Daily

Work the approval queue. It needs a named owner and a response-time expectation. Approvals reaching APPROVAL_EXPIRED are actions that silently did not happen. See Approvals queue.

Scan the Security Center. CRITICAL audit events, open incidents, blocked A2A connections, pending MCP servers. It is the one page that is worth looking at even when nothing is wrong, because it is where "nothing is wrong" gets confirmed.

Check refusal volume. A sudden change in either direction is information. A spike means something changed — an agent, a policy, or a downstream. A drop to zero means enforcement might not be doing anything.

#Weekly

Review the Risk Center. Score distribution, signal breakdown, highest-risk tools, destinations in play. Signals that fire on everything need lower weights; signals that never fire need attention or removal from your mental model.

Run doctor across the fleet.

bash
veefore doctor --strict

In CI, on a schedule, with the result going somewhere a person reads.

Verify the audit chain.

bash
veefore audit verify

On a schedule, not only after an incident. A check you run only when you suspect something tells you nothing about when the problem began.

#Monthly

Review policies against reality.

bash
veefore policies diff pol_01ABC --from 4 --to 7

Ask of each policy: is there a rule here that has never matched? Is there a refusal happening regularly that should be a fixed agent instead of a standing block? Is any BLOCK rule being routinely worked around by a human doing the thing manually — because that is a rule that is wrong, not a control that is working.

Review delegations.

http
GET /v1/delegations/graph

Delegations accumulate. Look for grants that outlived their purpose, chains deeper than they need to be, and ceilings set higher than anything that has actually been used.

Review agent inventory. Agents that have not acted in a month are either retired or forgotten. Both should be paused or decommissioned. A dormant agent with live credentials is a liability with no upside.

Rotate. Agent keys and credentials, on a schedule.

bash
veefore agents rotate-key agt_01ABC

Rotation invalidates outstanding sessions and leases, so do it deliberately rather than reactively.

#Quarterly

Pull an audit evidence pack.

bash
veefore audit export \
  --format csv \
  --reason "Quarterly SOC 2 evidence" \
  --out audit-2026-q3.csv

Watermarked and hashed, so the recipient can prove the file is unaltered.

Renew trust evidence. Security attestations and compliance evidence expire. The EXPIRING status exists so you can act inside a window; the TRUST_EVIDENCE risk signal exists so lapsing is visible even if no policy explicitly requires that type.

Walk a runbook. Pick one and actually do it, against staging. A runbook nobody has executed is a document, not a capability.

Compromised agent Containment, revocation, blast radius
Policy rollback Reverting a bad activation
Credential leak Rotation under pressure
Dependency outage What fails closed and what to do

Review roles. Who holds security:emergency_action? Who holds policy:activate? Who holds audit:export? These accumulate quietly. See RBAC.

#When something changes

Change Do this
New agent veefore init, then OBSERVE long enough to build a baseline before promoting
New tool Register, then authorize deliberately. Registration grants nothing
New dangerous tool Add a rule before authorizing anyone. doctor flags it otherwise
New team member Grant a role, scoped to a workspace. Avoid OWNER
Someone leaves Remove the member. SCIM does this automatically if configured
Policy edit New version, tests pass, step-up, reason. Non-negotiable
Downstream API change Update the tool, rotate the credential if auth changed

#What rots if nobody owns it

Four things, in rough order of how often they are the actual cause of an incident:

  1. The approval queue. Unwatched queues turn approval rules into timeouts.
  2. Trust evidence. Silently expires and silently changes decisions.
  3. Credential rotation. Nothing breaks, until the key leaks.
  4. Policy relevance. Rules written for a system that has since changed.

Put each one on someone's name. doctor reports on all four, which makes them visible, but visible is not the same as owned.

Identity, authority, policy and enforcement for autonomous AI agents.