GitHub Models showed why permission migrations need explicit denials
GitHub’s May 2025 models:read change affected specific token classes. Plan permission migrations around intended access, expected denial and current policy.
By 
Paul. Architecture and infrastructure
A permission migration succeeds when the intended identity can perform the intended operation and other identities remain unable to do it. Restoring a previously working request is only half that contract. GitHub’s May 2025 Models permission change illustrates why a migration needs an explicit account of token classes and expected denials before anyone broadens access to make an error disappear.
Looking back from November 2026, the 15 May 2025 changelog said that fine-grained personal access tokens and GitHub Apps required models:read. It warned that requests to the playground without that permission would return Unauthorized. It also explicitly said coarse-grained tokens were unaffected. That distinction is historical evidence, not a universal statement about tokens or current endpoints.
Start with the identity, not the error message
Imagine a proposed internal tool that accesses a model service under an application identity. This is an illustrative migration scenario, not a deployed AL+ integration. If access fails after a permission change, switching to a developer’s broader token could restore the visible operation while changing who acts and what else that credential can reach. Success at the request level could conceal a worse authorization boundary.
The first useful artifact is therefore a small identity map. Identify the caller, credential class, requested capability and owner of the configuration. A fine-grained PAT, a classic PAT and an application credential should not be treated as alternative spellings for the same authority. The migration announcement itself separated credential classes; the application’s reasoning should preserve that separation.
Record the intended denial beside the intended allowance. A job that never needs model access should not acquire it as an accidental consequence of fixing a shared configuration. An integration intended for one approved organization should not silently become an integration acting through an individual’s unrelated access. These are proposed boundaries to establish, not assertions about GitHub’s enforcement of every possible organization policy.
The permission’s name also deserves care. A capability labelled read does not by itself describe the complete data path or establish that an operation has no cost. Avoid deriving spending authority, data approval or repository access from a short permission string. Those questions need their own current documentation and organizational decisions.
A narrow one-off fix can be reasonable
The strongest counterargument is that a single internal prototype may need only one permission setting changed. A large authorization inventory could cost more than the migration warrants. That is a fair limit. The proposed map can be brief when the system has one caller and one approved operation; it should still identify the credential class and the access that must remain absent.
The opposite limit is a shared automation platform. One permission change can affect several jobs and owners. In that setting, a narrowly targeted update and a clear record of expected denials can prevent an unrelated workflow from inheriting authority. The article provides no measured incident reduction or promise that a checklist alone prevents misconfiguration.
This subject is permission evolution, not emergency credential revocation. A correctly held credential can stop meeting a newly enforced requirement without having been compromised. Treating every denial as a breach would confuse diagnosis; treating every denial as permission to broaden a token would confuse authorization.
Two announcements describe different changes
GitHub also published “GitHub Models API now available” on 15 May. Availability and authorization are separate facts. The API announcement described the interface’s availability at that time; the permission notice described a changed requirement for particular callers. Combining the headlines into a general claim that every GitHub token could now call every model would erase both scope and conditions.
The authorization notice refers to an earlier warning in March. A warning, an enforcement announcement and a consumer’s completed migration are three milestones. A team could have prepared before May, or remained affected afterward. The changelog does not identify when an individual application updated its settings, and this retrospective does not invent that date.
GitHub Models is no longer an implementation option. GitHub’s current retirement notice, consulted in November 2026, states that the service fully retired on 30 July 2026. Its playground, model catalog, inference API and bring-your-own-key feature are unavailable. The May 2025 change remains a historical case for service-independent permission migration lessons.
Review a negative authorization case before executing anything
For another service, a migration plan can name expected behavior without making a live inference request. For example, specify that the intended application identity with the documented permission should be eligible for the approved operation, while an otherwise comparable identity lacking it should be denied under the applicable policy. That is a statement of acceptance criteria, not a test result.
Keep the negative case specific. A denial caused by a misspelled endpoint says little about missing permission. A successful request through a different credential does not prove the intended identity works. The future validation needs to isolate the property under examination and retain enough context to explain the outcome without recording secrets or sensitive request content.
This article performs read-only public-source research. It makes no inference API call, uses no credential and reports no live authorization test. An owner considering implementation against an available service would need to authorize any credential handling, service operation and associated spending separately. Planning a check is useful evidence of intent; only a properly scoped execution could supply evidence of enforcement.
That distinction also improves handover. A maintainer should be able to tell which conclusions came from documentation, which are proposed policy and which have actually been observed. Otherwise a future team may interpret a migration checklist as proof that every negative case already passed, or assume a historical response label establishes today’s exact HTTP behavior.
For custom software development, retain the identity map with the integration’s operating instructions. Date the policy sources, separate historical behavior from current guidance and state what has not been tested. A useful migration restores intended work while keeping its negative authorization contract visible.