Before an agent policy becomes enforcement

Name the work, the authority and the enforcement point.

A policy change often begins as a reasonable sentence: restrict an agent’s tools, remove an unsuitable model route, or set a workflow’s spending limit. The sentence is only the beginning. The reviewer needs to know which identities, work classes and routes it covers, where it will be enforced, and what the work will do when the rule objects.

Write the expected change in behavior. If a document agent should stop using a write-capable tool, name the agent’s approved role and the affected tool boundary. Explain what remains available for completing the job. A rule that removes an essential dependency can turn a privilege reduction into repeated failures and workarounds.

Coverage is part of the decision. An inline control governs traffic that actually passes through it. A configured rule does not establish that every runner, application or route uses that path. List the enrolled targets and known bypasses before describing the change as enterprise-wide. Keep unknown coverage visible until someone verifies it.

Use historical replay to find surprises.

Replay can compare a draft rule with the published policy against recorded activity. It helps a reviewer find which teams, agents, models or tools would receive a different decision. That is a useful rehearsal, particularly when the prose description sounds narrower than the resulting set of affected work.

Read the replay’s boundaries as carefully as its totals. The history may omit traffic, argument fields or conditions that the new rule requires. A control that cannot be replayed is not a control that affects nothing. It needs another form of validation, such as a representative controlled test, before the owner treats its behavior as understood.

ARC1’s what-if replay compares draft and published policy over recorded traffic. Its model requests, policy decisions and tool calls remain separate units. The replay is unpriced: it does not retain the token classes or read the rates needed to calculate a saving. A count of newly blocked requests should therefore remain a policy-impact measure.

Observe and warn modes can add evidence before enforcement where the control and target support them. Observe records the objection; warn communicates it while allowing work to continue. Neither demonstrates that an enforced block has occurred. Use each mode for a stated learning objective and decide what evidence permits the next step.

Approve the exact change and its recovery path.

The approval should bind to the proposal the reviewer actually examined. Record the policy version, target scope and exact planned difference. If the target or the published baseline changes during review, reassess the proposal against the new state. Approval of yesterday’s difference is weak evidence for today’s execution.

Separate the requester from the approver. The second person needs enough context to challenge the proposed behavior, the coverage claim and the recovery plan. A second signature adds little if it is attached to an ambiguous description or a proposal that can change after review.

Define recovery before rollout. If the new rule interrupts necessary work, identify the previously verified policy, the person authorized to restore it and the evidence needed to choose that action. Restoring broader access is itself a governed change; it should not silently bypass the approval boundary the rollout was intended to establish.

ARC1’s hub supports two-person approval, immutable policy versions and signed governance receipts. Its documented change-control workflow binds a request to a plan’s digest, checks the target has not moved, executes once, then reads configuration back and watches for drift. Target support and verification depth still matter: a hub workflow and a successful target integration are distinct pieces of evidence.

Verify the target, then verify the work.

Readback answers whether the target’s configuration matches the approved change. Runtime evidence answers what happened when relevant work encountered it. Keep both. A matching configuration with no covered traffic may be correctly installed but untested in operation. An allowed request may show only that the request did not meet the blocking condition.

1. 01 · IntentExact policy, scope and expected behavior
2. 02 · ApprovalIndependent decision bound to that change
3. 03 · TargetReadback against the approved configuration
4. 04 · OperationCovered work and its observed decisions

A receipt helps establish who acted and which policy was involved. It does not by itself prove that an approved configuration reached every target, that every request was observed or that the business outcome was acceptable. A gap in the chain should become a named follow-up, with an owner, rather than an implied success.

• Which route enforces this rule, and which work is outside it?
• What changed in replay, and what could not be replayed?
• Did a different person approve this exact proposal?
• Does target readback match the approved version?
• What observed work confirms the intended behavior, and what would trigger recovery?

ARC1 documents live hub governance alongside lab and planned gateway capabilities. Use those status distinctions when evaluating a rollout. A proposed operating pattern in this article does not activate a gateway, enroll a runner or establish customer coverage; those require the organization’s installation, routing and acceptance work.

The review is complete when the owner can connect the intended restriction, the approved change, the installed state and the behavior of covered work. That gives the next reviewer a decision they can inspect instead of a dashboard status they must trust.