GitHub Copilot app dostáva lokálny sandbox pre súbory, sieť aj prihlasovacie údaje

Agent dostáva hranice priamo na počítači

GitHub rozšíril aplikáciu Copilot o lokálny sandbox, ktorý má zmenšiť dosah nechcených alebo nesprávne vyhodnotených príkazov agentického asistenta. Ochrana sa nastavuje samostatne pre každý projekt a vzťahuje sa na relácie pracujúce s lokálnym repozitárom alebo pracovným stromom. Správca či vývojár môže určiť, ku ktorým priečinkom má relácia dodatočný prístup na čítanie a zápis, ktoré cesty smie iba čítať a ktoré majú zostať úplne zakázané. Samostatne sa riadi odchádzajúca komunikácia do internetu a lokálnej siete, ako aj prístup ku Git povereniam pre autentifikované operácie cez HTTPS a k povereniam GitHub CLI. Funkcia je zatiaľ vo verejnej ukážke, GitHub ju predvolene nezapína a upozorňuje, že jej správanie sa ešte môže meniť.

Dôležitým detailom je spôsob zlyhania. Ak operačný systém nedokáže požadovanú politiku vynútiť, sandboxovaný shell sa podľa GitHubu nespustí. Aplikácia teda nemá potichu pokračovať s plnými oprávneniami, čo by vytváralo falošný pocit bezpečia. Ide o princíp „fail closed“: nemožnosť uplatniť obmedzenie ukončí operáciu namiesto toho, aby sa ochrana obišla. Projektová politika navyše predstavuje iba rozsah, ktorý si relácia žiada. Podnikové pravidlá môžu výsledné oprávnenia ešte zúžiť, takže lokálny používateľ nemôže nastavením projektu prekonať centrálne obmedzenia organizácie.

Sandbox sa aktivuje v nastaveniach konkrétneho projektu voľbou „Sandbox new sessions“. Zmena platí pre nové relácie, nie spätne pre tie, ktoré už bežia. Úpravy pravidiel pre súborový systém, sieť a poverenia sa prejavia po založení novej relácie alebo po reštarte existujúcej. Pre práve otvorenú lokálnu reláciu ponúka aplikácia príkaz /sandbox on; ten mení iba danú reláciu a nemení projektové predvolené nastavenie. GitHub zároveň oddeľuje konfiguráciu Copilot app od nastavení Copilot CLI. Ochrana z aplikácie sa nevzťahuje na cloudové sandboxy ani na relácie bežiace na vzdialenom hostiteľovi.

Prečo je izolácia pri kódovacích agentoch podstatná

Klasický četovací asistent väčšinou navrhuje text, ktorý používateľ najprv prečíta. Kódovací agent však môže spúšťať shell, meniť desiatky súborov, inštalovať závislosti, volať sieťové služby alebo vykonať príkazy odvodené z obsahu repozitára. Chybný príkaz preto nemusí znamenať iba nepoužiteľnú odpoveď. Môže poškodiť pracovný strom, prečítať súbor mimo projektu, odoslať citlivé údaje alebo použiť existujúcu autentifikáciu na operáciu, ktorú používateľ nezamýšľal. Samotná kvalita modelu tento problém neodstraňuje, pretože riziko vzniká aj z nejednoznačného zadania, chybného nástroja, kompromitovanej závislosti či škodlivého textu vloženého do dokumentácie a issue.

Podobný bezpečnostný smer vidno aj pri konkurenčných nástrojoch. Dokumentácia Claude Code opisuje sandboxovanie príkazov s izoláciou súborového systému a siete, hranicu pracovného adresára a režim, v ktorom citlivejšie operácie vyžadujú schválenie. Anthropic zároveň výslovne upozorňuje na prompt injection a na riziko sieťových príkazov, ktoré načítajú nedôveryhodný obsah. Nejde o nezávislé potvrdenie konkrétnej implementácie GitHubu, ale o dôležitý kontext: výrobcovia agentických vývojárskych nástrojov sa zhodujú, že modelové pravidlá a dialógové potvrdenia treba doplniť technicky vynútiteľnými hranicami.

