Three Copilot entries landed in GitHub's changelog on 27 July, and all three are aimed at administrators rather than developers.
Individually they are housekeeping. Together they mark the point where Copilot stops being a plugin somebody installs and starts being infrastructure somebody governs.
What shipped
The three entries were:
- A dedicated policy for managing access to the Copilot app, separate from other Copilot permissions
- Enterprise managed settings covering both the Copilot app and the Copilot cloud agent
- Improved OpenTelemetry configuration and model management for Copilot in JetBrains
Why the admin layer keeps growing
Copilot now spans VS Code, Visual Studio, JetBrains, Xcode, Eclipse, a CLI, a cloud agent, github.com, a standalone app and mobile. Every surface is another place a model can be selected and another place a policy has to be enforced.
The OpenTelemetry work is the quiet tell. Telemetry configuration is what you build when customers need to prove to their own auditors what the assistant did.
What to do about it
If you administer a Business or Enterprise plan, this is the week to open Copilot settings and look at it properly, because the model-policy switches introduced here are the same ones that decide whether your developers can see models added later in the week.
- Check which models are enabled, not just which are available
- Decide whether the Copilot app needs separate access from the IDE extensions
- If you report to auditors, look at the telemetry options before you are asked for them