Copilot hardens security across surfaces

GitHub pushed a cluster of Copilot hardening changes across three surfaces in three days. In Visual Studio’s June update, published July 14, Copilot now checks every MCP server’s configuration and file fingerprint against a trusted baseline before it runs. A change trips a dialog that blocks the connection until a person approves it, on by default. Two days later the Copilot CLI closed a related gap: plan mode now hard-blocks any built-in tool call that would edit a file or run a mutating shell command while the agent is supposed to be planning, enforced at the runtime layer instead of trusting the model to hold the line.

Smaller changes landed in the same window. The JetBrains plugin can now point at a custom OpenAI-compatible endpoint with your own API key, across every Copilot tier. A /security-review command reached the Copilot app in public preview, scanning in-flight changes for injection flaws, cross-site scripting, and weak cryptography before you commit. And the CLI’s default limit on subagent nesting dropped from 6 to 4, alongside a mic-selection setting that now persists across voice-mode sessions.

What it means for operators

This is GitHub tightening the seams an autonomous agent can slip through: what it connects to, what it can do while “just planning,” and how far it can delegate to itself. That is the same trust problem behind enterprise-managed MCP authorization and the access question raised when Copilot’s browser tools went GA with reach into authenticated sessions. It also follows a patched Copilot data-theft flaw that showed why “just planning” is a dangerous category for an AI assistant to grade itself on. If you run Copilot as an agent, read the MCP trust prompt before clicking through, and treat the plan-mode block as the floor, not the ceiling.