A security policy that never reaches the coding agent is not a control. GitHub now lets Copilot fail closed

An administrator tightens the rules for Copilot’s coding agent on Monday morning: sandbox on, a risky setting off. On Monday afternoon, a developer opens a laptop that has been offline over the weekend. Which policy does the agent run under?

Until now, often the old one. Copilot clients cache managed settings, which makes startup fast and keeps developers working through a brief service outage. It also means a policy change reaches each machine only when that machine next refreshes. For autocomplete, the gap hardly mattered. For an agent that runs commands, edits files and calls tools, it is the gap between the policy an administrator believes is in force and the one actually enforced.

What GitHub shipped

On October 13, GitHub added two enforcement controls for enterprise-managed Copilot settings.

Forced refresh at startup. Setting forceRemoteSettingsRefresh to true, through server-managed, MDM-managed or file-based settings, requires supported clients to fetch current server-managed settings when they start instead of trusting the cache. “If the client cannot confirm current policy, it fails closed rather than running with a stale or unconfirmed policy.” Supported clients are Copilot CLI, VS Code and the GitHub Copilot app. One prerequisite: for server-managed values, the forced refresh applies on later startups only after the client has received the setting once. MDM and file-based delivery can require a fresh fetch before first sign-in.

Minimum client version for the sandbox. When the sandbox key is present in managed settings, users on older pinned client versions “will now be forced to update in order to resume using Copilot.” The sandbox itself is a generally available local capability; GitHub says minimum version requirements will extend to other governance keys over time. For now, it is the sandbox key only.

Fail closed is a decision, not a default

Failing closed is the right behavior for a security control. It is also a choice with a cost: if the client cannot reach the policy service, because of a network problem, a proxy that blocks the call or an outage, the developer cannot use Copilot until it can. GitHub keeps the cached behavior as the default for that reason.

The decision should be made per population, not per company:

• Fail closed where the agent can reach sensitive code, production credentials or regulated data, and where an unconfirmed policy is worse than an hour without an assistant.
• Keep the cache where developers work offline often and the agent’s permitted actions are already narrow.
• Plan the bootstrap. Because the first delivery of server-managed settings has to succeed before enforcement starts, a new machine is briefly governed by whatever it had before. MDM or file-based delivery closes that window.

The general lesson for agent governance

Controls for coding agents increasingly live in the client: which models are allowed, whether a sandbox is on, which MCP servers may start. We noted in a recent update that a default model in Copilot is not a policy. This update addresses the next question: whether the policy that is a policy actually arrived.

Any control enforced on an endpoint has three failure modes: the policy is wrong, the policy is stale, or the client is too old to understand it. Central consoles show the first. This release lets enterprises close the second and begins to close the third. The same questions apply to every agent that runs on developer machines, from any vendor:

1. How long can a client run on a cached policy?
2. What does it do when it cannot confirm the current one?
3. Can an old client ignore a setting it does not recognize?

If the answers are “indefinitely,” “keeps running” and “yes,” the policies in the console describe intentions, not enforcement. The containment argument we made in agent boundaries outside the model only holds if the boundary’s configuration reaches the machine it is meant to protect.