Copilot for JetBrains: fence your coding agent

GitHub shipped enterprise-managed sandbox policies for Copilot in JetBrains IDEs on September 8, in public preview. Admins now decide what a coding agent on a developer's laptop can read, reach, and unlock — not the developer. If you run a small team and your only sandbox policy is "we trust Kevin," this is the control you have been improvising.

What actually happened

The managed settings cover sandbox enablement, filesystem and network access, proxy settings, developer-tool access, and macOS Keychain access. Managed restrictions take precedence over user settings: Copilot locks the affected controls in the UI and marks them as organization-managed, so a developer cannot quietly widen the blast radius mid-sprint. The settings only surface once your org turns on the Editor Preview flag or configures a managed setting.

The same release adds cross-file jumps in next edit suggestions, global files and folders as chat context, and an /ide command that wires a terminal Copilot CLI session into JetBrains context — selections, diagnostics, file references — also in public preview.

Same day, GitHub Enterprise Server 3.22 went GA with a technical preview that lets admins point Copilot CLI at GHES for disconnected and air-gapped environments. Enterprise teams also reached general availability there.

Why the sandbox matters for your business

Keychain access is the line item to read twice. A coding agent with filesystem reach and Keychain reach is an agent that can find your Stripe key, your database URL, and the .env file you swore you deleted — and then paste any of it into a request. The agent does not need to be malicious. It needs one poisoned README, one dependency with instructions in a docstring, one prompt injection in an issue it was asked to fix.

Three things to set this week, whether or not you use Copilot:

Deny network by default. An agent that can write code but not call out cannot exfiltrate. Allowlist the registries it actually needs.

Keep credentials out of the filesystem the agent sees. Secrets belong in a manager the agent has to ask for, with a human on the approve button. Not in .env next to the code.

Make the policy central, not per-laptop. A setting each developer can toggle is not a policy. It is a suggestion with good intentions.

The reason GitHub built this is the reason you need it: the agent runs on the developer's machine, with the developer's access, and the developer is busy.

Sources: GitHub Changelog, GitHub Changelog: GHES 3.22.