Pri práci so softvérom, agentmi umelej inteligencie alebo súbormi stiahnutými z internetu je jedným z najčastejších obáv, že sa vám niečo pokazí vo vašom systéme, že vás napadnú škodlivým softvérom alebo že vám takmer bez uvedomenia uniknú citlivé údaje. Nemusíte byť paranoidní: jediné neúspešné spustenie môže vymazať databázu, zničiť nasadenie alebo zaviesť do vášho systému chybu.
Dobrou správou je, že dnes existuje niekoľko spôsobov, ako vytvoriť izolované prostredie, v ktorom môžete testovať veci bez rizika poškodenia , a mnohé z nich sú integrované do samotného operačného systému alebo do platforiem určených pre kódových agentov. Toto nazývame „sandboxing“: spúšťanie kódu vo vnútri akejsi kontrolovanej bubliny, takže aj keď sa niečo pokazí alebo je to škodlivé, poškodenie je obmedzené.
Čo je manuálny sandbox bez dodatočného softvéru?
V oblasti bezpečnosti a vývoja znamená hovoriť o sandboxe presné definovanie toho, k čomu má program alebo agent prístup počas behu . Nejde len o „spúšťanie niekde inde“, ale o definovanie jasných hraníc: aké súbory môže vidieť, aké procesy môže spustiť, či má prístup k sieti, aké prihlasovacie údaje môže použiť, ako dlho toto prostredie trvá a čo sa stane s jeho stavom po ukončení.
Slovné spojenia „manuálny“ a „bez dodatočného softvéru“ sú zavádzajúce. V mnohých prípadoch sa môžete spoľahnúť na funkcie, ktoré sú už súčasťou vášho operačného systému alebo vašej vlastnej vývojovej platformy , ako napríklad Windows Sandbox, Linuxové primitívy (Landlock, seccomp) alebo mechanizmy macOS. Nemusíte inštalovať kompletný virtualizačný balík, ale musíte sa naučiť, ako tieto vstavané mechanizmy aktivovať a spravovať , aby fungovali ako bariéra medzi kódom, ktorý chcete testovať, a vaším skutočným počítačom.
Prečo kódoví agenti potrebujú izolované prostredia?
Moderní kódovací agenti už nie sú len asistenti pripomínajúci chat, ktorí navrhujú úryvky kódu: sú to behové prostredia prepojené s jazykovým modelom . Môžu čítať váš repozitár, upravovať súbory, vykonávať terminálové príkazy, inštalovať balíky, vytvárať kontajnery , komunikovať s externými API a dokonca otvárať relácie prehliadača.
Platformy ako Claude Code, niektorí „hlboko riadení agenti“ od LangChainu a špecifické sandboxy distribuované spoločnosťou Docker a ďalšími nástrojmi explicitne opisujú, ako títo agenti fungujú na reálnych súborových systémoch, spúšťajú vlákna a delegujú úlohy špecializovaným subagentom . Inými slovami, sú dosť podobní juniorskému vývojárovi s prístupom k vašim nástrojom… len automatizované a veľmi rýchle.
V tejto súvislosti sa hlavná bezpečnostná otázka presúva z „Reaguje správne na výzvu?“ na „Aký je jeho rozsah, keď urobí chybu, je nesprávne zarovnaný alebo bol upravený?“ Ak model dokáže napríklad spustiť pytest, inštalovať balíčky npm, spravovať vetvy alebo kontrolovať zlyhanie kompilácie, je len pár krokov od dotyku skriptov nasadenia, úpravy hookov Git alebo exfiltrácie tajomstiev do vzdialenej služby.
Jednoduchou odpoveďou je často vyžadovať ľudské schválenie pre každý príkaz. To pomáha, ale má to opakujúci sa problém: únavu zo schvaľovania . V prostrediach, kde inžinieri spúšťajú mnoho agentov alebo pracovných postupov paralelne, obrovský objem žiadostí znamená, že takmer všetko je nakoniec schválené bez dôkladného prečítania. Keď je viac ako 90 % žiadostí o povolenie schválených automaticky, tento mechanizmus prestáva byť skutočnou bezpečnostnou kontrolou a stáva sa čistou ceremóniou.
Preto sú sandboxy také dôležité: nerobia model neomylným ani neopravujú vkladanie inštrukcií , ale znižujú „polomer výbuchu“ jeho chýb. Ak umelá inteligencia pokazí veci alebo sa niekomu podarí uniesť jej inštrukcie, poškodenie sa obmedzí na izolované prostredie namiesto toho, aby sa rozšírilo priamo do vášho produkčného systému alebo notebooku.
Hlavné obmedzenia sandboxu kódového agenta
Seriózny sandbox pre kódovacích agentov sa spolieha na niekoľko typov hraníc, nielen na „iný adresár“ alebo „iný kontajner“. Každá z nich pokrýva iný aspekt rizika a ich pochopenie je nevyhnutné pre efektívne manuálne sandboxovanie s vašimi existujúcimi zdrojmi.
Hranica súborového systému
Prvým krokom je rozhodnúť sa, ktorý adresárový strom môže agent vidieť a upravovať . V správne nastavenom sandboxe by mal byť agent schopný čítať a zapisovať iba do pracovného priestoru alebo zväzkov, ktoré pre neho explicitne pripojíte. Zvyšok systému (domovský adresár používateľa, systémové cesty, iné projekty) by mal byť mimo jeho dosahu.
Rámce agentov a sandbox platformy to jasne ukazujú: sandbox je bariéra, ktorá bráni prístupu k súborom hostiteľa nad rámec zdieľaných súborov . V modeloch založených na microVM je pravidlo ešte prísnejšie: hranicu medzi virtuálnym strojom a hostiteľom prekračuje iba adresár, ktorý pripojíte (často s prístupom na čítanie aj zápis). Všetko ostatné zostáva neprístupné, pokiaľ ho neotvoríte.
Hranica procesu a jadro
Druhým kľúčovým obmedzením je to, čo agent vidí na úrovni procesov a jadra. Ak v izolovanom prostredí inštaluje služby, spúšťa kontajnery alebo spúšťa vlákna , všetky tieto akcie musia zostať zapuzdrené bez zdieľania procesov alebo holého jadra s hostiteľom.
Mnohé robustné implementácie sandboxu sa spoliehajú na mikroVM alebo ľahké virtuálne stroje s vlastným jadrom Linuxu, posilnené technikami seccomp, cgroups, menných priestorov a jail. Iné používajú vrstvy ako gVisor alebo Kata Containers na vloženie virtualizačnej alebo emulačnej vrstvy medzi izolovaný proces a jadro uzla. Základná myšlienka: ak niekto niečo vo vnútri zneužije, skok na hostiteľa je oveľa ťažší ako v jednoduchom kontajneri so zdieľaným jadrom.
Hranica siete
Agenti kódu sú často veľmi „hladní po sieti“: chcú inštalovať závislosti, konzultovať dokumentáciu, volať rozhrania LLM API, pristupovať k vzdialeným repozitárom alebo dokonca prehliadať web. Bez jasnej politiky sa „izolované“ prostredie môže stať fantastickým tunelom na únik údajov.
Preto čoraz viac platforiem implementuje predvolenú politiku odmietania odchádzajúcej prevádzky : HTTP/HTTPS sú blokované okrem určitých prípadov, TCP/UDP/ICMP sú obmedzené a, čo je veľmi dôležité, prístup k súkromným rozsahom a lokálnym adresám je zakázaný. Komunikácia je povolená iba s hostiteľmi alebo doménami explicitne uvedenými na zozname povolených adries a často prostredníctvom proxy servera ovládaného hostiteľom.
Limit poverení
Nemá veľký význam mať agenta uzamknutého, ak vo svojej klietke dokáže čítať vaše API kľúče, tokeny nasadenia alebo tajné údaje databázy. Moderný dizajn mnohých sandboxov zahŕňa nikdy nevkladanie surových tajných údajov do izolovaného prostredia , ale namiesto toho proxy na hostiteľovi pridáva poverenia do hlavičiek HTTP požiadaviek, ktoré chce sandbox odoslať.
Pri tomto prístupe proces v sandboxe používa poverenia, ale nikdy ich nevidí . To výrazne znižuje dopad potenciálneho únosu agenta. Avšak v momente, keď uložíte kľúč do súboru alebo premennej prostredia v sandboxe, táto výhoda mizne: model ho potom môže priamo prečítať a akákoľvek inštrukčná injekcia mu môže dať pokyn na jeho filtrovanie.
Hranica a stav životného cyklu
Nakoniec je tu časové obmedzenie: čo sa zachová a čo sa zničí, keď sa prostredie zastaví . Agenti nie sú procesy viazané na určitý čas: čítajú, kompilujú, ladia, otvárajú viacero hypotéz, niektoré opúšťajú, iné obnovujú... To si vyžaduje behové prostredie, ktoré inteligentne riadi stav: rýchle spustenie, pozastavenie, snímky, vetvenie a bezpečné odstránenie.
Niektoré platformy ponúkajú snímky v pamäti, skupiny predhriatych prostredí a funkcie vetvenia z konkrétneho stavu (napríklad už autentifikovaný prehliadač alebo čiastočne vyriešený graf závislostí). To predstavuje zásadný rozdiel medzi použiteľným agentom – agentom, ktorý dokáže interaktívne iterovať – a agentom, ktorému trvá večnosť, kým to isté nastavenie znova a znova zopakuje.
Implementácie sandboxu v systémoch macOS, Linux a Windows
Okrem komerčných produktov sa mnoho tímov rozhodlo využiť existujúce izolačné primitívy v operačných systémoch na vytvorenie vlastných sandboxov kódových agentov bez nutnosti pridávania náročnejších vrstiev. Kľúčom je pochopiť, čo každá platforma prináša.
Sandboxing v systéme macOS: Profil bezpečnostného pásu a dynamické profily
V systéme macOS bolo vyhodnotených niekoľko modelov: App Sandbox, kontajnery, virtuálne počítače a Seatbelt. Prvé možnosti majú pre vývojové prostredie značné nevýhody: App Sandbox vyžaduje podpísanie každého binárneho súboru, ktorý by agent mohol spustiť, a dedí dôveryhodnosť podpisu, čo otvára vektory zneužitia, ak samotný agent generuje alebo upravuje binárne súbory; kontajnery sú obmedzené na ekosystém Linuxu; tradičné virtuálne počítače pridávajú značnú latenciu bootovania a spotrebu pamäte.
Praktickou alternatívou bolo spoľahnúť sa na Seatbelt, prístupný cez sandbox-exec . Hoci ho Apple už roky označuje za zastaraný, stále ho používajú kritické aplikácie ako Chrome . Umožňuje vykonávanie príkazov v rámci profilu sandbox, ktorý obmedzuje správanie celého stromu potomkov procesov.
Tento profil definuje oprávnenia s veľkou granularitou: dokáže filtrovať špecifické systémové volania a operácie čítania alebo zápisu na špecifických súboroch a adresároch pomocou jedinečného jazyka politík. Niektoré implementácie generujú túto politiku dynamicky za behu, kombinujúc konfiguráciu pracovného priestoru, politiky správcu a súbory ignorovania používateľov, takže agent má priestor na manévrovanie bez prístupu do potenciálne nebezpečných oblastí.
Sandboxing v Linuxe: Landlock a seccomp
Linux ponúka väčšiu flexibilitu aj viac práce: jadro sprístupňuje primitívy ako Landlock a seccomp , ale je zodpovednosťou používateľského priestoru skombinovať ich do súdržného a spravovateľného sandboxu.
Namiesto spoliehania sa výlučne na externé projekty sa niektoré tímy rozhodnú použiť seccomp priamo na blokovanie systémových volaní považovaných za nebezpečné a Landlock na obmedzenie prístupu k súborovému systému. Bežný prístup zahŕňa pripojenie pracovného priestoru používateľa na prekrytie súborového systému a nahradenie súborov označených ako ignorované špeciálnymi kópiami chránenými Landlockom , aby izolovaný proces nemohol čítať ani upravovať nič, čo chcete skryť.
Najpomalšou časťou tohto prístupu je zvyčajne vyhľadanie a opätovné pripojenie všetkých týchto súborov, pretože Linux neponúka jednoduchý spôsob, ako nájsť úplnú cestu k súboru vo filtri seccomp-bpf . Výsledkom je však pomerne prepracovaný sandbox: agent môže pracovať so svojím projektovým stromom, zatiaľ čo zakázané cesty sú de facto vylúčené z jeho prostredia.
Sandboxing vo Windowse: spoliehanie sa na WSL2
V systéme Windows je príbeh iný. Vytvorenie univerzálneho natívneho sandboxu je oveľa komplikovanejšie, pretože mnohé existujúce izolačné primitívy sú určené pre prehliadače alebo iný veľmi špecifický softvér a nie sú dobre kompatibilné s všestrannými vývojovými nástrojmi.
Praktickým riešením je spustiť Linuxový sandbox v rámci WSL2 . Týmto spôsobom môžete opätovne použiť izolačné nástroje Linuxu (Landlock, seccomp, menné priestory atď.) na virtualizovanom základe, ktorý izoluje vývojovú reláciu od hostiteľa Windows. Súbežne prebieha práca so spoločnosťou Microsoft na sprístupnení nových primitív, ktoré nakoniec umožnia natívnejší sandbox pre vývojové nástroje.
Windows Sandbox: izolovaný priestor integrovaný do systému
Pre tých, ktorí používajú edície Windows 10 alebo 11 Pro, Enterprise alebo Education, existuje obzvlášť zaujímavý nástroj: Windows Sandbox . Je to ľahký virtuálny stroj integrovaný do samotného systému, ktorý umožňuje spúšťať nedôveryhodné aplikácie alebo podozrivé súbory v jednorazovom prostredí.
Myšlienka je jednoduchá: otvorenie Windows Sandboxu spustí dočasnú, čistú pracovnú plochu systému Windows, rovnako ako nová inštalácia . Všetko, čo doň skopírujete alebo nainštalujete – programy, dokumenty, skripty – existuje iba v danej inštancii. Ak zatvoríte okno, prostredie sa zničí: softvér, súbory a stav systému sa zahodia a pri ďalšom otvorení systému Windows začnete odznova.
Kľúčové vlastnosti Windows Sandboxu
Táto funkcia má niekoľko veľmi užitočných vlastností pre manuálne sandboxovanie bez spoliehania sa na nástroje tretích strán:
- Súčasť systému WindowsVšetko, čo potrebujete, je už zahrnuté v kompatibilných edíciách (Pro, Enterprise, Education). Nemusíte sťahovať obrazy ani spravovať externé virtuálne počítače.
- Jednorazové a nedotknutéKaždé spustenie je rovnako čisté ako nová inštalácia systému Windows. Po zatvorení prostredia sa nič, čo v ňom urobíte, neuloží do vášho zariadenia.
- Bezpečný už od návrhuSpolieha sa na hardvérovo podporovanú virtualizáciu (Hyper-V) na izoláciu sandboxového jadra od hostiteľského jadra. Na oddelenie týchto dvoch svetov používa hypervízor od spoločnosti Microsoft.
- účinnýSpustenie je rýchle, v priebehu niekoľkých sekúnd, s inteligentnou správou pamäte a podporou virtuálnych GPU, pričom využíva menej zdrojov ako tradičný virtuálny počítač.
Technicky sa správa ako malý, jednorazový virtuálny stroj so systémom Windows , ktorý je perfektný na testovanie inštalátorov, návštevu pochybných webových stránok alebo otváranie e-mailových príloh, ktorým nedôverujete, že sa spustia na vašom skutočnom systéme.
Praktické scenáre používania Windows Sandboxu
Existuje niekoľko typických scenárov, v ktorých sa Windows Sandbox osvedčil ako jednoduché manuálne riešenie sandboxu:
- Vyskúšajte neznámy softvérKeď si stiahnete aplikáciu alebo spustiteľný súbor z internetu a nie ste si istí jeho pôvodom, môžete ho najprv nainštalovať v prostredí Windows Sandbox a zistiť, ako sa bude správať bez rizika pre váš počítač.
- Bezpečnejšie prehliadanie webu: pre Návšteva potenciálne nebezpečných webových stránok, stránok so škodlivým softvérom alebo phishingových stránokPrehliadač môžete otvoriť v rámci sandboxu. Ak sa niečo pokazí, jednoduché zatvorenie okna odstráni všetky stopy.
- Otváranie nedôveryhodných príloh a súborovAk dostanete podozrivú prílohu alebo ZIP súbor, ktorý nevzbudzuje dôveru, skopírujete ho do sandboxu, otvoríte ho tam a po kontrole sa rozhodnete, či sa oplatí niečo extrahovať do vášho skutočného systému.
- Ukážky a testy špecifických nástrojovJe ideálny na vytváranie softvérových ukážok, testovanie ukážkových verzií, rozšírení alebo doplnkov bez toho, aby zahlcoval vašu hlavnú inštaláciu.
- Udržiavať viacero samostatných vývojových prostredíNapríklad môžete vytvoriť samostatné, izolované priestory pre každý jazykový zásobník alebo verziu sandbox pre každú verziu Pythonu a jej závislostiaby experimenty nenarúšali vaše stabilné prostredie.
Požiadavky a licencie na používanie Windows Sandboxu
Nie každý môže používať Windows Sandbox, ale je už dostupný v mnohých profesionálnych prostrediach. Na jeho povolenie vo vašom počítači potrebujete:
- Kompatibilná edícia systému WindowsWindows 10/11 Pro, Enterprise, Pro Education/SE alebo Education. Verzia Home nie je podporovaná.
- Podpora virtualizácieJe nevyhnutné mať virtualizačné funkcie v systéme BIOS/UEFI (Intel VT-x, AMD-V alebo ekvivalent).
- Minimálne zdrojeaspoň 4 GB RAM (odporúča sa 8 GB), 1 GB voľného miesta na disku — najlepšie SSD — a minimálne 2 jadrá CPU (ideálne 4 s hyperthreadingom).
- aktualizovaný operačný systémPočnúc určitými zostavami (napríklad zostava Windowsu 10 18305 a novšia a moderné zostavy Windowsu 11). V ARM64 sa kompatibilita objavila s novšími zostavami.
Pokiaľ ide o licencie, edície Pro, Enterprise a Education zahŕňajú právo používať Windows Sandbox bez nutnosti platiť za ďalšie licencie virtualizačného softvéru. Stačí ho aktivovať a môžete začať.
Ako aktivovať Windows Sandbox bez ďalších nástrojov
Na jeho spustenie a prevádzku nepotrebujete nič okrem samotného systému:
- Otvorte ponuku Štart a vyhľadajte možnosť "Zapnite alebo vypnite funkcie systému Windows".
- V zozname funkcií označte Pieskovisko systému Windows a potvrďte.
- Po zobrazení výzvy reštartujte počítač.
- Po reštarte vyhľadajte v ponuke Štart „Windows Sandbox“ a spustite ho.
Ak uprednostňujete technickejší prístup, môžete ho povoliť aj pomocou PowerShellu príkazom `Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online` , za predpokladu, že máte oprávnenia správcu. Po povolení bude sandbox vždy k dispozícii, kedykoľvek budete potrebovať tento bezpečný „druhý počítač“.
Konfiguračné a prispôsobovacie súbory
Sandbox systému Windows podporuje jednoduché konfiguračné súbory, ktoré vám umožňujú prispôsobiť určité parametre prostredia : napríklad pripojenie hostiteľských priečinkov ako iba na čítanie alebo čítanie aj zápis, vypnutie siete, spúšťanie skriptov pri štarte atď. Tieto súbory sú k dispozícii od špecifických zostavení systému Windows 10 a 11.
V praxi vám táto funkcia pomáha vytvárať „recepty“ v sandboxe: jedna konfigurácia so zakázanou sieťou na otváranie malvéru , druhá s priečinkom projektu pripojeným v režime iba na čítanie na kontrolu súborov alebo konfigurácia zameraná na testovanie softvéru s určitými nástrojmi predinštalovanými v základnom obraze.
Ako naučiť agentov s umelou inteligenciou správne používať sandbox
Sandbox je skutočne efektívny iba vtedy, ak samotný kódový agent rozumie prostrediu, v ktorom pracuje, a vie, kedy môže fungovať voľne a kedy potrebuje požiadať o ďalšie povolenia alebo ľudskú pomoc.
Aby sa to dosiahlo, mnohé platformy museli dôkladne prepracovať infraštruktúru, ktorá popisuje nástroje modelu. Napríklad aktualizovali popisy nástrojov shellu, aby jasne vysvetlili:
- Aké obmedzenia ukladá sandbox? (prístup k súborovému systému, git, sieť).
- Ako môže agent požiadať o aktualizáciu povolení keď niečo zlyhá kvôli nedostatku privilégií.
- Ktoré typy príkazov budú s najväčšou pravdepodobnosťou blokované?
Tieto zmeny nie vždy fungujú dokonale hneď na prvýkrát: zvyčajne si vyžadujú rozsiahle manuálne testovanie reálnych postupov nasadenia , analýzu toho, kde sa očakávania modelu pokazia, a úpravu výziev a pokynov. Meraním správania s a bez sandboxu v interných benchmarkoch sa identifikujú vzorce zlyhania, ako napríklad agenti, ktorí opakovane vykonávajú ten istý príkaz, ktorý sandbox blokuje, namiesto toho, aby pochopili, že potrebujú požiadať o ďalšie povolenia alebo upraviť svoju stratégiu.
Praktickým vylepšením je zobrazenie konkrétneho dôvodu blokovania vynúteného sandboxom vo výsledkoch nástroja a dokonca explicitné navrhnutie, aby agent v prípade potreby požiadal o zvýšené privilégiá. Táto malá rada drasticky znižuje počet slepých opakovaní a zlepšuje zotavenie z chýb súvisiacich s sandboxom, a to ako v offline testovaní, tak aj v produkčnom prostredí.
Aby sa zabezpečilo, že sandbox nezhorší používateľskú skúsenosť, mnoho spoločností sa rozhodlo pre postupné zavádzanie , pričom pred jeho predvoleným povolením zhromažďujú internú a externú spätnú väzbu. Údaje sú zvyčajne jasné: značná časť požiadaviek (napríklad približne tretina) sa nakoniec vykoná v rámci sandboxu na kompatibilných platformách, pričom sa výrazne skráti čas strávený žiadaním o schválenie aj manuálnou kontrolou.
Modely izolácie a praktické bezpečnostné lekcie
V praxi neexistuje jediný „dokonalý sandbox“. Existujú dôležité rozdiely medzi zdieľaným kontajnerom jadra, sandboxom typu gVisor, microVM a plnohodnotným VM . Toto rozlíšenie je dôležité, keď hovoríme o tom, či agentovi umožníme spúšťať Docker, inštalovať ľubovoľné balíčky alebo dokonca spúšťať zložité prehliadače a vlákna.
Historické bezpečnostné incidenty zdôrazňujú dôležitosť správneho výberu: zraniteľnosti ako CVE-2019-5736 alebo CVE-2024-21626 , ktoré umožňovali prechod z kontajnera na hostiteľa alebo manipuláciu s binárnymi súbormi systému, ukazujú, že keď je limitom dôvery beh kontajnera na jadre hostiteľa, závažná chyba môže celú bariéru zničiť.
Toto sa stáva ešte problematickejším u kódovacích agentov, pretože často spúšťajú nedôveryhodný kompilačný kód, vytvárajú obrazy, inštalujú neauditované závislosti a vo všeobecnosti spracovávajú vysoko heterogénne vstupy. Okrem toho je tlak na „dať im viac moci“ silný: ak nemôžu spúšťať určité nástroje, často nedokážu dokončiť svoje úlohy.
Preto mnoho moderných návrhov sandboxov agentov má tendenciu posilňovať hranice pomocou mikrovirtuálnych strojov alebo odľahčených virtuálnych strojov , a to aj za cenu mierne zvýšenej zložitosti. To znižuje priamu závislosť od jadra hostiteľa a poskytuje ďalšiu vrstvu izolácie proti únikom kontajnerov. V prostrediach s viacerými nájomníkmi alebo pri rozsiahlom vykonávaní nedôveryhodného kódu zaujímajú gVisor alebo Kata Container strednú cestu, pričom vymieňajú kompatibilitu za väčšiu izoláciu.
Ľudské schválenia, politické schválenia a sandboxy: ako to všetko prepojiť
Jedným opakujúcim sa vzorcom je, že trvalé žiadosti o povolenia sa dobre neškálujú . V demo režime je v poriadku, ak agent pred prístupom k súboru požiada o povolenie. V produkčnom režime sa však s poloautonómnymi pracovnými postupmi a množstvom malých akcií model „kliknite OK pre všetko“ stáva sitom.
Zrelší prístup kombinuje niekoľko vrstiev:
- Silné pieskovisko na ochranu hostiteľa a vymedzenie prostredia vykonávania.
- Obmedzujúca sieťová politika ovládať, s ktorými koncovými bodmi môže agent komunikovať.
- Správa poverení cez proxyaby ich model používal bez toho, aby ich videl.
- Verzované konfigurácie na úrovni projektu (povolenia, hooky, externé servery), aby tímy mali v repozitári jeden zdroj pravdivých informácií.
- Subagenti iba na čítanie na prieskum a plánovanie, pričom písanie sa ponecháva na kontrolovanejšie prípady.
- Ľudské schválenie vyhradené pre skutočne chúlostivé činypublikovanie balíkov, zmeny infraštruktúry, rotácia tajných údajov alebo odosielanie do kritických vetiev.
Okrem toho je dôležité zvážiť kontrolný povrch, ktorý agentovi poskytujete prostredníctvom vlastných konfiguračných súborov, pluginov a zručností. Sprievodcovia od poskytovateľov ako OpenAI jasne varujú, že zverejnenie otvorených katalógov funkcií alebo umožnenie komukoľvek definovať výkonné inštrukcie v rámci repozitára môže viesť k únikom údajov alebo deštruktívnym akciám, ak sa útočníkovi podarí vložiť škodlivé inštrukcie do súborov README, problémov, dokumentácie alebo vzorových súborov.
V rozumnom dizajne sa sandbox nevníma ako kúzelnícky trik, ktorý cez noc vyrieši bezpečnosť, ale skôr ako ďalšia hranica v rámci architektúry, ktorá zahŕňa politiky, nezávislé overovanie, starostlivú správu tajomstiev a kontroly konfigurácie . Preto aj za predpokladu, že agent jedného dňa prečíta a bude poslúchať škodlivé pokyny, systém je navrhnutý tak, aby obmedzil dopad: žiadny priamy prístup ku kľúčom, žiadna otvorená sieť a žiadna možnosť tajne upravovať skripty, ktoré potom spustíte na svojom skutočnom počítači.
Nastavenie dobrého manuálneho sandboxu bez spoliehania sa na ďalší softvér v konečnom dôsledku spočíva v maximalizácii možností systémov macOS, Linux a Windows – profilov Seatbelt, Landlock a seccomp, Windows Sandbox a WSL2 – v kombinácii s jasnými sieťovými pravidlami, povereniami a správou životného cyklu prostredia. Pridajte k tomu vyškolených agentov, ktorí rozumejú týmto obmedzeniam, rozumné politiky a určitú disciplínu, pokiaľ ide o to, k čomu majú vo vašom pracovnom priestore prístup, a môžete testovať rizikový kód, nástroje a súbory s oveľa väčším pokojom na duši s vedomím, že ak sa niečo pokazí, problém zostane v sandboxe a neohrozí váš systém ani kritické údaje. Zdieľajte tieto informácie, aby sa o nich mohlo dozvedieť viac používateľov.