Enterprise-Governed AI Coding Lands in VS Code Copilot

Enterprise-governed AI coding arrived in VS Code on June 5, 2026, when GitHub put enterprise-managed Copilot plugins into public preview — and the quieter half of the story, an air-gapped bring-your-own-key path that no longer needs a GitHub sign-in, landed a week earlier in VS Code 1.122. Read together, they are less a feature drop than a change in who is allowed to deploy AI coding at all.

That opening describes the June release window: GitHub's June 5 preview announcement and the May 28 release notes establish the dates. A deployment decision still depends on the specific organization, client and network. None of these features establishes that a bank, hospital or government contractor can approve a particular workload.

Updated October 4, 2026: enterprise managed settings became generally available on July 1. The documented server-managed path is now .github-private/copilot/managed-settings.json. The April residency announcement authorizes the underlying model hosts and infrastructure; it describes Copilot's own FedRAMP authorization as future. This guide corrects that distinction, replaces the fixed thirteen-policy count with a scoped decision table, and adds a local-only preflight example. It does not report a customer rollout, compliance certification or measured cost saving.

An enterprise coding assistant has several independent trust boundaries. A plugin supplies instructions and tools. A managed setting distributes a baseline. An inference provider receives prompts. A sandbox constrains some command execution. Procurement evaluates the service and workload against the organization's requirements. Combining these into a single claim of "enterprise-ready" hides the decisions a reviewer needs to make.

Start with the data path rather than the model name. Write down where source code, prompts, terminal output, retrieved documents and session history can travel. Then identify who can change each route. The person who approves a plugin repository is not necessarily the person who approves the inference contract. A local endpoint does not make a remote MCP tool local, and a private registry does not make a server's returned instructions trustworthy.

The practical artifact is a workload-specific deployment record: client and extension versions, operating system, selected provider, enabled tools, configuration source and a named owner for changes. This is a recommended review method, not a statement that a particular regulator requires this exact format. The coding-agent data terms census supplies a separate lens on provider commitments; the configuration record explains what your own installation actually uses.

The June announcement located plugin marketplace settings at .github-private/.github/copilot/settings.json and described automatic application for users licensed through the enterprise with Copilot Business or Enterprise. That remains evidence of the launch, not the path to copy into a new deployment. The July 1 GA announcement describes enforcement through managed-settings.json in VS Code and Copilot CLI.

Current getting-started instructions place the file at copilot/managed-settings.json inside the designated .github-private repository. Settings apply to users receiving a license from the enterprise or its organizations even when they cannot access that repository. Restrict edit rights and review changes as code. Visibility to enterprise members can help developers understand the baseline without granting them permission to alter it.

Delivery is another boundary. GitHub documents server, MDM and file-based delivery. Server-managed settings depend on the signed-in account; device-delivered settings can apply before sign-in and remain when accounts change. In Copilot CLI, a server request failure with no cached policy leaves that server policy unavailable. A restriction that must survive loss of connectivity needs an appropriate device-delivery design and a tested failure case.

Do not assume every key has the same support in every client. The managed-settings schema carries a client-support matrix. A platform team should record the intended client for each control before approving a shared file. Reusing one logical configuration is useful; claiming identical enforcement everywhere needs evidence from each supported surface.

The original article's thirteen-policy table was a selection, not a durable census. The current VS Code policy reference lists a broader surface. The table below is a decision aid: it connects selected controls to tests and deliberately avoids a claim that one setting provides complete security. Policy names are case-sensitive configuration identifiers, not interchangeable labels for a compliance objective.

The AI-management reference distinguishes global auto-approval from tool eligibility and terminal rules. It also warns that managed MCP allow/deny values replace corresponding device-policy values rather than merging them. Review both delivered sources before concluding that a deny survives a second configuration channel. An empty allowlist, an omitted allowlist and a list containing one server should be treated as distinct test inputs.

