GitHub Copilot agent: VS Code zet sandboxing aan, dit regel je deze week

Microsoft bracht op 7 oktober 2026 met VS Code 1.141 cross-platform sandboxing voor de GitHub Copilot agent: je kunt nu per sessie instellen welke bestanden en welke netwerkadressen de agent mag raken, naast de goedkeuringsvraag die er al was (officiële release notes). Werkt jouw team met Copilot's agentmodus in VS Code, dan is dit geen cosmetische toevoeging: het is de eerste ingebouwde grens op wat de agent zelf mag doen zodra hij een terminalcommando draait. Hieronder: waarom deze functie er nu is, hoe de sandbox werkt, en de instelling die bij het aanzetten vaak over het hoofd wordt gezien.

Wat is de GitHub Copilot agent, en wat verandert er met sandboxing?

De GitHub Copilot agent is de agentmodus in VS Code en de Copilot-app: in plaats van losse suggesties te geven, leest hij je project, kiest zelf tools (bestanden bewerken, commando's draaien, MCP-servers aanroepen) en werkt een taak in meerdere stappen af. Tot nu toe kende die agent twee standen: een actie draait automatisch, of hij vraagt eerst jouw goedkeuring. Sandboxing voegt een derde, onafhankelijke laag toe. Microsoft legt het zelf zo uit in de documentatie over agent-sandboxing: "Approvals" bepalen of een actie een bevestiging nodig heeft, "Sandboxing" beperkt welke bestanden en netwerkbronnen een actie daadwerkelijk kan bereiken, ook als je hem had goedgekeurd.

Dat onderscheid is de kern. Je kunt een terminalcommando goedkeuren zonder te weten wat het precies raakt. De sandbox zorgt dat zelfs een goedgekeurd commando niet verder komt dan de paden en domeinen die jij hebt toegestaan. Dat werkt via besturingssysteem-niveau afscherming (op Linux met bubblewrap, op macOS ingebouwd, op Windows via een losse update) voor terminalcommando's en de processen die daaruit starten, en standaard ook voor lokaal gestarte MCP-servers en taalservers. Ingebouwde tools die geen los proces starten, zoals het lezen van een bestand in de editor zelf, hebben hun eigen controle en vallen er dus buiten.

Waarom heeft de GitHub Copilot agent nu een sandbox nodig?

Sandboxing komt niet uit het niets. GitHub's eigen beveiligingsteam publiceerde eerder onderzoek waarin onderzoeker Michael Stepankin liet zien hoe kwetsbaar de agentmodus zonder deze laag was (Safeguarding VS Code against prompt injections, github.blog). Hij plaatste een verborgen instructie in een gewone GitHub Issue en vroeg Copilot vervolgens alleen om die issue samen te vatten. Het model volgde in plaats daarvan de verborgen instructie. Het las een lokaal GitHub-token uit een bestand en stuurde dat naar een extern domein. Dat mocht zonder goedkeuring, want het doeladres leek op het eerste gezicht op de vertrouwde lijst te staan. Een tweede, apart gevonden route gebruikte de ingebouwde browser-tool op dezelfde manier. Een derde liet zien dat een bestandsbewerking al op schijf staat vóór je de melding ziet: de agent herschreef settings.json zodat er bij het opnieuw laden automatisch een rekenmachine opstartte, als bewijs dat een MCP-server net zo makkelijk vanuit die bewerking te starten was.

GitHub repareerde elk van deze drie routes apart (het vertrouwde-domeinen-lek, de browser-tool en het automatisch opslaan van bewerkingen buiten de werkmap), maar dat zijn lapmiddelen per tool. Sandboxing pakt het mechanisme zelf aan: zelfs als een volgende tool een vergelijkbare fout bevat, komt een proces niet verder dan de bestanden en domeinen die jij hebt opgegeven. Dat is ook precies waarom prompt injection als risico nummer één op de OWASP-lijst voor LLM-toepassingen staat: het model kan zelf niet altijd onderscheiden tussen jouw instructie en tekst die het toevallig tegenkomt in een bestand, een issue of een webpagina.

Hoe werkt een ai agent sandbox: bestanden, netwerk en de instelling die mensen missen

Drie bestandscategorieën bepalen wat een gesandboxte actie mag: readwritePaths (lezen en schrijven), readonlyPaths (alleen lezen) en deniedPaths (geen toegang). Staat een pad in meerdere lijsten, dan wint deniedPaths, daarna readonlyPaths. Je huidige projectmap krijgt automatisch lees- en schrijftoegang; alles daarbuiten moet je zelf toevoegen.

Netwerktoegang is een losse knop, en dat is precies de instelling die vaak over het hoofd wordt gezien: chat.agent.sandbox.network.allowNetwork staat standaard op true. Sandboxing aanzetten blokkeert het internet dus niet automatisch. Je beperkt uitgaand verkeer pas met een expliciete lijst in allowedDomains of deniedDomains. Waarom Microsoft die knop niet standaard dichtzet: de meeste coding-taken hebben zelf al netwerktoegang nodig (pakketten installeren, documentatie opzoeken, een API testen), en een dichte knop zou de agent bij elke normale taak laten vastlopen. Het gevolg is wel dat "ik heb sandboxing aan" zonder verdere actie niets zegt over wat de agent nog naar buiten kan sturen. Dat was precies het lek in het onderzoek hierboven: het proces had toegang tot het netwerk, en dat maakte het tokenlek mogelijk.

Een derde instelling werkt averechts als je hem laat staan: chat.agent.sandbox.fileSystem.allowDevToolAccess staat standaard op true en geeft de agent leestoegang tot gangbare ontwikkeltools, configuratie en caches, inclusief registry-tokens. Handig voor een build die anders vastloopt, maar het is precies het soort toegang die een geslaagde prompt injection zou willen gebruiken.

Beslisregel: welke instelling past bij jouw copilot coding agent?

Elke stap hoger in strengheid kost een paar extra meldingen tijdens het werk. Begin daarom bij de rij die bij je huidige repository past, niet bij de strengste optie: te veel geblokkeerde, normale acties leidt ertoe dat teams de sandbox na een week weer uitzetten, en dan is de bescherming weg.

Het voorbeeld: een vergiftigde GitHub Issue, met en zonder sandbox

Dit is het echte, door GitHub gedocumenteerde scenario uit het onderzoek hierboven, niet een verzonnen illustratie.

De invoer. Iemand plaatst een GitHub Issue met een stuk tekst dat op het oog een gewone bugmelding is. Verstopt in die tekst staat een instructie die net zo geschreven is als Copilot's eigen systeemprompt, met een voorwaarde erbij ("alleen als de huidige datum vandaag is") om detectie te ontwijken.

De prompt. Een ontwikkelaar vraagt niets uitzonderlijks: "Vat issue #482 voor me samen."

Wat er misging, zonder sandbox. Het model volgde de verborgen instructie in plaats van alleen samen te vatten. Het las een lokaal GitHub-token uit een configuratiebestand en stuurde dat via een tool voor externe aanroepen naar een domein dat op het eerste gezicht op de vertrouwde lijst leek te staan (een tekstvergelijking zag example.com/.github.com/xyz ten onrechte aan als een geldig GitHub-adres). Geen melding, geen goedkeuringsvraag: de ontwikkelaar zag alleen een normale samenvatting verschijnen.

Wat sandboxing daaraan verandert, en wat niet. Met sandboxing aan en een expliciete domeinenlijst was die externe aanroep geblokkeerd geweest, ook al had het model de instructie weer gevolgd: het doeladres stond niet op de toegestane lijst. Zonder die expliciete lijst (dus met de standaardinstelling allowNetwork: true en een lege allowedDomains) was de aanroep nog steeds doorgegaan, want de sandbox regelt dan alleen welke bestanden het proces mag lezen, niet naar welk adres het mag versturen. Dat is precies waarom de beslisregel hierboven bij gevoelige repositories een vaste toegestane lijst aanraadt in plaats van te vertrouwen op de standaardinstelling.

Wat je nog altijd zelf doet. De sandbox voorkomt niet dat het model de instructie volgt; hij beperkt alleen wat het daarmee kan bereiken. GitHub repareerde de onderliggende tool-lekken intussen zelf (bevestiging bij nieuwe domeinen, geen bewerkingen meer buiten de werkmap), maar een volgende, nog onbekende tool-fout is niet uit te sluiten. Daarom blijft de vaste domeinenlijst de regel, niet de uitzondering, bij elk project dat externe bijdragen krijgt.

Wat je realistisch mag verwachten van deze coding agent, en wat niet

Zet geen vast uurtje op dit werk, maar de stappen die het kost. Een .env-bestand of SSH-key opzoeken en het pad noteren kost twee tot vijf minuten per pad; bij een project met vijf tot tien van zulke paden is dat 15 tot 30 minuten. Je package-registry en de twee of drie interne API's die je build nodig heeft in allowedDomains zetten kost nog eens 10 minuten, als je vooraf weet welke dat zijn. De rest van de tijd gaat naar de eerste testrun: /sandbox policy draaien om te zien wat er echt actief staat, een normale taak uitvoeren en de twee tot drie meldingen oplossen die daarbij meestal naar boven komen (vaak een build-tool die buiten de toegestane map wil schrijven). Voor een gemiddeld project met vijf tot tien gevoelige paden en een handvol netwerkbestemmingen komt dat uit op 40 tot 60 minuten, de eerste keer. Een project zonder duidelijke geheimen is sneller klaar; veel losse scripts en tools kosten meer tijd.

Wat na een week niet beter wordt: de sandbox leert niet mee en wordt niet slimmer over wat "normaal" gedrag is voor jouw project. Elke wijziging aan je workflow (een nieuwe build-tool, een nieuwe interne API) vraagt een nieuwe regel. En op Windows blijft de ondersteuning experimenteel: zonder de vereiste systeemupdate start een gesandboxt commando gewoon niet, in plaats van ongesandboxt door te draaien.

Drie meetpunten zonder extra tooling, na zeven dagen:

• Hoeveel keer moest je "toestaan buiten de sandbox" goedkeuren? Gebruik het slash-commando /sandbox policy om de actieve regels te zien. Meer dan twee of drie keer per dag betekent dat je paden te strak staan voor je eigen workflow.
• Welke domeinen stonden niet op je lijst maar waren wel nodig? Elke keer dat je een domein moest toevoegen tijdens het werk, is een signaal dat je vooraf-inventarisatie niet compleet was.
• Is er één sessie geweest waarin je de sandbox volledig uitzette om door te kunnen werken? Dat is het signaal dat de instelling niet past bij de taak, niet dat de sandbox overbodig is. Zoek dan de specifieke blokkade op in plaats van de knop om te zetten.

Wat sandboxing niet oplost

Sandboxing is geen vervanging voor code review. Een agent die een kwaadaardige instructie volgt binnen zijn toegestane paden (bijvoorbeeld een bestand binnen je eigen projectmap aanpassen op een manier die een achterdeur toevoegt) wordt er niet door tegengehouden: dat blijft iets wat een mens moet zien voor het gemerged wordt. Het is ook geen vervanging voor een Dev Container of GitHub Codespace: die isoleren het hele besturingssysteem, sandboxing isoleert één proces op je eigen machine. En de functie staat zelf nog in preview: Microsoft waarschuwt dat het gedrag nog kan veranderen voor de volgende release.

Een tweede, structurele grens is al zichtbaar bij vergelijkbare sandboxes van andere coding agents. Onafhankelijke beveiligingsonderzoekers van Pillar Security publiceerden deze zomer zeven lekken in de sandboxes van Cursor, OpenAI's Codex CLI, Google's Gemini CLI en Google's Antigravity, onder de naam "The Week of Sandbox Escapes" (Cloud Security Alliance, research note). Geen van die zeven lekken brak de sandbox zelf open. De agent schreef telkens een bestand dat binnen zijn toegestane paden mocht (een Git-hookbestand, een virtuele-omgevingbestand, een taakdefinitie), en een ander, niet-gesandboxt onderdeel (een editor-extensie, Git zelf, een Docker-daemon) voerde dat bestand later klakkeloos uit. De onderzoekers noemen het zelf treffend: de agent "hoefde de sandbox niet te breken, hij moest alleen iets schrijven dat een vertrouwd onderdeel buiten de sandbox later zou uitvoeren." Precies dat mechanisme zag je al in het voorbeeld van settings.json hierboven: de agent paste een bestand binnen zijn eigen rechten aan, en een ander onderdeel (het herladen van de MCP-configuratie) voerde de gevolgen daarvan uit zonder zelf gesandboxt te zijn. Omdat VS Code's sandbox nog in preview staat en nog niet het hele besturingssysteem isoleert, is het aannemelijk dat dezelfde aanpak hier ook werkt: controleer daarom niet alleen welke paden en domeinen de agent zelf mag raken, maar ook welke andere, niet-gesandboxte tools in je editor bestanden uit je projectmap automatisch oppikken en uitvoeren.

Doe dit deze week

1. Update naar VS Code 1.141 en check de platformvereiste

   Op macOS kun je direct door. Op Linux of WSL2 installeer je bubblewrap en socat. Op Windows installeer je eerst de beveiligingsupdate van 8 september 2026 die bij jouw Windows-versie past, anders start een gesandboxt commando niet.

2. Inventariseer welke paden geheimen bevatten, en zet chat.agent.sandbox.enabled aan

   Zoek per repository naar .env-bestanden, SSH-keys en cloud-configuratie buiten de projectmap. Zet die in deniedPaths. Draai daarna /sandbox policy in de chat om te zien welke regels echt actief zijn, niet alleen welke je dacht te hebben gezet.

3. Vul een vaste domeinenlijst in plaats van op de standaardinstelling te vertrouwen

   Zet allowedDomains op de paar adressen die je builds en pakketbeheer echt nodig hebben (je package-registry, je interne API's). Dat is de stap die het voorbeeld hierboven had geblokkeerd, en die de standaardinstelling overslaat.

Het recept dat vandaag werkt: één repository met klantgegevens of externe bijdragers, sandboxing aan, een handmatig ingevulde deniedPaths-lijst voor geheimen, en een korte allowedDomains-lijst in plaats van de standaardinstelling. Test dat een week voor je het op meer projecten uitrolt. Wil je de bredere afweging maken welke taken een prompt, een workflow of een volledige agent verdienen binnen je eigen team, dat niveau zetten we samen neer in de Agent Sprint. Twijfel je waar te beginnen met governance rond coding agents, plan een kort gesprek.

Bronnen

• Visual Studio Code, Visual Studio Code 1.141 release notes. Officiële release notes, zelf geopend. Bron voor de releasedatum (7 oktober 2026) en de beschrijving van de sandboxing-functie zelf.
• Visual Studio Code, Sandbox Copilot Agent Host sessions. Officiële documentatie, zelf geopend. Bron voor de instellingennamen, de standaardwaarden (allowNetwork: true, allowDevToolAccess: true), de platformvereisten en het /sandbox policy-commando.
• GitHub, Safeguarding VS Code against prompt injections door Michael Stepankin, GitHub Security Lab. Leveranciersonderzoek (GitHub Security Lab is onderdeel van GitHub, zelf onderdeel van Microsoft), zelf geopend. Bron voor het uitgewerkte voorbeeld: de vergiftigde GitHub Issue, het tokenlek via de vertrouwde-domeinenlijst, de browser-tool-route en het automatisch opslaan van bewerkingen.
• Cloud Security Alliance, AI Coding Agent Sandbox Escapes: The Trust Handoff Flaw, op basis van onderzoek van Pillar Security. Onafhankelijke branchevereniging zonder winstoogmerk, los van Microsoft, GitHub of de vier onderzochte leveranciers, zelf geopend. Bron voor het trust-handoff-patroon en de zeven sandbox-lekken bij Cursor, Codex CLI, Gemini CLI en Antigravity.
• OWASP GenAI Security Project, OWASP Top 10 for Large Language Model Applications. Onafhankelijke, open-source beveiligingsstandaard, zelf geopend. Bron voor de positie van prompt injection als risico nummer één.
• Project Impact, AI-agent en MCP-server. Eigen uitleg van de onderliggende begrippen die in deze post worden gebruikt.

Veelgestelde vragen

• Wat is sandboxing bij de GitHub Copilot agent precies?

  Sandboxing is een functie in VS Code 1.141 (7 oktober 2026) die beperkt welke bestanden en netwerkadressen de Copilot-agent kan bereiken als hij een terminalcommando draait. Het is een losse laag naast de goedkeuringsvraag: zelfs een goedgekeurd commando komt niet verder dan de paden en domeinen die jij hebt toegestaan.

• Wat is een ai agent sandbox, en vervangt die code review?

  Een ai agent sandbox beperkt wat een AI-agent kan bereiken op je machine (welke bestanden, welke netwerkadressen), niet wat hij inhoudelijk voorstelt. Hij vervangt geen code review: een agent die binnen zijn toegestane paden een schadelijke wijziging voorstelt, wordt er niet door tegengehouden. Dat blijft iets wat een mens ziet voor het gemerged wordt.

• Blokkeert sandboxing automatisch internettoegang voor mijn coding agent?

  Nee. De instelling die uitgaand netwerkverkeer toestaat (chat.agent.sandbox.network.allowNetwork) staat standaard op aan, ook als je sandboxing zelf activeert. Wil je de toegang van je coding agent tot het internet beperken, dan moet je zelf een domeinenlijst invullen in allowedDomains of deniedDomains.

• Is de GitHub Copilot coding agent veilig voor bedrijfscode met geheimen?

  Met sandboxing aan en een expliciete deniedPaths-lijst voor .env-bestanden, SSH-keys en cloud-credentials is het risico kleiner, maar niet nul. GitHub's eigen beveiligingsonderzoek liet zien dat de agent via een vergiftigde GitHub Issue een token kon lekken; sandboxing had die specifieke aanroep geblokkeerd, mits je vooraf een domeinenlijst had ingevuld.

• Werkt sandboxing ook voor Claude Code of Codex in VS Code?

  De sandboxing-functie uit VS Code 1.141 is gebouwd voor de Agent Host die de Copilot-harness aandrijft en geldt standaard voor lokaal gestarte MCP-servers en taalservers binnen die sessie. Gebruik je Claude Code of Codex als los commandoregelprogramma buiten VS Code, dan val je buiten deze specifieke sandbox en regel je isolatie via een eigen container of Codespace.