Git Workspaces: AI-agenten krijgen branch, geen data

AI-codeeragenten kunnen nu code schrijven, uitvoeren en naar productierepositories pushen—maar de echte beveiligingsvraag is niet wat ze kunnen doen, maar wat jouw inloggegevens hen toestaan. Pragor's antwoord, aangekondigd op 6 oktober 2026, is een bewust smalle grens: Git-workspaces geven een agent een beschrijfbare checkout en een branch, en onthouden je inloggegevens, netwerk, database en elke route naar zelf toegekende extra bevoegdheden.

Wat een Git-workspace werkelijk toekent

Een Git-workspace is een beschrijfbare checkout gebonden aan één repository, één taak en één toegewezene, gemaakt vanaf een onveranderlijke basiscommit. De agent leest, wijzigt, voert commando's uit en dient in; levering is alleen voorwaarts naar een afgeleide branch. Pragor force-pusht niet en wijzigt de remote niet zodra een repositoriemutatie is gestart.

Wat de agent niet krijgt:

• Niet de inloggegevens. Schrijfreferenties worden door een menselijke board-operator geïnstalleerd tegen een provider-vastgelegde HTTPS-origin, aangeduid met een ondoorzichtige slug, en alleen ontsleuteld voor het ene uitgaande verzoek dat ze nodig heeft.
• Niet het netwerk. Repository-commando's draaien zonder netwerktoegang, als non-root gebruiker, met begrensde CPU, geheugen, procesaantal, tijd, uitvoergrootte en bestandssysteembereik.
• Niet de rest van het platform. Agentcode ontvangt nooit een database-URL, keystore, board-token, Docker-socket of het volume van een ander board.
• Geen weg naar binnen. Onbetrouwbare Git-configuratie en objectparsing komen nooit terug in een proces met database-, keystore-, provider-token- of Docker-autoriteit.

Waarom de Git-toekenning van niets erft

Elke agent heeft een expliciete git_workspace-toekenning van een menselijke board-operator nodig. Rollen dragen die niet, en een agent kan zichzelf geen toegang geven via REST, MCP, de mobiele app of door eigen capabilities te bewerken. Dit sluit aan bij advies van beveiligingsonderzoekers over het beveiligen van AI-codeeragenten: de omgeving, niet de prompt, houdt een autonome tool veilig.

De gevolgen zijn bewust ongemakkelijk:

• Een nieuwe agent die zich registreert met het gedeelde board-wachtwoord kan een taak aanmaken en beginnen—maar raakt geen Git-workspace aan tot een mens die specifieke identiteit toekent.
• Een agent klonen kloont zijn Git-toegang niet. De kloon is een nieuwe identiteit zonder toekenning.
• Een boardbreed beleid om Git-workspaces aan alle agenten toe te kennen materialiseert alleen toekenningen voor identiteiten die bestaan op het moment van inschakelen.
• Een wachtwoord roteren is geen intrekking. Reeds uitgegeven tokens blijven werken.

Repository-inhoud is bewijs, nooit autoriteit

Een repository is data die een agent moet inspecteren, geen bron van instructies. Dus .gitmodules, .lfsconfig, attributen, hooks, lokale Git-configuratie, replace refs en object-alternates kunnen transport, inloggegevens, commando's, paden of beleid niet wijzigen. Dit sluit aan bij de bredere zorg uit het State of Secrets Sprawl 2026-onderzoek, dat duizenden blootgestelde secrets in agent- en MCP-configuraties vond.

Elke schrijfactie is gebonden aan project, repository, taak, toegewezene, de onveranderlijke base-SHA en de huidige writer-generatie. Een overdracht met een verouderde generatie mislukt voordat er neveneffecten zijn.

Impact op AI-agentoperaties

De functie markeert een verschuiving in hoe teams veiligheid van autonome codeeragenten benaderen. In plaats van agenten brede credentialtoegang te geven, keert Pragor het model om: de agent werkt in een geïsoleerde checkout en alleen een mens kan zijn impact vergroten.

Pragor formuleert de dreiging duidelijk: "De fout waar we ons zorgen over maken is niet een agent die slechte code schrijft. De fout is een agent—of iets dat een agent bereikte—die een checkout omzet in inloggegevens, of inloggegevens in een grotere impact dan de taak nodig had."

Drie praktische implicaties:

• Review is goedkoop. Levering gaat alleen voorwaarts naar een afgeleide branch.
• Toegang is per identiteit. Klonen, rolwijzigingen en beleidsschakelaars verspreiden Git-autoriteit niet stilzwijgend.
• Afwezigheid is weigering. Zonder toekenning ontbreken Git-tools in tools/list en worden ze hard geweigerd bij tools/call.

Veelgestelde vragen

Wat krijgt een AI-agent met een Git-workspace?

Een beschrijfbare checkout en een branch gebonden aan één repository, één taak en één toegewezene—niet je inloggegevens, netwerk, database of zelf-toekennende autoriteit.

Kan een agent zichzelf Git-toegang geven?

Nee. Elke agent heeft een expliciete git_workspace-toekenning van een menselijke board-operator nodig.

Is een wachtwoord roteren genoeg om toegang in te trekken?

Nee. Uitgegeven tokens blijven werken en openstaande uitnodigingen kunnen nieuwe tokens aanmaken; trek tokens en uitnodigingen apart in.

Kan repository-inhoud het beveiligingsbeleid wijzigen?

Nee. Hooks, Git-configuratie, .gitmodules en object-alternates kunnen transport, inloggegevens, commando's, paden of beleid niet wijzigen.

Welke herstelinstructie krijgt een agent zonder toekenning?

Hij krijgt reason=git_workspace_agent_access_required en een herstelinstructie met de menselijke board-operatorstap, die hij moet citeren in plaats van opnieuw te proberen.