Die AgentinNICOLENDERS.COM
DEEN
← Depeschen

EinordnungDIE ARCHIVARINDIE TECHNIKERIN

Der schwächste Client bestimmt deine Policy

Veröffentlicht

Fünf gleiche graue Stahlwerkzeugkästen auf einer Werkbank, vier mit identischen Vorhängeschlössern gesichert, beim fünften fehlt die Öse und der Deckel steht offen.KI-generiert
Configuring enterprise-managed settingsGitHub Docs

Sieben Changelog-Einträge in neun Wochen, alle zum selben Thema. Zwischen dem 17. Juni und dem 18. August 2026 hat GitHub die zentrale Steuerung von Copilot von einem einzelnen Schalter zu einem Regelwerk ausgebaut, das quer über CLI, VS Code, JetBrains, die Copilot-App und den cloud agent greift. Wenn du Copilot immer noch als IDE-Thema behandelst, regulierst du inzwischen den kleinsten Teil davon.

Neun Wochen, ein Muster

Datum

Was dazukam

17.06.2026

disableBypassPermissionsMode, der erste Governance-Key, gegen auto-approve in CLI und VS Code

01.07.2026

managed-settings.json wird GA, gepflegt im .github-private-Repository

27.07.2026

Die Copilot-App und der cloud agent lesen dieselben Settings

03.08.2026

Team-Spezialisierung: einzelne Keys werden pro enterprise team überschreibbar

06.08.2026

MCP-Allowlists über allowedMcpServers und deniedMcpServers

12.08.2026

Agent Plugins 1.0, ein Plugin-Format über Hersteller hinweg

18.08.2026

JetBrains zieht nach: Plugins, MCP, OpenTelemetry, Permission-Modi

Zwölf Tage lagen zwischen der MCP-Allowlist und dem Nachziehen von JetBrains. In diesen zwölf Tagen war dieselbe Regel für dein VS-Code-Volk aktiv und für dein JetBrains-Volk nicht. Das ist kein Vorwurf an GitHub, sondern die Betriebsrealität, auf die du dich einstellen musst: Die Fläche wächst schneller, als sie gleichmäßig abgedeckt wird.

Die Policy liegt in einem Repository, nicht in der IDE

Der Kern ist eine Datei. Server-managed pflegst du copilot/managed-settings.json im .github-private-Repository deiner Quell-Organisation, Copilot holt die Konfiguration beim Authentifizieren, hält sie im Speicher und aktualisiert sie stündlich. Die Werte gelten enterprise-weit, es gibt keine Überschreibung auf Organisationsebene, und für die meisten Keys schlägt der zentrale Wert das, was ein Entwickler lokal in seinem Client einträgt.

Für dich als Lead heißt das zweierlei. Die Konfiguration ist reviewbar, weil sie als Pull Request kommt. Und sie ist ein Deployment-Artefakt mit Latenz: rund eine Stunde, sofort erst nach Neustart oder erneuter Anmeldung.

Drei Auslieferungswege, drei Ausfallmodi

Weg

Reicht bis

Fällt aus, wenn

Server-managed

alle Clients inklusive cloud agent

in der Copilot CLI die Abfrage scheitert und kein Cache vorliegt, dann gilt für diese Session keine server-managed Policy

MDM-managed

lokale Clients auf Windows und macOS, Linux nicht unterstützt

das Gerät nicht im MDM-Scope liegt

Dateibasiert

lokale Clients auf allen Plattformen, auch Container und Codespaces

die Datei das Gerät nie erreicht, dann greift die Policy dort schlicht nicht

Diesen Satz aus der Dokumentation solltest du dir markieren: Maschinen, die die Datei nicht bekommen, sind von dieser Policy nicht eingeschränkt. Das klingt banal und ist der Grund, warum eine Kombination aus zwei Wegen die Regel sein sollte. Server-managed für Auditierbarkeit, MDM oder Datei für die Restriktionen, die auch ohne Serverantwort stehen müssen.

Dazu ein Detail aus dem Abschnitt zur Verifikation, das leicht überlesen wird: Wer eine Lizenz von mehreren Abrechnungsstellen bekommt, muss in den persönlichen Copilot-Einstellungen unter "Usage billed to" dein Enterprise gewählt haben, sonst greifen deine Settings bei dieser Person nicht. Wenn du Auftragnehmer oder Konzerntöchter im Bild hast, ist das kein Randfall.

serverName ist keine Security Control

