GitHub's Copilot default policy is enforcing itself through October 26: what to check before it chooses for you
On October 22 GitHub started enforcing the global default policy for generally available Copilot features. The rollout runs through October 26 and lands at different times for different enterprises and organizations. Anything eligible that your org never explicitly configured gets set to whatever t
Am 22. Oktober begann GitHub, die globale Standardrichtlinie für allgemein verfügbare Copilot-Features durchzusetzen. Der Rollout läuft bis zum 26. Oktober und erreicht verschiedene Enterprises und Organizations zu unterschiedlichen Zeitpunkten. Alles, was berechtigt ist und von eurer Organisation nie explizit konfiguriert wurde, wird auf den Wert gesetzt, den die Standardrichtlinie vorgibt. Für viele Teams bedeutet das, dass sich Features ein- oder ausschalten, ohne dass jemand irgendwo klickt.
Genau diese Art von Veränderung wird drei Wochen später zu einem mysteriösen Incident: Ein Agent erreicht plötzlich ein Tool, das er am Montag noch nicht erreichen konnte, und niemand erinnert sich, das je autorisiert zu haben. Deshalb habe ich die Changelog-Einträge zu beiden Stichtagen gelesen, und dies ist die Kurzfassung für alle, die Copilot für ein Team betreiben.
GitHub kündigte die globale Standardrichtlinie im September an; sie umfasst allgemein verfügbare Copilot-Features und unterstützte Client-Fähigkeiten in den Plänen Copilot Business und Enterprise. Neu ist die Durchsetzung. Aus dem Changelog-Eintrag vom 22. Oktober:
Ab heute rollen wir die Durchsetzung der Richtlinie schrittweise bis zum 26. Oktober aus, sodass sie zu unterschiedlichen Zeitpunkten für unterschiedliche Enterprises und Organizations wirksam werden kann. Nicht konfigurierte, berechtigte Features werden entsprechend der globalen Richtlinie gesetzt.
Es gibt drei Standardpositionen: Enabled, Disabled und Let organizations decide. Was auch immer bei euch eingestellt ist, dieser Wert wird beim Rollout auf die nicht konfigurierten Einträge geschrieben. Bei Let organizations decide greift für die nicht konfigurierten Features jeweils der eigene Standard der Organisation.
Die Richtlinie gilt für berechtigte Einstellungen auf zwei Ebenen:
Die zweite Ebene ist der Grund, warum dies mehr ist als eine gewöhnliche Admin-Checkbox-Geschichte. Die MCP-Server-Ebene ist die Tool-Ebene, die eure Copilot-Agents erreichen können. Wird dort eine Fähigkeit als allgemein verfügbar und berechtigt ausgeliefert und eure Organisation hat sich nie dazu geäußert, trifft die Standardrichtlinie die Entscheidung stattdessen. Kein PR, kein Diff, nichts, was euer Repository mitbekommt.
Das Design ist enger gefasst, als die Schlagzeile vermuten lässt, was gut ist:
Der Rollout erfasst also nur Entscheidungen, die niemand getroffen hat. Der Haken daran: Nichts entschieden zu haben ist genau die Grundeinstellung gegenüber jedem Feature, das ausgeliefert wurde, während das Team den Changelog nicht gelesen hat.
Enterprise- und Organization-Owner: AI Controls → Copilot → Default policy for new features. Diese Seite zeigt die aktuelle Standardposition. Der Screenshot des Eintrags zeigt die Seite Features and clients mit der auf Enabled gesetzten Standardrichtlinie und dem bereits eingeblendeten Banner vom 22. Oktober.
Öffnet dann Features & clients und arbeitet die Liste durch. Jede Zeile, die noch als Unconfigured markiert ist, wird von diesem Rollout gesetzt. Stehen eure Zeilen heute noch auf Unconfigured, hat der Wechsel eure Organisation schlicht noch nicht erreicht; das Zeitfenster läuft bis zum 26. Oktober.
1. AI Controls → Copilot → Default policy for new features, den Standard lesen: Enabled / Disabled / Let organizations decide 2. Features & clients: alle Zeilen auflisten, die als Unconfigured markiert sind 3. MCP servers in Copilot: genauso alle Unconfigured-Zeilen auflisten 4. Für jede Zeile, die wichtig ist, vor dem 26. Oktober eine explizite Einstellung vornehmen, denn explizite Entscheidungen überstehen spätere Änderungen der Standardrichtlinie 5. Eine Kopie des Endzustands außerhalb der Admin-UI speichern Enter fullscreen mode Exit fullscreen mode Schritt 5 ist der, den alle auslassen. Die Admin-UI ist eine Konfigurationsdatei, die man nicht diffen kann.
Wenn ihr das Verhalten eurer Agents in Konfigurationsdateien festlegt, und das solltet ihr, ist die feature-seitige Plattformrichtlinie ab jetzt Teil dieser Konfiguration. Sie lebt eben in einer Admin-UI statt in einem Repository. Die Tool-Verfügbarkeit für eure Agents kann sich nun nach einem Zeitplan ändern, den ihr nicht festgelegt habt, was ganz gewöhnliches Config Drift mit Hersteller-Signatur ist. Ich habe geschrieben, wie man diese Art von Drift in den eigenen Dateien abfängt, bevor sie zuschlägt: Your AGENTS.md is lying: how configs drift and how to catch it.
Die praktische Regel: Alles, was ändert, welche Tools eure Agents aufrufen können, gehört in euer Config Review, egal wo die Einstellung physisch liegt.
Dieselbe Standard-Maschinerie hat eine zweite laufende Frist. Am 16. November 2026 werden drei Modelle aus jeder Copilot-Erfahrung entfernt (Chat, Inline-Edits, Ask- und Agent-Modi, Completions), laut Deprecation-Hinweis:
Claude Opus 4.8 bleibt für individuelle Copilot-Abonnenten mit Jahresplänen verfügbar. Unter der Standard-Model Enablement werden die Alternativen für Business und Enterprise automatisch aktiviert, es sei denn, ein Administrator hat den globalen Standard deaktiviert oder das Modell ausgeschaltet. Falls ihr den Standard abgeschaltet habt, aktiviert ihr die Ersatz-Modelle über Model Policies in den Copilot-Einstellungen. Bis dahin brechen Workflows, die an ein auslaufendes Modell gebunden sind, zu einem Zeitpunkt, den niemand geplant hat.
Wenn euer Team Prompts auf einem der auslaufenden Modelle standardisiert hat, ist das eine Config-Migration mit Deadline. Welche Ebene entscheidet, was eure Agents tatsächlich ausführt, ist eine Frage, der ich beim GA-Status von Haiku 5.5 im Detail nachgegangen bin: Claude Haiku 5.5 is GA in GitHub Copilot: 4 config surfaces decide what runs your subagents.
Nichts davon ist feindselig gemeint. Standardrichtlinien sind eine vernünftige Antwort auf Feature-Überfluss, und explizite Entscheidungen zu erhalten ist das richtige Verhalten. Der kleinere Punkt, den man verinnerlichen sollte: Ein Standard, der auf eine nicht konfigurierte Einstellung angewendet wird, ist trotzdem eine Entscheidung über eure Agents, die nirgendwo in eurem Repository dokumentiert wird.
Behandelt die Admin-UI-Richtlinie wie jede andere Konfiguration. Lest sie vor der Deadline, notiert euch, was sie sagt, und prüft sie erneut, wenn sich der Changelog bewegt. Das Zeitfenster bis zum 26. Oktober ist ein guter Anlass, damit anzufangen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
On October 22 GitHub started enforcing the global default policy for generally available Copilot features. The rollout runs through October 26 and lands at different times for different enterprises and organizations. Anything eligible that your org never explicitly configured gets set to whatever that default says. For a lot of teams this means features switching on, or off, with nobody clicking anything.
This is the kind of change that turns into a mystery incident three weeks later: an agent suddenly reaches a tool it could not reach on Monday, and nobody remembers authorizing it. So I read the changelog entries on both deadlines, and this is the short version for anyone running Copilot for a team.
GitHub announced the global default policy in September, covering generally available Copilot features and supported client capabilities on Copilot Business and Enterprise plans. Enforcement is the new part. From the October 22 changelog entry:
Starting today, we're gradually rolling out enforcement of the policy through October 26, so it may take effect at different times for different enterprises and organizations. Eligible features left unconfigured will be set according to the global policy.
Three default positions exist: Enabled, Disabled, and Let organizations decide. Whatever yours says is the value the rollout writes onto unconfigured rows. With Let organizations decide, each organization's own default takes over for its unconfigured features.
The policy applies to eligible settings on two surfaces:
The second one is why this matters more than a normal admin-checkbox story. The MCP server surface is the tool surface your Copilot agents can reach. If a capability there ships as generally available and eligible, and your org never made a choice about it, the default policy makes the choice instead. No PR, no diff, nothing your repository sees.
The design is narrower than the headline suggests, which is good:
So the rollout only takes choices nobody made. The catch is that "nobody made a choice" is the default posture toward every feature that shipped while the team was not reading the changelog.
Enterprise and organization owners: AI Controls → Copilot → Default policy for new features. That page shows the current default position. The entry's own screenshot shows the Features and clients page with the default policy set to Enabled and the October 22 banner already up.
Then open Features & clients and read down the list. Every row still marked Unconfigured is a row this rollout will set. If your rows still say Unconfigured today, the flip may simply not have reached your org yet; the window runs through October 26.
1. AI Controls → Copilot → Default policy for new features read the default: Enabled / Disabled / Let organizations decide 2. Features & clients list every row marked Unconfigured 3. MCP servers in Copilot same: list every Unconfigured row 4. For each row you care about, set it explicitly before October 26 explicit choices survive later default-policy changes 5. Save a copy of the final state somewhere outside the admin UI Enter fullscreen mode Exit fullscreen mode Step 5 is the one people skip. The admin UI is a config file you cannot diff.
If you pin agent behavior in config files, and you should, platform-side feature policy just became part of that config. It simply lives in an admin UI instead of a repository. Tool availability for your agents can now change on a schedule you did not pick, which is ordinary config drift with a vendor signature. I wrote about catching that class of drift in your own files before it bites: Your AGENTS.md is lying: how configs drift and how to catch it.
The practical rule: anything that changes what tools your agents can call belongs in your config review, wherever the setting physically lives.
The same defaults machinery has a second deadline running. On November 16, 2026, three models leave every Copilot experience (chat, inline edits, ask and agent modes, completions), per the deprecation notice:
Claude Opus 4.8 stays available for individual Copilot subscribers on annual plans. Under default model enablement, the alternatives are automatically enabled for Business and Enterprise unless an administrator turned off the global default or disabled the model. If you did turn the default off, you enable the replacements through model policies in Copilot settings. Until you do, workflows pinned to an outgoing model break on a date you did not schedule.
If your team standardized prompts on one of the outgoing models, that is a config migration with a deadline. Which surface decides what actually runs your agents is a question I walked in detail when Haiku 5.5 went GA: Claude Haiku 5.5 is GA in GitHub Copilot: 4 config surfaces decide what runs your subagents.
Nothing here is hostile. Default policies are a reasonable answer to feature sprawl, and preserving explicit choices is the right behavior. The part to internalize is smaller: a default applied to an unconfigured setting is still a decision about your agents, recorded nowhere in your repository.
Treat admin-UI policy like any other config. Read it before the deadline, write down what it says, and review it when the changelog moves. The October 26 window is a good excuse to start.