Terminal sandboxing is not a restriction on every built-in file tool. Network behavior also differs by harness and platform; some shells use an outbound on/off boundary rather than domain filtering. Build tests around the selected surface instead of copying a screenshot from another operating system. A policy report can establish that a value arrived; an attempted forbidden operation establishes a different fact about its effect. Both belong in the acceptance record.

VS Code 1.122 made BYOK available without GitHub sign-in. The release notes say configuring a BYOK model makes Chat available and directs requests to the provider; GitHub's May-release summary corroborates the release family. A provider can be a cloud service or a local endpoint. Only the latter can support an offline design, and tools must stay within the same intended boundary.

The June 18 BYOK explanation separates chat from other Copilot features and explains the utility settings. Set chat.utilityModel and chat.utilitySmallModel through the model picker to configured local models when utility features are needed while signed out. Selecting a local chat model alone does not select those background routes. Test a title or commit-message task explicitly rather than inferring support from a successful chat answer.

The current language-model reference says local models can work without a GitHub account or Copilot plan. Semantic search, inline suggestions and embeddings-dependent features remain outside offline BYOK. The built-in Ollama provider is now deprecated in favor of the official Ollama extension. Record that integration choice; do not treat the six providers named in May as a permanent compatibility guarantee.

The earlier guide said COPILOT_OFFLINE=true was a required VS Code telemetry switch. The sources checked for this refresh do not establish that instruction, so it is withdrawn. VS Code's telemetry documentation describes telemetry.telemetryLevel and notes that extensions can have their own controls. Inventory those controls and enforce the network boundary separately. A setting label cannot establish that no bytes leave a device.

GitHub's April 13 announcement, clarified April 24 says the underlying model hosts and infrastructure are FedRAMP Moderate authorized for US government customers. It says Copilot itself will become authorized through GHEC-DR's authorization path. That wording does not support the original article's claim that Copilot obtained authorization in April. A future authorization path and a completed authorization are different procurement facts.

The same announcement describes US and EU inference residency, with the EU boundary including EU member states and EFTA countries as of May 1. It lists generally available Copilot features in scope. A buyer must still confirm the current offering, selected models and service terms with the vendor. Do not transfer the residency commitment to an independently configured BYOK provider, a plugin's third-party endpoint, or a local deployment simply because the editor is VS Code.

An evidence packet should separate the vendor statement, contract, organization configuration and workload approval. The article can establish what the dated announcement says; it cannot substitute for the buyer's approval process. Remove planned regions and promotional cost multipliers from a current decision unless their current eligibility is established. The useful question is which data types and services the selected commitment covers, including logs and tools, not whether a product page contains a familiar compliance acronym.

The April Business and Enterprise BYOK announcement says usage is billed by the chosen provider and does not count against Copilot request quotas. That establishes the billing route, not a maximum bill. A contracted endpoint, hosted gateway or self-hosted model can still incur usage, infrastructure and operational costs. Keep those budgets separate from the Copilot allowance.

Current organization billing documentation describes pooled AI credits and additional paid usage. One AI credit equals $0.01. Additional usage is enabled by default; administrators must explicitly disable the paid-usage policy to prevent spending beyond included credits. User budgets can halt access even while a pool still has capacity, and budget exhaustion does not automatically route a task to a cheaper model.

The original June–August promotional allowances are historical and are not presented here as October entitlements. Check the current plan and billing entity before estimating available capacity. Likewise, selecting a utility model is a routing choice, not evidence of savings or unchanged quality. Measure representative utility tasks, record failures and retries, and compare actual provider charges before making a cost claim. A smaller model that repeatedly retries can change both cost and developer experience.

Consider a fictional pilot that requires both utility routes to resolve to a tested loopback model. The function below checks an explicit fixture catalog and returns reasons a candidate cannot proceed. It does not read VS Code configuration, discover models, implement GitHub's policy engine or contact a provider. Its input model IDs are fixture identifiers; use the actual selector values produced by your installation when collecting a real configuration record.

