GitHub is announcing managed sandbox policies for Copilot in JetBrains. The point is not to add an instruction for developers, but to verify which boundaries actually apply to the agent, in every environment across the estate.
What GitHub announces in JetBrains
A preview, not a guarantee for the whole estate
A sandbox is an execution environment that limits the resources accessible to a program. Here, the question concerns restrictions an organization can impose on the development assistant.
On 8 September 2026, GitHub announced managed sandbox policies in public preview for Copilot in JetBrains. The announcement describes organization-defined restrictions that take precedence over individual settings, covering in particular files, network, local tools or services, and diagnostic elements for the received policy. These facts come from the GitHub changelog, reviewed on 9 September. They prove neither universal availability nor the behavior of a particular installation.
A preview must therefore be qualified by environment: IDE edition and version, plugin, system, Copilot plan and the policy actually received. A rule declared in a console is not yet a demonstrated boundary on the workstation where the agent works.
The trap of adjacent documentation
GitHub documentation on local sandbox configuration provides context on controls, tools and approved exceptions. It is oriented toward the command-line interface (CLI). It does not demonstrate that every setting, format or command applies to JetBrains. Any configuration proposed to a team must therefore be tied to a tested client, rather than assembled from adjacent examples.
Describing the expected boundary before configuration
Files, network and tools: three separate inventories
Before a pilot, establish a needs matrix by task. An assistant fixing a test does not necessarily need the same files, hosts or tools as one analyzing a dependency. This separation avoids making broad permission the default solution.
| Environment | Plugin version | Expected policy | Harmless action | Observed result | Evidence | Owner |
|---|---|---|---|---|---|---|
| To be completed | To be completed | To be completed | Demonstration file, host or tool | Not measured | Not measured | To be assigned |
Use demonstration paths, test hosts and dummy secrets. The aim is to verify a boundary without moving customer data or modifying a real company policy.
Who may request or accept an exception?
Map separately the administrator who changes the central policy, the developer who observes a block and the approver who accepts an exception. A documented request, an approval and an authorized workaround are not synonymous. Their existence and visibility remain to be confirmed in the client and organization deploying the preview.
Verifying the effective policy
One positive and one negative test per boundary
Prepare a pair of tests for each expected authorization: a file inside and outside the permitted space, an accepted then refused demonstration endpoint, an accessible then excluded dummy local resource. For each trial, retain the expected outcome, observation, version and available evidence. An empty result means “not measured,” never “secure.”
Diagnosing instead of drawing a conclusion from an isolated failure
A refusal can reveal a policy; a network failure, disabled preview option or version incompatibility can produce the same symptom. Record the received policy, display indicators, versions and relevant log before reaching a conclusion. The diagnostic capability announced by GitHub becomes useful when it lets the team distinguish an intended restriction from a deployment defect.
Deploying without disrupting daily work
Start with a pilot group, known tasks and an owner for every exception. Before deployment, define what must stop the pilot: loss of traceability, inability to diagnose a block, or exception drift. These criteria are internal choices; GitHub does not provide a universal threshold here.
Track useful friction: legitimate requests blocked, exceptions that become persistent, and tasks that leave the arrangement. These observations do not measure an incident reduction. They make it possible to see whether the boundary meets real work and whether residual rights remain understood.
What a central policy does not replace
A central policy replaces neither code review nor least privilege, and does not make an agent output correct by construction. The framework presented in our article on zero-trust AI agents remains complementary: writes, identities and sensitive actions require their own evidence and controls.
A pilot deliverable can remain simple: an approved matrix, reproducible tests and an owner for every exception. That is what makes boundaries observable. An announced policy then becomes a defensible technical decision, without presenting it as an inviolable sandbox.