JetBrains IDEs are where a lot of enterprise backend work happens — Java, Kotlin, Spring, big monorepos with a lot to break. So when an AI coding agent starts running shell commands inside that environment, the question isn’t whether it’s useful. It’s what happens if it touches the wrong file, the wrong network path, or a credential it shouldn’t have.

GitHub’s answer, rolled out this week, gives administrators direct control over that boundary. Enterprise-managed sandbox policies for Copilot in JetBrains are now in public preview, and they let IT teams centrally set what a sandboxed Copilot session can and can’t do: whether sandboxing runs at all, what filesystem and network paths it can reach, which proxy it routes through, whether it can touch developer tools, and — on Mac — whether it gets access to the Keychain. Once an admin locks a setting, it shows up in the JetBrains plugin marked “(managed),” and developers can’t override it locally.

This isn’t a new idea for GitHub. Local and cloud sandboxes for Copilot CLI went into public preview back in June, giving developers a way to restrict what an agent could reach on their machine (/sandbox enable) or offload heavier tasks to an ephemeral cloud Linux box instead. Enterprises could already enforce some of that through Intune or other device management platforms. What’s changed is where the control now lives. Instead of routing sandbox policy through general-purpose MDM tools, GitHub is building it directly into the Copilot plugin’s managed settings — the same mechanism it introduced in August for governing plugins, MCP server allowlists, and telemetry routing in JetBrains. Sandbox behavior joins that list as another lever administrators can pull without touching the operating system layer.

That’s a meaningful distinction for platform and security teams. MDM policy is broad and often slow to change. A setting baked into the tool itself, distributed through the same channel as everything else Copilot-related, lets a platform team adjust it in an afternoon instead of routing through a device management change request.

The release includes a few other pieces worth flagging alongside the sandbox controls. A policy diagnostics tool lets admins verify their managed settings are being detected and enforced on developer machines — useful, since a policy nobody can confirm is running is close to no policy at all. Copilot’s next-edit suggestions can now jump across files instead of stopping at the one you’re in, which matters for changes that touch multiple layers of a codebase. Chat can pull in project-wide context instead of requiring developers to attach files one at a time. And the Copilot CLI’s /ide command now connects a terminal session directly to JetBrains context, so a command-line agent session can see the same selections and diagnostics the IDE sees. OpenTelemetry settings for Copilot Chat, previously managed-only, are now available to everyone.

Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, sees the sandbox policy as part of a bigger shift in how enterprises need to think about AI coding tools.

“Once an agent can execute commands, edit across files, and reach the network on its own, the IDE isn’t just an editor anymore — it’s a runtime that needs the same access controls as any other system touching production code,” Ashley said. “Building sandbox policy into the tool itself, rather than leaving it entirely to device management, is what lets security teams actually verify what’s enforced instead of assuming it. That verification piece is the part most organizations still skip.”

That verification point lines up with what GitHub shipped alongside the sandbox controls. A diagnostics tool that confirms policy enforcement is really an admission that trust-but-don’t-verify doesn’t hold up once an agent is running shell commands on its own. Teams that have spent the last few months turning on Copilot’s agentic features — autopilot, bypass-approval modes, cloud sandboxes — now have a way to check that the boundaries they set are actually in place, not just configured.

None of this is dramatic if you’ve been watching GitHub’s Copilot governance work over the summer. Managed plugin lists in July, MCP server allowlists and telemetry routing in August, and now sandbox policy in September — it’s the same pattern applied to a new surface each time. The through-line is that agentic AI features keep shipping faster than the controls around them, and GitHub keeps circling back to close that gap one setting at a time.

For engineering and platform teams running JetBrains at scale, the practical move is straightforward: don’t treat this as a JetBrains plugin update to skim past. Pull up the policy diagnostics tool before turning on any of Copilot’s more autonomous modes, decide who owns the sandbox filesystem and network settings, and confirm those decisions are actually landing on developer machines rather than sitting in a config file nobody checked. The tools to do that now exist. Whether organizations use them before or after something goes wrong is the part still up to them.