The acceptance rule is intentionally narrower than "offline works." Both settings must name a catalog entry, its address must parse as HTTP(S) on a loopback hostname, and the fixture must record a successful utility-capability test. Duplicate model identifiers also fail. This catches a missing small-model route and an obvious cloud endpoint before a reviewer mistakes the chat-model choice for the whole deployment. It does not inspect the main chat route or any MCP server.

// Offline illustration: a local-only rollout requirement, not VS Code policy.
export function preflight(settings, models) {
  const failures = [];
  const catalog = new Map();
  for (const model of models) {
    if (!model.id || catalog.has(model.id)) {
      failures.push("duplicate or missing model id");
    }
    catalog.set(model.id, model);
  }
  for (const key of ["chat.utilityModel", "chat.utilitySmallModel"]) {
    const id = settings[key];
    if (typeof id !== "string" || !catalog.has(id)) {
      failures.push(`${key}: select a configured model`);
      continue;
    }
    const model = catalog.get(id);
    let endpoint;
    try {
      endpoint = new URL(model.endpoint);
    } catch {
      failures.push(`${key}: invalid endpoint`);
      continue;
    }
    const loopback = ["localhost", "127.0.0.1", "[::1]"];
    if (
      !(
        ["http:", "https:"].includes(endpoint.protocol) &&
        loopback.includes(endpoint.hostname)
      ) ||
      endpoint.username ||
      endpoint.password
    ) {
      failures.push(`${key}: endpoint is not plain loopback HTTP(S)`);
    }
    if (model.utilityTestPassed !== true) {
      failures.push(`${key}: utility capability not tested`);
    }
  }
  return { ready: failures.length === 0, failures };
}

In the isolated tests, a catalog entry named fixture-local at http://127.0.0.1:11434/v1/chat/completions, with utilityTestPassed: true, passes when both utility settings select it. Changing only the small-model selection to an absent ID fails with a targeted diagnostic. A cloud URL, malformed URL, credential-bearing URL, lookalike hostname or non-HTTP protocol fails. IPv4 and IPv6 loopback fixtures are included. No inference server was started and no real account was used.

The tests prove the displayed illustrative function's behavior on those inputs. They do not establish that a model supports the requested task, that the endpoint is safe, or that a remote service cannot be tunneled through localhost. The utilityTestPassed flag is supplied evidence, not a check performed by the function. Replace it with your own recorded fixture result in a real pilot and attach the client's effective configuration. Do not promote this small preflight into a compliance certificate.

Choose a low-risk repository and synthetic documents for the first pilot. A read-only internal documentation tool can establish retrieval behavior without introducing customer-record writes. Grant only the resources required for the task and review returned tool content as untrusted input. An initial CRM connector is not automatically the best baseline: its data sensitivity and action scope can make it a poor first fixture. Start with the smallest useful context boundary you can inspect.

Record positive and negative cases together. An approved documentation request should work; an unapproved MCP server should fail. A harmless forbidden terminal operation should remain blocked. A missing local utility model should produce a visible failure rather than an assumed fallback. Switching accounts, restarting the client and losing policy connectivity should produce the behavior your delivery design expects. Record exact versions, policy source and observable results instead of declaring success from a settings screenshot.

Prepare rollback before widening access. Retain the previous reviewed policy, identify who can publish a replacement, and confirm how the target client refreshes it. Include credential revocation and disabling the plugin or server when its behavior changes unexpectedly. Git history is useful evidence, but reverting a file alone does not prove that every running client has adopted the earlier state. Read back the effective settings and rerun the failed case after rollback.

The Cursor governance guide can frame a separate product evaluation, while the Copilot desktop-app analysis explains another client surface. Neither comparison supplies acceptance evidence for VS Code. Our AI transformation work connects workload selection with these implementation boundaries: the deliverable should be an inspectable deployment record, with a named owner and a tested rollback.