2026-10-20
Model policy belongs in your IaC, not a dropdown
What the changelog says
The entry is short. GET and PATCH endpoints are now generally available for Copilot model policies at four levels: the enterprise, enterprise teams, enterprise apps, and the organization. It lists the path for each one, and notes that enterprise policies can "delegate model control" to organizations in organization mode, or to teams and apps in enterprise teams mode. That is the whole announcement: no new models, no new restrictions, just programmatic read and write access to a setting the post frames as newly reachable from the API. You can read it at github.blog.
Nothing breaks today. What changes is that a coding-agent control can now be described in a file instead of remembered by whoever last opened the settings page.
The read half matters more than the write half
The obvious reading of an API announcement is the write half: now a pipeline can set the policy. Fine, and useful eventually. The half I would use first is GET.
Which models an agent may use is a posture decision, not a developer preference. It determines which provider receives your source, which tool behaviours are in play, and what the agent is capable of pulling into context. Treat it as a preference and it drifts quietly: a new organization gets created, somebody flips a toggle during a demo, and six months later nobody can answer the question without clicking through a list. A control whose only source of truth is a web page is a control you audit from memory, and memory is an optimistic logging backend.
Two other things follow from the delegation modes. First, choosing between holding the policy at the enterprise and pushing it down to organizations or teams is a governance decision with an owner attached. Either choice is defensible; picking one by accident and leaving it unowned is not. Second, the changelog describes endpoints, not events. My assumption is that detecting a change means polling the GET on a schedule and diffing the result, and that there is nothing to subscribe to. I would confirm that in the API documentation before promising anyone near-real-time alerting on policy changes.
One limit worth stating plainly, since it is my reasoning and not something the post claims: a model policy constrains which models are available. It says nothing about what an agent does with the repository access it already holds. This is a narrow control. Narrow controls are still worth having, as long as nobody writes them up as a boundary.
What I would do this month
In this order:
- GET the current policy at every level you operate and commit the output somewhere you already keep configuration. That file is your baseline, and producing it is the part that takes an afternoon.
- Write down which delegation mode you are in and who owns the decision at that level. One line each is enough, as long as it names a team.
- Add the GET to whatever already runs your drift checks, diff it against the committed baseline, and alert on any difference. This is where the value is; steps one and two exist to make it possible.
- Only after the drift check is running, start setting policy with PATCH from a pipeline. Automating a write you cannot yet observe is how you end up debugging a policy that three systems believe they own.
None of this is urgent in the way the eight items with reported exploitation on this week's page are urgent. It is the sort of plumbing that is cheap while nobody is asking, and the output is a file you can diff.