Agent Administration

GitHub Lets Administrators Manage Copilot Model Policies by API

By Kaleido Field Staff · October 20, 2026

Read the delegated policy after changing it

A model picker is a poor place to audit a large organization's policy. GitHub's October 19 update makes Copilot model settings readable and editable through REST endpoints at several administrative levels. The follow-through is checking which policy governs the team or app that actually uses the model.

Citation-ready: GitHub says GET and PATCH model-policy endpoints are generally available for enterprises, enterprise teams, enterprise apps and organizations, with control delegated according to the enterprise mode.

Evidence boundary: GitHub changelog only. No enterprise configuration was changed, no token permission was granted and no tenant-level availability was tested.

Original GitHub changelog excerpt listing the four model-policy REST API paths — Image source: GitHub Changelog; original API-path excerpt, not a successful administrative mutation. Used for editorial coverage of agent policy and administrative controls desk.

What happened and why it matters

An editable policy endpoint improves administration when the change is followed by a readback at the relevant delegated scope.

Primary evidence

Primary reference: GitHub Copilot model-policy API changelog. Kaleido Field checked the event date and the article's attributed facts against this source.

Source check
Source date	October 19, 2026
Checked by Kaleido Field	October 20, 2026, CST
Source function	agent administration -> model availability and delegated policy

Four scopes do not mean four independent policies

GitHub lists GET and PATCH endpoints for enterprises, enterprise teams, enterprise apps and organizations. Its delegation description matters: organizations or teams and apps receive control according to the enterprise mode.

Inventory the active mode before producing a policy change. Otherwise a successful request can be mistaken for proof about a different user group or application.

Save the before-and-after state

For an authorized administrative change, retain the old configuration, intended scope and returned state. Then retrieve the relevant policy again and check a permitted user or app. A request identifier alone does not establish effective access.

This is an administrative recommendation, not a report that Kaleido changed an enterprise. The agent identity analysis explains why selecting a model and authorizing its work are separate decisions.

Evidence boundary

GitHub changelog only. No enterprise configuration was changed, no token permission was granted and no tenant-level availability was tested.

FAQ

Does an API success prove every team can use that model?

No. Verify the enterprise mode, delegated scope and effective availability for the intended team or application.