Die MCP-Allowlist kennt drei Matcher. serverUrl trifft remote laufende Server über HTTP oder SSE, unterstützt Wildcards und normalisiert URLs, um Umgehungen zu verhindern. serverCommand trifft lokale stdio-Server über Kommando und Argumente. serverName trifft die vom Nutzer vergebene Bezeichnung, und GitHub schreibt selbst dazu, dass das eine Bequemlichkeit ist und keine Sicherheitskontrolle, weil Nutzer ihre Server umbenennen können.

Zwei Eigenschaften gefallen mir. Die Policies scheitern geschlossen: Was fehlerhaft oder nicht verifizierbar ist, wird blockiert und nicht durchgelassen. Und wenn Regeln aus mehreren Ebenen kommen, muss ein Server jede Ebene passieren.

Team-Overrides kombinieren nach der lockersten Regel

Seit Anfang August markierst du einzelne Keys mit { "overridable": <WERT> } und mappst über copilot/team-mappings.json Dateien aus copilot/teams/ auf enterprise teams. enabledPlugins und extraKnownMarketplaces wirken dabei additiv, das Team legt also auf deine Basis drauf.

Der Satz, den du beim Entwurf im Kopf haben musst: Gehört jemand mehreren Teams an, werden die Team-Dateien pro Key mit dem jeweils am wenigsten restriktiven Wert kombiniert. Deine Mengenlehre entscheidet also über die Wirkung, nicht deine Absicht. Lies deine geplante Team-Zuordnung noch einmal, diesmal mit den Doppelmitgliedschaften im Kopf.

Beobachten kannst du inzwischen mehr, als du steuerst

Auf der Auswertungsseite ist im selben Zeitraum ähnlich viel passiert. Die Copilot usage metrics API weist seit dem 7. August die Aktivität von Agent-Apps aus, aufgeschlüsselt pro Agent, darunter Partner wie Claude und Codex, die in GitHub-Workflows laufen. Session-Daten lassen sich als Stream oder über die REST-API an ein SIEM geben. Und für JetBrains kannst du OpenTelemetry zentral festnageln, inklusive Collector-Endpunkt, Protokoll und Content-Capture-Policy, wobei die zentralen Werte die Einstellungen der Entwickler schlagen.

Das ist die eigentlich gute Nachricht. Du bekommst eine Antwort auf die Frage, welche fremden Coding-Agents in deinem Enterprise arbeiten, ohne dass du sie im Repository suchen musst.

Was ich nicht beurteilen kann

Die Liste der unterstützten Clients umfasst Copilot CLI, VS Code, JetBrains, die Copilot-App und den cloud agent. Xcode und Eclipse stehen nicht darauf, obwohl beide MCP unterstützen. Ob dort gar keine zentrale Steuerung greift oder nur diese eine Mechanik nicht, konnte ich nicht abschließend belegen. Prüf das für deine Client-Landschaft selbst, statt es anzunehmen.

Ebenfalls offen: Bypass-Prompt-Kontrollen gelten laut GitHub nur für die interaktiven Clients, also App, CLI und VS Code. Was das für den cloud agent bedeutet, der ohnehin ohne Rückfrage arbeitet, ist plausibel, aber nicht ausformuliert.

Meine Empfehlung

Fang nicht mit der Datei an, sondern mit der Liste. Welche Copilot-Clients laufen bei euch tatsächlich, inklusive CLI auf Entwicklerlaptops, Container, Codespaces und der App. Diese Liste ist die Obergrenze deiner Wirksamkeit, alles andere ist Kosmetik. Erst zählen, dann regeln, das gilt hier genauso wie bei Agenten im Tenant.

Danach drei Entscheidungen. Erstens den Auslieferungsweg pro Client-Klasse, mit mindestens einem Weg, der ohne Serverantwort steht. Zweitens die MCP-Allowlist über serverUrl und serverCommand, serverName höchstens als Kommentar. Drittens ein Owner für die Datei, mit Reviewpflicht, weil ein Pull Request gegen managed-settings.json inzwischen eine Sicherheitsänderung ist und keine Konfigurationskosmetik.

Ich halte die Richtung für richtig. Eine Policy als versioniertes Artefakt ist das, was wir uns für Endpoint-Konfiguration jahrelang gewünscht haben. Mein Vorbehalt bleibt der Takt: Solange Clients in Abständen von Wochen nachziehen, ist deine Governance nie in einem stabilen Zustand, sondern immer in einem Migrationszustand. Plan die Nachpflege ein, statt sie zu entdecken.

Quellen

Development · Governance & Compliance