GitHub vo svojom návrhu oddeľuje tri oblasti, ktoré majú rozdielny profil rizika. Súborové pravidlá chránia zdrojový kód, osobné adresáre a lokálne konfiguračné súbory. Sieťová politika znižuje priestor na sťahovanie neovereného obsahu alebo odoslanie údajov mimo počítača. Oddelená správa poverení rieši situáciu, keď by agent síce videl iba projekt, no mohol by zdediť silnú identitu používateľa. Takéto vrstvenie je praktickejšie než jedno globálne povolenie „agent môže používať terminál“, pretože tím môže sprístupniť presne tie schopnosti, ktoré úloha potrebuje.

Čo to mení pre vývojárske tímy

Pre lokálny vývoj je rozumným východiskom povoliť zápis iba do pracovného stromu a do nevyhnutných adresárov pre zostavenie, pričom domovský priečinok, úložiská kľúčov a konfigurácie ostatných projektov zostanú zakázané. Prístup na internet nemusí byť otvorený pri každej úlohe. Refaktoring existujúceho modulu alebo spúšťanie lokálnych testov môže fungovať bez siete, zatiaľ čo inštalácia balíkov bude vyžadovať presnejšie povolenie. Git a GitHub CLI poverenia majú zmysel až vtedy, keď relácia skutočne potrebuje vykonať autentifikovanú operáciu. Princíp najmenších oprávnení tak možno uplatniť na úroveň projektu a typu práce, nie iba na používateľský účet.

Pre firmy je podstatné, že projektová konfigurácia môže byť podriadená prísnejšej podnikovej politike. To vytvára priestor na štandardné profily pre citlivé repozitáre, regulované prostredia alebo projekty so zákazníckymi dátami. Sandbox však nenahrádza kontrolu zmien, ochranu vetiev, správu tajomstiev, revíziu pull requestov ani monitorovanie. Obmedzí následky niektorých chybných akcií, no nedokáže zaručiť, že agent vytvorí bezpečný kód alebo že povolená sieťová destinácia je dôveryhodná. Tím musí naďalej kontrolovať diff, spúšťať testy a používať krátkodobé poverenia s minimálnym rozsahom.

Slovenské vývojárske tímy často pracujú na jednom počítači s viacerými klientskymi repozitármi, VPN prístupmi a uloženými cloudovými profilmi. Práve v takom prostredí je projektová izolácia užitočnejšia než všeobecné upozornenie pred spustením príkazu. Dobre nastavený zákaz čítania susedných adresárov môže zabrániť tomu, aby sa obsah jedného zákazníckeho projektu náhodne dostal do kontextu druhého. Obmedzenie lokálnej siete môže zase chrániť interné administrátorské rozhrania, ktoré sú z pracovnej stanice dostupné bez ďalšej autentifikácie. Zavedenie funkcie by preto malo začať inventúrou ciest, poverení a sieťových služieb, nie automatickým povolením všetkých výnimiek.

Otázky, ktoré verejná ukážka ešte nezodpovedá

GitHub v krátkom oznámení nepublikoval merania odolnosti sandboxu, podrobný model hrozieb ani úplný zoznam rozdielov medzi podporovanými operačnými systémami. Nevieme preto, aké obmedzenia bude mať izolácia pri špecifických build nástrojoch, kontajneroch, symbolických odkazoch alebo procesoch, ktoré komunikujú cez lokálne sockety. Rovnako bude dôležité sledovať, ako zrozumiteľne aplikácia vysvetľuje zamietnuté operácie. Ak budú vývojári pri bežnej práci narážať na nejasné chyby, môžu pravidlá postupne uvoľňovať až do bodu, keď ochrana stratí význam.

Verejná ukážka je napriek týmto neistotám významný posun. Lokálny agent už nie je iba návrhový nástroj, ale proces schopný konať s identitou a prístupom používateľa. GitHub preto presúva časť bezpečnostného rozhodovania z konverzačného rozhrania do vynútiteľnej politiky operačného prostredia. Praktická hodnota bude závisieť od kvality implementácie a od toho, či tímy vytvoria úzke, udržateľné profily oprávnení. Základná architektúra však smeruje správne: agent má dostať iba potrebné súbory, potrebnú sieť a potrebné poverenia, pričom nemožnosť ochranu vynútiť má znamenať zastavenie relácie.