GitHub Copilot computer use: begin met smalle rechten en verifieer writes

Een desktopagent kan met legacysoftware werken die geen API of command-line-interface heeft. Daar zit ook het risico: GitHub Copilot computer use kan tekst op een scherm lezen, klikken, typen en door schermen navigeren. Een verkeerde knop of onverwachte dialoog kan een echte wijziging veroorzaken.

Dit artikel beschrijft een patroon, geen uitgevoerde desktoptest. De precieze schermen en permissies kunnen tijdens de preview veranderen. De kern is om drie dingen uit elkaar te houden: wat de agent kan zien, welke applicatie hij mag bedienen en hoe je controleert dat de taak het juiste resultaat had.

Wanneer heb je GitHub Copilot computer use nodig?

Gebruik computer use vooral wanneer de taak echt via een grafische applicatie moet lopen. Als een API, MCP-server, terminalcommando, filesystemtool of browserautomatisering hetzelfde werk direct kan doen, is die route meestal beter te structureren en te controleren.

GitHub kondigde de functie op 1 oktober 2026 aan als public preview voor Copilot CLI en de Copilot app op macOS en Windows. De agent kan onder meer leesbare app-inhoud bekijken, klikken, typen, scrollen en tussen applicaties navigeren. Denk aan een demo waarin je een status uit een oud back-officeprogramma laat samenvatten. Een formulier indienen of een betaling uitvoeren is een heel andere risicoklasse.

Een visueel scherm is geen stabiele API. Een update, pop-up, focuswissel of andere venstergrootte kan dezelfde klik op een andere plek laten landen. Behandel computer use daarom als een extra interface met eigen foutmodi.

Wat keurt een computer-use-permissie goed?

Een permissie kan Copilot toegang geven om een applicatie te bedienen; de documentatie belooft niet dat iedere afzonderlijke muisklik of wijziging daarna een nieuwe bevestiging krijgt. Lees de dialoog daarom precies en behandel toestemming voor een app of sessie niet als bewijs dat een specifieke write inhoudelijk is goedgekeurd.

Computer use staat standaard uit. Volgens de huidige GitHub-documentatie over computer use bepaalt de Tool Permissions-instelling van de Copilot-omgeving of Copilot om goedkeuring vraagt voordat het een applicatie bedient. Je kunt een verzoek voor de huidige sessie toestaan, opslaan voor later of weigeren.

Let op de optie Always allow. GitHub bewaart die lokaal; de toestemming kan gelden in zowel Copilot CLI als de Copilot app op dezelfde computer. Een opgeslagen toestemming verwijderen voorkomt toekomstige hergebruik, maar trekt toegang in een al lopende sessie niet in. Een deny-regel krijgt voorrang op een opgeslagen of automatische approval. Op macOS vraagt de functie ook om Accessibility- en, waar nodig, Screen Recording-toegang.

Voor organisaties kan een beheerder computer use via managed settings uitschakelen met de instelling features.computerUse op false. Een lokale instelling kan dat verbod niet opheffen. Controleer dus ook het beleid van je organisatie voordat je de functie in een werkapp probeert.

Hoe start je read-only?

Begin met een taak die informatie leest en geen waarden verandert. Zeg expliciet welke applicatie is toegestaan en welke handelingen verboden zijn. Die instructie helpt de agent, maar is geen technische lock.

Gebruik bijvoorbeeld deze demo-prompt in een testapp met synthetische gegevens:

Open de demo-app Taken en lees de status van DEMO-104.
Verander niets, klik niet op Verzenden en dien geen formulier in.
Als je toegang nodig hebt, vraag die alleen voor deze sessie.
Geef terug welke status je ziet en welke tekst je als bewijs hebt gelezen.

Controleer vóór je start:

1. Taak: is het doel een read-only samenvatting of een write?
2. Applicatie: is precies de bedoelde app geselecteerd?
3. Scherminhoud: staat daar informatie in die je niet naar de modelcontext wilt sturen?
4. Toestemming: is de keuze tijdelijk, opgeslagen of geweigerd?
5. Stoproute: weet je hoe je de lopende handeling onderbreekt?

In de Copilot app kun je stoppen met de Stop-knop of Escape. In CLI noemt GitHub Escape tweemaal als stopactie. Oefen dit met een laag-risico taak; vertrouw bij een gevoelige taak niet op een onbekende stoproute.

Hoe laat je een write controleren?

Laat een write pas doorgaan nadat je de exacte wijziging en de echte toestemming hebt bekeken. De app-permissie is geen transactiebevestiging; gebruik voor onomkeerbare of impactvolle acties de eigen bevestigingsstap van de applicatie of voer die stap zelf uit.

Een bruikbaar patroon heeft vier controles:

1. Leg de beginstatus vast. Gebruik een synthetisch record of een niet-productieomgeving.
2. Vraag eerst om een voorstel. Laat Copilot de doelwaarde en beoogde stappen noemen, maar laat hem nog niets verzenden.
3. Beoordeel de echte handeling. Controleer de app, het record en de actie waarop de toestemming betrekking heeft. Als de permissiedialoog niet iedere write apart begrenst, laat de applicatie zelf om bevestiging vragen of doe de submit handmatig.
4. Controleer de opgeslagen eindstatus. Herlees het record in de app of controleer een onafhankelijk audit-event. Een klik of een “klaar”-antwoord bewijst niet dat de wijziging is opgeslagen.

Test ook de weigering. Vraag in een wegwerpbare demo bijvoorbeeld om een waarde te wijzigen terwijl je alleen-lezen toestemming hebt gegeven. De gewenste uitkomst is dat er geen write plaatsvindt; controleer dat aan de hand van de echte status, niet alleen aan de hand van wat Copilot zegt.

Welke foutmodi moet je verwachten?

De GitHub-documentatie waarschuwt dat een veranderende interface, afwijkend scherm of timingprobleem tot een verkeerde control, verkeerde tekst of herhaalde actie kan leiden. Een formulier kan daardoor tweemaal worden verzonden of tekst kan in het verkeerde veld belanden.

Computer use kan ook zichtbare gegevens uit het werk of de accounts van anderen meenemen in de context. Kies dus alleen applicaties en taken waarvan de getoonde inhoud geschikt is om te delen. Een screenshot, trace of opname kan zelf gevoelige informatie bevatten. Bewaar die niet standaard; log liever een taak-ID, beslissing, tijdstip en gecontroleerde uitkomst.

Always allow vergroot het risico bij apps met klant-, financiële of beheeracties. Een sterke standaard is sessiegebonden toegang voor één noodzakelijke app en een aparte, door de applicatie afgedwongen bevestiging voor impactvolle submits.

Wanneer kies je computer use wel of niet?

De preview maakt desktopautomatisering toegankelijker, maar vervangt geen autorisatie, applicatievalidatie of menselijk oordeel. Voor bredere grenzen rond coding agents, zie hoe je een onbekende repository veilig beoordeelt en AI-agenten in productie. Voor ontwerpkeuzes op systeemniveau: AI-architectuur voor agent- en systeemgrenzen.

Samenvatting

Start read-only, geef alleen tijdelijke toegang tot de noodzakelijke app en controleer iedere bedoelde write in de echte applicatie. Always allow is een lokale, blijvende keuze voor toekomstig gebruik en verwijderen beëindigt een actieve sessie niet. Computer use kan de UI bedienen; het bewijst niet dat een klik juist was of dat een wijziging is opgeslagen.