Fresh agent policies: when to fail closed

An agent should fail closed when an action depends on current policy and the client cannot prove that it received, understood, and applied the authorized version. A central file is not enough: the effective decision happens across a specific user, device, client, version, workspace, and tool. If that combination keeps a stale copy, it may execute with permissions an administrator has already revoked. GitHub formalized this problem on October 13, 2026 by allowing Copilot CLI, VS Code, and the Copilot app to require a fresh managed-settings download at startup. With the requirement active, a cached response does not confirm posture; if the download fails, affected operations are restricted or features are blocked. That behavior fits urgent changes—disabling computer use, closing a domain, or hardening the sandbox—but it adds a network dependency and availability risk. The sound decision is not to fail closed everywhere. It is to declare which controls cannot tolerate stale policy and test how work recovers without opening a bypass.

The central news was two Lima calendar days old when consulted on October 15. GitHub also announced that the sandbox key can require a minimum client version, preventing an old binary from continuing when it lacks the required enforcement semantics. These are provider contract claims, not an independent measurement of availability, latency, or resistance to a tampered client. The value for other agent systems lies in the mechanism: policy governs only when it can prove authority, version, freshness, precedence, and failure behavior.

The flow has four states even when interfaces show only “configured.” First, an authority publishes policy with identity and review—for example, a commit in a managed private repository, an MDM payload, or a system file. Second, the client retrieves and validates it. Third, it combines sources according to precedence rules. Fourth, the runtime translates the result into decisions about commands, paths, domains, MCP, plugins, computer use, or sandboxing. Evidence must accompany every transition; otherwise, the dashboard proves administrative intent rather than enforcement.

Freshness answers a different question from validity. A copy may contain valid JSON and come from a legitimate authority yet represent a revoked decision. A contract therefore needs a version identifier, issue time, receipt time, maximum tolerated age, and confirmation state. GitHub documents that its fresh download bypasses the normal one-hour cache in CLI and the app; in VS Code, features remain blocked until the required refresh succeeds. A custom implementation can use an ETag, hash, or monotonic revision, but it should not rely only on the local clock, which can drift or be altered.

Precedence prevents a less trusted source from weakening another. GitHub's documentation orders MDM, server, file, and user preferences, while composing sandbox and permission controls in the more restrictive direction. Granular permissions use deny before ask and ask before allow; when several sources declare allowlists, effective authorization behaves like an intersection. The general pattern matters: combining security policy as a union of permissions creates accidental escalation. Every key must declare whether it replaces, intersects, inherits, or selects the most restrictive value.

Treat policy as a distributed protocol rather than an administration screen. The following five gates separate existence from freshness and turn a control promise into a verifiable outcome.

Imagine a SaaS company whose support agent can read tickets, inspect logs, and run read-only diagnostic queries. An investigation finds that one connector includes personal identifiers in its results. Security immediately removes the connector domain from the allowlist and adds a deny rule. The central change is approved at 10:00, but twenty laptops retain a copy downloaded at 9:35. If the cache remains valid for an hour, administrative revocation and actual capability diverge for 35 minutes.

In the hypothetical pilot, capabilities are classified by tolerance. Browsing public documentation may accept cached policy during a short outage. Querying internal data requires a revision no more than fifteen minutes old. Production access requires fresh confirmation when the session starts and again before obtaining ephemeral credentials. The runtime attaches policy revision, client version, and effective decision to every tool call without copying ticket or result content. When the authority is unavailable, public reading continues while production tools appear blocked with a verifiable reason.

Recovery does not mean asking the user to disable controls. The interface offers retry, shows the last confirmed revision, and links to service status. A separate break-glass procedure has a short lifetime, two-person approval, single-task scope, and retrospective review. When authority recovers, the client must download again before leaving restricted mode. This example is not a Wasyra customer or benchmark; it illustrates how to make freshness a capability-level property instead of a global switch.

Start by inventorying enforcement points. For every client, record version, policy source, supported keys, offline behavior, and operational owner. Separate preference controls—such as default model or appearance—from risk controls—computer use, permissions, domains, sandbox, MCP, and credentials. Only the second group needs a strong guarantee. If a provider requires a minimum version for a key, treat that requirement as part of rollout: measure coverage first, then block old versions, and only then activate freshness enforcement.

Roll out by cohort. A small canary receives the new policy and runs negative tests: forbidden domain, denied command, path outside the sandbox, unapproved MCP server, and failed remote download. Observe bypasses as well as false blocks. Expand next to a team with support available, then to everyone else. Keep a kill switch at the authority, but do not let the same channel that publishes policy silently disable verification; emergency control needs its own identity and record.

Design the failure experience. Users should distinguish “the tool is down” from “policy could not be confirmed” and know which local work remains available. Avoid retry loops that overload the authority; use backoff, explicit state, and content-free metrics for refresh rate, age, errors by client, and recovery time. Fresh policy that nobody can diagnose creates pressure for informal bypasses; a bounded explanation reduces that pressure without exposing complete sensitive rules.

Evaluate security and availability separately. For security, attempt operation with an old revision, a permissive lower-priority source, malformed file, unsupported client, and altered local clock. Acceptance requires that a protected capability does not execute and that the event records expected revision, observed revision, client, and reason without capturing secrets. For availability, measure how much safe work remains, how long recovery takes, and how many users attempt bypass. A system can block correctly yet remain impractical if an authority outage stops tasks that never needed that control.

Include transition tests rather than only steady states. Change allow to deny during an active session; rotate authority; raise the minimum version; restore the network after several failures; and expire a break-glass exception. Verify that new and existing sessions adopt the declared semantics, recovery does not reuse invalid cache, and a lower-priority source cannot reopen capability. If clients react differently, document that difference as part of the product rather than as an implementation footnote.

The meaningful change is not another configuration file. It is recognizing that cache belongs to the security boundary. The five gates—authority, freshness, precedence, capability, and failure—follow policy all the way to the runtime that decides. Fail closed only for capabilities whose risk exceeds the cost of unavailability, preserve safe work where possible, and rehearse recovery before a real revocation.

If you need to design a pilot with tools, permissions, sandboxing, traces, and release gates, Wasyra's custom agent service can turn these rules into operational tests. It is an implementation service on wasyra.com, separate from the Agents product available at agents.wasyra.com. The result that matters is not a managed console; it is being able to prove which policy governed each action.