---
title: 4. Operate it
description: What day two looks like — the rhythms, the reviews and the things that rot if nobody owns them.
label: Operate it
---

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](/operate/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](/operate/runbook-compromised-agent) | Containment, revocation, blast radius |
| [Policy rollback](/operate/runbook-policy-rollback) | Reverting a bad activation |
| [Credential leak](/operate/runbook-credential-leak) | Rotation under pressure |
| [Dependency outage](/operate/runbook-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](/secure/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.

## Related

:::cards

:::card Run the stack | /operate/run-the-stack
Processes, health, scaling.
:::

:::card Observability | /operate/observability
Metrics, traces, logs and what to alert on.
:::

:::card Troubleshooting | /operate/troubleshooting
The failures people actually hit.
:::

:::card Compliance | /secure/compliance
Control mapping with live evidence.
:::

:::