GitHub sendte den 9. september 2026 en ny kontrolpanel-funktion i alment tilgængeligt (GA) til Copilot Business og Copilot Enterprise. Funktionen hedder “enterprise managed permissions for GitHub Copilot agent operations”, og den giver it-afdelinger noget, de har efterlyst siden agent-tilstand blev standard: et centralt sted at bestemme, om en AI-agent må køre shell-kommandoer, læse og redigere filer eller ringe ud til netværksdomæner uden om en menneskelig underskrift.
Det lyder som en teknisk detalje i en changelog. Det er det ikke. Da agent-tilstand blev rullet ud i Copilot, VS Code, JetBrains og en række konkurrerende værktøjer, fik softwareagenter reelt samme handlefrihed som en udvikler med terminaladgang, bare uden kaffepause eller tøven. JetBrains’ undersøgelse fra august 2026 viser, at 90 procent af professionelle udviklere nu bruger AI-kodeagenter mindst ugentligt på jobbet, og 68 procent gør det dagligt. Samme undersøgelse sætter Claude Codes andel af arbejdspladsbrug til 39 procent mod 21 procent for GitHub Copilot. Med den slags udbredelse bliver spørgsmålet om, hvem der har lov til at trykke “kør” på vegne af agenten, et reelt sikkerhedsspørgsmål og ikke længere en teoretisk øvelse.
Denne artikel gennemgår, hvad de nye adminkontroller faktisk dækker, hvordan de adskiller sig fra tilsvarende forsøg hos konkurrenterne, og hvorfor en anden frist, den 28. september, kan blive mindst lige så vigtig for virksomheder i Danmark og Norden, der har rullet Copilot ud i produktion.
Hvad er GitHub Copilots nye adminkontroller?
Kernen i lanceringen er tre handlingstyper, som en agent kan udføre uden at spørge en udvikler først: shell-kommandoer, fillæsning/filredigering og netværkskald til eksterne domæner. Ifølge GitHubs officielle changelog kan en administrator nu sætte et fast resultat for hver kategori: blokeret, kræver godkendelse, eller tilladt uden prompt. GitHub formulerer det sådan: “If you administer GitHub Copilot Business or GitHub Copilot Enterprise, you can now centrally control which agent operations are blocked, require human approval, or can proceed without a prompt” (GitHub, officiel changelog).
Kontrollerne rammer tre steder, hvor Copilot i dag reelt kører: Copilot-appen, Copilot CLI (kommandolinjen) og VS Code-sessioner, der bruger Agent Host. GitHub understreger selv, at dækningen omfatter “shell commands, file reads and edits, and network domains” (GitHub, officiel changelog), altså præcis de tre steder, hvor en autonom agent kan gøre reel skade: køre en kommando, ændre kildekode eller sende data ud af virksomhedens netværk.
Tre resultater, ingen bagdøre
Det, der adskiller denne funktion fra tidligere Copilot-indstillinger, er håndhævelsen. Individuelle udviklere kan ikke længere omgå en central politik ved at slå auto-godkendelse til lokalt eller genbruge en gammel godkendelse. GitHub skriver direkte: “Managed restrictions can’t be weakened by user or workspace settings, auto-approval, or previously saved approvals” (GitHub, officiel changelog). Det betyder i praksis, at en sikkerhedschef kan sætte et gulv, som ingen udviklerkonto kan grave sig under, uanset hvor bekvemt det ville være i en presset sprint.
Sådan konfigureres politikkerne i praksis
De centrale regler styres via en fil kaldet managed-settings.json, som ifølge GitHubs egen dokumentation giver virksomheder mulighed for at bestemme, hvordan brugere kan interagere med agenter på tværs af alle Copilot-klienter: “The managed-settings.json file allows enterprises to control how users can interact with agents across Copilot clients” (GitHub Docs). I VS Code-miljøet bruges tre nøgler til at styre præcis samme tre kategorier, som dokumentationen for enterprise AI-indstillinger beskriver: “Use permissions.allow, permissions.ask, and permissions.deny to control file, shell, and network operations” (GitHub, VS Code enterprise-dokumentation).
Konkret kan en politik se sådan ud for en organisation, der vil starte med en konservativ baseline:
{
"permissions": {
"shell": "ask",
"file_edit": "allow_in_workspace",
"network": {
"default": "deny",
"allowlist": ["github.com", "npmjs.org", "internal.firma.dk"]
}
}
}Baseline-logikken svarer til den, flere sikkerhedsrådgivere har peget på i ugen efter lanceringen: bloker udgående netværkstrafik til domæner, der ikke står på en godkendt liste, kræv godkendelse for shell-kommandoer, og tillad fillæsning inden for det aktuelle workspace uden at spørge hver gang. Det giver reel beskyttelse uden at slå den produktivitetsgevinst ihjel, som fik virksomhederne til at indføre agent-tilstand i første omgang.
Forskellige regler til forskellige teams
En detalje, der har fået mindre opmærksomhed end selve lanceringen, er muligheden for at differentiere politikker mellem teams i samme organisation. Et sikkerhedsteam, der arbejder med produktionsinfrastruktur, kan få strammere regler end et frontend-team, der primært redigerer UI-komponenter i et isoleret repo. Restriktionerne kan stadig ikke svækkes lokalt, uanset hvilket team en udvikler tilhører, men de kan skrues forskelligt fra centralt hold. For virksomheder med adskilte compliance-krav på tværs af afdelinger, for eksempel en bank med både kundevendte apps og interne backend-systemer, er den finkornethed sandsynligvis den reelle grund til, at funktionen vil blive taget i brug hurtigt frem for at blive et skuffe-projekt.
Hvad lanceringen ikke dækker
Tre ting mangler stadig, og det er værd at sige højt, før virksomheder planlægger deres udrulning for stramt. For det første er den officielle changelog-tekst kortfattet om selve opsætningen: den viser ikke trin for trin, hvor i adminpanelet en politik skal skrives, så dokumentationssiderne forbliver den egentlige autoritative kilde. For det andet nævner lanceringen ingen prisændring. Der er intet i materialet, der kobler adgang til de nye kontroller til en ekstra betaling ud over Business- eller Enterprise-abonnementet. For det tredje dækker GA-lanceringen kun tre klienter: Copilot-appen, CLI’en og VS Code med Agent Host. En separat funktion, der dækker JetBrains-miljøer, kører stadig i forhåndsvisning og er ikke det samme værktøj, som vi gennemgår her (mere om det nedenfor).
28. september-fristen, som mange administratorer overser
Lanceringen af de nye tilladelser kommer ikke isoleret. Den 28. september 2026 samler GitHub Copilot Chat på github.com, Copilot Mobile og den skybaserede agent til én samlet oplevelse. Ændringen har konsekvenser, der rækker videre end brugerfladen: chat-historik skifter fra automatisk sletning efter 28 dage til opbevaring i hele kontoens levetid, og standardindstillingen for kodegennemgang ændres fra “Lite” til “Balanced”. Tre separate politikker smelter sammen til én. Det er en beslægtet historie til de databevaringsspørgsmål, som allerede har rejst kritik af, hvordan Copilots PR-godkendelsesdata gemmes på ubestemt tid, og den understreger, at governance af AI-agenter ikke er ét projekt, man afslutter, men en løbende opgave.
For virksomheder, der vil beholde “Lite” som standard for kodegennemgang, skal indstillingen sættes eksplicit, inden ændringen ruller ud. Det samme gælder for agent-tilladelserne: hvis en organisation ikke har konfigureret managed-settings.json, før den samlede oplevelse lander, risikerer den at stå med udviklere, der pludselig møder nye godkendelsesprompter midt i en arbejdsgang, der tidligere kørte uden berøring. Ingen lokal indstilling kan genskabe den gamle, mere lempelige adfærd, når en central politik først er sat.
Dækkede handlinger og standard-baseline
| Handlingskategori | Konkret eksempel | Blokeret | Kræver godkendelse | Tilladt uden prompt |
|---|---|---|---|---|
| Shell-kommandoer | Installation af npm/pip-pakker | – | Anbefalet baseline | Mulig, højere risiko |
| Shell-kommandoer | Sletning af filer (rm, del) | Mulig valgmulighed | Anbefalet baseline | Frarådes |
| Fillæsning | Læsning af kildekode i workspace | – | – | Anbefalet baseline |
| Filredigering | Automatiske commits/ændringer | Mulig valgmulighed | Anbefalet baseline | Mulig, kræver tillid |
| Netværksdomæner | Kald til ikke-godkendte domæner | Anbefalet baseline | Alternativ | Frarådes |
| Netværksdomæner | Kald til allowlistede interne domæner | – | – | Anbefalet baseline |
Konkurrencen: hvor står JetBrains, Cursor og Amazon Q?
Samme dag, den 8. september 2026, satte GitHub også en separat funktion i forhåndsvisning: enterprise-styret sandkasse til Copilot i JetBrains-miljøer. Det er ikke den samme funktion, som vi gennemgår her, men et beslægtet kontrolsæt, der lader administratorer styre sandkasse-aktivering, filsystem- og netværksadgang, proxy-indstillinger, adgang til udviklerværktøjer og macOS Keychain-adgang. Et nyt diagnostikværktøj gør det muligt at verificere, at politikker faktisk håndhæves på udviklermaskiner, ikke bare er konfigureret et sted i skyen uden effekt. Det er værd at holde de to funktioner adskilt: den ene (9. september) dækker Copilot-appen, CLI’en og VS Code, mens den anden (8. september, stadig i preview) specifikt retter sig mod JetBrains-integrationen.
For Cursor og Amazon Q Developer fandtes der ved research til denne artikel ingen officielt dokumenteret, direkte sammenlignelig funktion, der dækker præcis de samme tre kategorier (shell, filer, netværk) med samme tre-vejs håndhævelse. Det betyder ikke, at de to værktøjer mangler enterprise-sikkerhed. Amazon Q Developer læner sig op ad AWS’ eksisterende IAM-rammeværk og infrastruktur-niveau kontroller, mens Cursor har egne agent- og terminalindstillinger. Men ingen af dem har, så vidt det kan dokumenteres i skrivende stund, en centralt håndhævet politikmatrix, der matcher Copilots omfang. Det giver GitHub et reelt forspring i den del af salgssamtalen, der handler om compliance-afdelinger og sikkerhedsteams, som ofte er den reelle bremseklods, når en virksomhed overvejer at skalere AI-agenter fra pilotprojekt til produktion.
Copilots tidslinje i september 2026
| Dato | Hændelse |
|---|---|
| 4. september | GPT-6 Astra bliver alment tilgængelig i Copilot for Pro+, Max, Business og Enterprise |
| Uge fra 7. september | Eksperimentel stemmetilstand lanceres, hvor brugere kan tale til, afbryde eller omdirigere Copilot undervejs |
| 8. september | Enterprise-styret sandkasse til Copilot i JetBrains sættes i offentlig forhåndsvisning |
| 9. september | Enterprise managed permissions for agent-handlinger bliver alment tilgængelig |
| 10. september | Modellen MAI-Code-1-Flash udfases og erstattes af MAI-Code-1.1-Flash |
| 28. september | Copilot Chat, Mobile og cloud-agent samles, chat-historik skifter til opbevaring uden udløb |
Mønstret er tydeligt, når man lægger datoerne ved siden af hinanden: GitHub har komprimeret en hel kvartals enterprise-arbejde ind i under fire uger. Det hænger sandsynligvis sammen med det pres, konkurrenter som JetBrains AI Assistant lægger på prissætning og funktionsdækning, kombineret med et bredere behov for at vise store kunder, at agent-tilstand kan styres, ikke kun aktiveres.
Historisk kontekst: fra autofuldførelse til agent med nøgler til huset
Da GitHub Copilot lancerede i 2021, var værktøjet i praksis en avanceret autofuldførelsesfunktion. Det foreslog kodelinjer, en udvikler skulle læse, forstå og selv indsætte. Den model krævede ingen særlig governance, fordi mennesket stod mellem hvert forslag og den faktiske udførelse. Agent-tilstand ændrede den ligning fundamentalt: agenten kan nu selv skrive, køre og committe kode, installere afhængigheder og i nogle konfigurationer sende data ud af netværket, alt sammen uden at et menneske nødvendigvis ser hvert trin.
Den udvikling har allerede givet sikkerhedsforskere nyt stof. Tidligere i september 2026 beskrev sikkerhedsfirmaet AIR Security en sårbarhed ved navn Plugin4Shell, som ramte fire store AI-kodeagenter, herunder Claude Code, Codex og Copilot selv, gennem en svaghed i, hvordan plugins blev verificeret (Help Net Security). Samme måned dokumenterede andre forskere en separat sårbarhedsklasse ved navn GitSpawn, der ramte syv AI-kodeagenter på tværs af markedet. GitHub har ikke offentligt koblet de nye adminkontroller direkte til nogen af disse hændelser, men tidslinjen taler for sig selv: branchen bevæger sig fra “agenten virker” til “agenten skal kunne styres”, og det er en naturlig, om end sen, modning af en kategori, der voksede hurtigere end dens sikkerhedsmodel kunne følge med.
Markedseffekt: hvad betyder det for danske og nordiske virksomheder?
For it-afdelinger i Danmark og resten af Norden lander de nye kontroller på et tidspunkt, hvor NIS2-kravene allerede har skærpet forventningerne til dokumenteret risikostyring af softwareværktøjer, inklusive dem, der bruger kunstig intelligens. En centralt håndhævet politik for, hvornår en agent må røre produktionskode eller sende data ud af virksomhedens netværk, er lige præcis den type kontrol, en revisor eller et tilsyn vil spørge efter, når en virksomhed skal dokumentere, hvordan den styrer AI-værktøjer med adgang til kildekode og infrastruktur.
Samtidig er der en praktisk friktion, som mange danske teams vil mærke først: udviklere, der er vant til, at agenten “bare kører”, vil pludselig møde godkendelsesprompter midt i en arbejdsgang. Det kræver kommunikation fra ledelsen, før politikkerne rulles ud, ikke bagefter. Erfaringen fra lignende sikkerhedsstramninger, for eksempel da GitLab Duo blev ramt af en sårbarhed med CVSS-score 8,7 tidligere i 2026, viser, at virksomheder, der venter til efter en hændelse med at stramme adgangsstyringen, typisk betaler en højere pris i tabt tillid end dem, der handler proaktivt.
Hvad branchen siger om ansvarlig agent-styring
GitHubs egen dokumentation lægger vægt på, at politikkerne er en gulv, ikke en fuldstændig afskaffelse af agent-autonomi. Det fremgår tydeligt af, hvordan virksomheden selv formulerer den tekniske ramme i VS Code-dokumentationen: “Use permissions.allow, permissions.ask, and permissions.deny to control file, shell, and network operations” (GitHub, VS Code enterprise-dokumentation). Kombineret med garantien om, at lokale indstillinger ikke kan svække en central politik, tegner det et billede af et produkt, der er bygget til at blive stillet skarpt af en sikkerhedsafdeling og derefter efterlades i fred, i stedet for at kræve konstant opsyn fra den enkelte udvikler.
Fem forudsigelser for agent-governance i 2027
- Konkurrenterne følger efter inden årsskiftet. Med Copilot først ude med en fuld tre-kategori politikmatrix vil det være svært for Cursor, Amazon Q Developer og andre enterprise-fokuserede værktøjer at stå uden et tilsvarende svar i mere end et par måneder, især hvis store kunder begynder at kræve det i udbud.
- Politikker bliver en del af compliance-tjeklister. Forvent, at revisorer og NIS2-relaterede audits inden for det næste år konkret spørger efter dokumentation for, hvordan en organisation styrer agent-tilladelser, på samme måde som de i dag spørger efter adgangsstyring til produktionsdatabaser.
- Flere lag af granularitet kommer. Team-niveau politikker er kun det første trin. Det er sandsynligt, at GitHub og konkurrenterne udvider til repo-niveau eller endda fil-niveau regler i løbet af 2027, i takt med at agenter får adgang til mere følsomme kodebaser.
- Standardindstillinger bliver strammere, ikke løsere. Efterhånden som flere sårbarheder i AI-agenter bliver dokumenteret offentligt, vil leverandørerne under pres fra sikkerhedsteams sandsynligvis flytte fabriksindstillingen fra “tillad” til “spørg” for flere handlingstyper end i dag.
- Data-opbevaring bliver den næste stridszone. Skiftet den 28. september fra 28-dages sletning til opbevaring uden udløb for chat-historik peger på et mønster, hvor leverandører prioriterer produktdata til modeltræning og fejlfinding over minimering af datamængden, hvilket sandsynligvis udløser flere GDPR-relaterede spørgsmål fra europæiske kunder i 2027.
Sådan kommer en organisation i gang i dag
For it- og sikkerhedsansvarlige, der administrerer Copilot Business eller Enterprise, er det første skridt at kortlægge, hvor teams i dag reelt lader agenter køre shell-kommandoer, redigere filer og nå ud til netværksdomæner, før en politik overhovedet skrives. Dernæst bør hver kategori tildeles et konkret resultat baseret på organisationens risikovillighed, med mulighed for at opdele politikker per team, hvor risikoprofilerne reelt er forskellige. Endelig bør udviklere advares, før håndhævelsen slår til: alle, der har vænnet sig til gemte godkendelser eller auto-godkendelse, vil møde nye prompter, i det øjeblik en restriktion lander, og ingen lokal indstilling kan gendanne den gamle adfærd.
For udviklere, der bruger agenter i det daglige, er rådet enklere: forvent, at godkendelsesprompter kan dukke op i arbejdsgange, der tidligere kørte uden berøring, og indregn den tid i planlægningen. For organisationer, der stadig overvejer, om de tør give en agent adgang til shell og netværk, er den klassiske indvending, “vi kan ikke lade en autonom agent røre produktionsmiljøet”, nu et konfigurationsspørgsmål frem for et fast nej.
Ofte stillede spørgsmål
Hvad er enterprise managed permissions for GitHub Copilot?
Det er en funktion, der giver administratorer af Copilot Business og Copilot Enterprise mulighed for centralt at bestemme, om en agents handlinger inden for shell-kommandoer, fillæsning/-redigering og netværksdomæner skal blokeres, kræve godkendelse eller tillades uden prompt.
Kan en udvikler omgå de centrale politikker?
Nej. Ifølge GitHub kan restriktioner sat centralt ikke svækkes af bruger- eller workspace-indstillinger, auto-godkendelse eller tidligere gemte godkendelser.
Hvilke Copilot-klienter understøtter funktionen?
Funktionen er alment tilgængelig i Copilot-appen, Copilot CLI og VS Code-sessioner, der bruger Agent Host. JetBrains-integrationen dækkes af en separat, stadig eksperimentel sandkasse-funktion.
Koster de nye adminkontroller ekstra?
Der er intet i den officielle lancering, der kobler funktionen til en separat pris. Den kræver et Copilot Business- eller Copilot Enterprise-abonnement, men fremstår som en del af de eksisterende planer.
Kan forskellige teams i samme virksomhed have forskellige regler?
Ja. Administratorer kan sætte specialiserede politikker per team, så risikoprofiler kan variere internt, samtidig med at ingen lokal indstilling kan svække den enkelte teams politik.
Hvad sker der den 28. september 2026?
GitHub samler Copilot Chat på github.com, Copilot Mobile og den skybaserede agent til én oplevelse. Samtidig skifter chat-historik fra automatisk sletning efter 28 dage til opbevaring uden udløb, og standarden for kodegennemgang ændres fra “Lite” til “Balanced”.
Har konkurrenter som Cursor eller Amazon Q Developer en tilsvarende funktion?
Der findes ikke i skrivende stund en offentligt dokumenteret funktion hos Cursor eller Amazon Q Developer, der dækker præcis samme tre kategorier med samme centrale tre-vejs håndhævelse som Copilots nye kontroller.
Er JetBrains-sandkassen det samme som Copilots managed permissions?
Nej. Det er to forskellige funktioner lanceret en dag fra hinanden. Managed permissions (9. september) dækker Copilot-appen, CLI’en og VS Code, mens JetBrains-sandkassen (8. september) er en separat, stadig eksperimentel funktion med sit eget kontrolsæt for filsystem, netværk, proxy og macOS Keychain.
