Při práci se softwarem, agenty umělé inteligence nebo soubory staženými z internetu je jednou z nejčastějších obav, že se vám něco v systému pokazí, že vás napadnou malware nebo že dojde k úniku citlivých dat téměř bez vědomí. Nemusíte být paranoidní: jediné neúspěšné spuštění může smazat databázi, zničit nasazení nebo zavést do systému chybu.
Dobrou zprávou je, že dnes existuje několik způsobů, jak vytvořit izolované prostředí, kde můžete testovat věci bez rizika poškození , a mnoho z nich je integrováno do samotného operačního systému nebo do platforem určených pro kódové agenty. Tomuto říkáme „sandboxing“: spouštění kódu uvnitř jakési kontrolované bubliny, takže i když se něco pokazí nebo je to škodlivé, poškození je pod kontrolou.
Co je manuální sandbox bez dalšího softwaru?
V oblasti bezpečnosti a vývoje znamená hovořit o sandboxu přesné definování toho, k čemu má program nebo agent během běhu přístup . Nejde jen o „běh někde jinde“, ale o definování jasných hranic: jaké soubory může vidět, jaké procesy může spustit, zda má přístup k síti, jaké přihlašovací údaje může používat, jak dlouho dané prostředí trvá a co se stane s jeho stavem po jeho ukončení.
Fráze „manuální“ a „bez dalšího softwaru“ je zavádějící. V mnoha případech se můžete spolehnout na funkce, které jsou již součástí vašeho operačního systému nebo vaší vlastní vývojové platformy , jako je Windows Sandbox, Linuxové primitivy (Landlock, seccomp) nebo mechanismy macOS. Nemusíte instalovat kompletní virtualizační sadu, ale musíte se naučit, jak tyto vestavěné mechanismy aktivovat a spravovat , aby fungovaly jako bariéra mezi kódem, který chcete testovat, a vaším skutečným počítačem.
Proč kódoví agenti potřebují izolovaná prostředí?
Moderní kódovací agenti už nejsou jen chatoví asistenti, kteří navrhují úryvky kódu: jsou to běhová prostředí propojená s jazykovým modelem . Mohou číst váš repozitář, upravovat soubory, spouštět terminálové příkazy, instalovat balíčky, vytvářet kontejnery , komunikovat s externími API a dokonce otevírat relace prohlížeče.
Platformy jako Claude Code, někteří „Deep Agents“ od LangChainu a specifické sandboxy distribuované Dockerem a dalšími nástroji explicitně popisují, jak tito agenti fungují na reálných souborových systémech, spouštějí vlákna a delegují úkoly specializovaným subagentům . Jinými slovy, jsou docela podobní juniornímu vývojáři s přístupem k vašim nástrojům… jen automatizovaným a velmi rychlým.
V této souvislosti se hlavní bezpečnostní otázka přesouvá z „Reaguje správně na výzvu?“ na „Jaký je jeho rozsah, když udělá chybu, je špatně zarovnaný nebo byl upraven?“. Pokud model například dokáže spustit pytest, instalovat balíčky npm, spravovat větve nebo kontrolovat selhání kompilace, je jen pár kroků od dotyku skriptů pro nasazení, úpravy hooků Git nebo exfiltrace tajných kódů do vzdálené služby.
Jednoduchá odpověď je často vyžadovat lidské schválení pro každý příkaz. To pomáhá, ale má to opakující se problém: únavu ze schvalování . V prostředích, kde inženýři spouštějí mnoho agentů nebo pracovních postupů paralelně, naprostý objem požadavků znamená, že téměř vše je nakonec schváleno bez pečlivého přečtení. Když je automaticky schváleno více než 90 % žádostí o oprávnění, tento mechanismus přestává být skutečnou bezpečnostní kontrolou a stává se pouhým ceremoniálem.
Proto jsou sandboxy tak důležité: nedělají model neomylným ani neopravují vkládání instrukcí , ale snižují „poloměr výbuchu“ jeho chyb. Pokud umělá inteligence selže nebo se někomu podaří unést její instrukce, poškození se uzavře v izolovaném prostředí, místo aby se rozšířilo přímo do vašeho produkčního systému nebo notebooku.
Hlavní omezení sandboxu kódového agenta
Seriózní sandbox pro kódovací agenty se spoléhá na několik typů hranic, nejen na „další adresář“ nebo „další kontejner“. Každá z nich pokrývá jiný aspekt rizika a jejich pochopení je nezbytné pro efektivní manuální sandboxování s vašimi stávajícími zdroji.
Hranice souborového systému
Prvním krokem je rozhodnout se, který adresářový strom agent může vidět a upravovat . Ve správně nastaveném sandboxu by měl být agent schopen číst a zapisovat pouze do pracovního prostoru nebo svazků, které pro něj explicitně připojíte. Zbytek systému (domovský adresář uživatele, systémové cesty, další projekty) by měl být mimo jeho dosah.
Agentové frameworky a sandbox platformy to dávají jasně najevo: sandbox je bariéra, která brání přístupu k souborům hostitele nad rámec sdílených souborů . V modelech založených na microVM je pravidlo ještě přísnější: hranici mezi virtuálním strojem a hostitelem překračuje pouze adresář, který připojujete (často s přístupem pro čtení i zápis). Všechno ostatní zůstává nepřístupné, dokud to neotevřete.
Hranice procesu a jádro
Druhým klíčovým omezením je to, co agent vidí na úrovni procesů a jádra. Pokud v izolovaném prostředí instaluje služby, spouští kontejnery nebo spouští vlákna , všechny tyto akce musí zůstat zapouzdřené, bez sdílení procesů nebo holého jádra s hostitelem.
Mnoho robustních implementací sandboxu se spoléhá na mikrovirtuální stroje nebo lehké virtuální stroje s vlastním linuxovým jádrem, posílené technikami seccomp, cgroups, jmenných prostorů a jail. Jiné používají vrstvy jako gVisor nebo Kata Containers k vložení virtualizační nebo emulační vrstvy mezi izolovaný proces a jádro uzlu. Základní myšlenka: pokud někdo zneužije něco uvnitř, skok na hostitele je mnohem obtížnější než v jednoduchém kontejneru se sdíleným jádrem.
Hranice sítě
Agenti kódu jsou často velmi „hladoví po síti“: chtějí instalovat závislosti, konzultovat dokumentaci, volat LLM API, přistupovat ke vzdáleným repozitářům nebo dokonce procházet web. Bez jasné politiky se „izolované“ prostředí může stát fantastickým tunelem pro únik dat.
Stále více platforem proto implementuje výchozí politiku odmítání odchozího provozu : HTTP/HTTPS jsou blokovány s výjimkou určitých případů, TCP/UDP/ICMP jsou omezeny a, co je velmi důležité, přístup k privátním rozsahům a lokálním adresám je zakázán. Komunikace je povolena pouze s hostiteli nebo doménami explicitně uvedenými na seznamu povolených adres a často prostřednictvím proxy serveru ovládaného hostitelem.
Limit přihlašovacích údajů
Nemá velký význam mít agenta uzamčeného, pokud uvnitř své klece může číst vaše API klíče, tokeny nasazení nebo tajné údaje databáze. Moderní design mnoha sandboxů spočívá v tom, že se do izolovaného prostředí nikdy nevkládají nezpracované tajné údaje , ale místo toho se na hostiteli nachází proxy server, který přidává přihlašovací údaje do záhlaví HTTP požadavků, které chce sandbox odeslat.
S tímto přístupem proces v sandboxu používá přihlašovací údaje, ale nikdy je nevidí . To výrazně snižuje dopad potenciálního únosu agenta. V okamžiku, kdy však uložíte klíč do souboru nebo proměnné prostředí v sandboxu, tato výhoda mizí: model jej pak může přímo číst a jakákoli instrukční injekce mu může dát pokyn k jeho filtrování.
Hranice a stav životního cyklu
A konečně je tu časové omezení: co se zachová a co se zničí, když se prostředí zastaví . Agenti nejsou procesy v čase: čtou, kompilují, ladí, otevírají více hypotéz, některé opouštějí, jiné obnovují… To vyžaduje běhové prostředí, které inteligentně spravuje stav: rychlé spuštění, pozastavení, snímky, větvení a bezpečné mazání.
Některé platformy nabízejí snímky v paměti, skupiny předpřipravených prostředí a větvení funkcí z určitého stavu (například již ověřený prohlížeč nebo částečně vyřešený graf závislostí). To představuje zásadní rozdíl mezi použitelným agentem – takovým, který dokáže interaktivně iterovat – a agentem, kterému trvá věčnost, než stejné nastavení opakuje znovu a znovu.
Implementace sandboxu v systémech macOS, Linux a Windows
Kromě komerčních produktů se mnoho týmů rozhodlo využít stávající izolační primitiva v operačních systémech k vytvoření vlastních sandboxů kódových agentů, aniž by muselo přidávat těžší vrstvy. Klíčem je pochopení toho, co každá platforma přináší.
Sandboxing v systému macOS: Profily bezpečnostních pásů a dynamické profily
V systému macOS bylo vyhodnoceno několik modelů: App Sandbox, kontejnery, virtuální počítače a Seatbelt. První možnosti mají pro vývojové prostředí značné nevýhody: App Sandbox vyžaduje podepsání každého binárního souboru, který by agent mohl spustit, a dědí důvěryhodnost podpisu, což otevírá možnosti zneužití, pokud agent sám generuje nebo upravuje binární soubory; kontejnery jsou omezeny na ekosystém Linuxu; tradiční virtuální počítače přidávají značnou latenci bootování a spotřebu paměti.
Praktickou alternativou bylo spoléhat se na Seatbelt, dostupný přes sandbox-exec . Ačkoli jej Apple již léta označuje za zastaralý, stále jej používají kritické aplikace, jako je Chrome . Umožňuje provádění příkazů v rámci sandboxového profilu, který omezuje chování celého stromu následných procesů.
Tento profil definuje oprávnění s velkou granularitou: dokáže filtrovat specifická systémová volání a operace čtení nebo zápisu na konkrétních souborech a adresářích pomocí jedinečného jazyka zásad. Některé implementace generují tyto zásady dynamicky za běhu a kombinují konfiguraci pracovního prostoru, zásady správce a soubory ignorování uživatelů, takže agent má prostor pro manévrování bez přístupu do potenciálně nebezpečných oblastí.
Sandboxing v Linuxu: Landlock a seccomp
Linux nabízí větší flexibilitu i více práce: jádro zpřístupňuje primitiva jako Landlock a seccomp , ale je odpovědností uživatelského prostoru je zkombinovat do souvislého a spravovatelného sandboxu.
Místo spoléhání se výhradně na externí projekty se některé týmy rozhodnou použít seccomp přímo k blokování systémových volání považovaných za nebezpečné a Landlock k omezení přístupu k souborovému systému. Běžný přístup zahrnuje připojení pracovního prostoru uživatele na překryv souborového systému a nahrazení souborů označených jako ignorované speciálními kopiemi chráněnými Landlockem , aby izolovaný proces nemohl číst ani upravovat nic, co chcete skrýt.
Nejpomalejší částí tohoto přístupu je obvykle nalezení a opětovné připojení všech těchto souborů, protože Linux nenabízí snadný způsob, jak najít úplnou cestu k souboru ve filtru seccomp-bpf . Výsledkem je však poměrně propracovaná sandboxová platforma: agent může pracovat se svým stromem projektu, zatímco zakázané cesty jsou de facto z jeho prostředí vyloučeny.
Sandboxing ve Windows: spoléhání se na WSL2
Ve Windows je situace jiná. Vytvoření univerzálního nativního sandboxu je mnohem složitější, protože mnoho existujících izolačních primitiv je navrženo pro prohlížeče nebo jiný velmi specifický software a dobře nekompatibilní s univerzálními vývojářskými nástroji.
Praktickým řešením je spustit Linuxový sandbox v rámci WSL2 . Tímto způsobem znovu použijete izolační nástroje Linuxu (Landlock, seccomp, namespaces atd.) na virtualizované bázi, která izoluje vývojovou relaci od hostitele Windows. Souběžně probíhá práce se společností Microsoft na zpřístupnění nových primitiv, které nakonec umožní nativní sandbox pro vývojové nástroje.
Sandbox ve Windows: izolovaný prostor integrovaný do systému
Pro ty, kteří používají edice Windows 10 nebo 11 Pro, Enterprise nebo Education, je k dispozici obzvláště zajímavý nástroj: Windows Sandbox . Jedná se o lehký virtuální stroj integrovaný do samotného systému, který umožňuje spouštět nedůvěryhodné aplikace nebo podezřelé soubory v jednorázovém prostředí.
Myšlenka je jednoduchá: otevření Windows Sandboxu spustí dočasnou, čistou plochu Windows, stejně jako nová instalace . Vše, co do něj zkopírujete nebo nainstalujete – programy, dokumenty, skripty – existuje pouze v dané instanci. Pokud okno zavřete, prostředí se zničí: software, soubory a stav systému se zahodí a při příštím otevření Windows začnete od nuly.
Klíčové vlastnosti Windows Sandboxu
Tato funkce nabízí několik velmi užitečných vlastností pro manuální sandboxování bez nutnosti spoléhat se na nástroje třetích stran:
- Součást systému WindowsVše, co potřebujete, je již zahrnuto v kompatibilních edicích (Pro, Enterprise, Education). Nemusíte stahovat obrazy ani spravovat externí virtuální počítače.
- Jednorázové a bezchybnéKaždé spuštění je stejně čisté jako nová instalace Windows. Nic, co uvnitř děláte, se po zavření prostředí neuloží do vašeho zařízení.
- Bezpečný designSpoléhá na hardwarově podporovanou virtualizaci (Hyper-V) k izolaci sandboxového jádra od hostitelského jádra. K oddělení těchto dvou světů používá hypervizor od společnosti Microsoft.
- EfektivníSpuštění je rychlé, během několika sekund, s inteligentní správou paměti a podporou virtuálních GPU, spotřebovává méně zdrojů než tradiční virtuální počítač.
Technicky se chová jako malý, jednorázový virtuální stroj s Windows , perfektně vhodný pro testování instalačních programů, návštěvu pochybných webových stránek nebo otevírání e-mailových příloh, u kterých nevěříte, že by se mohly spustit na vašem skutečném systému.
Praktické scénáře pro použití Windows Sandboxu
Existuje několik typických scénářů, kdy se Windows Sandbox osvědčil jako jednoduché manuální řešení sandboxu:
- Zkuste neznámý softwarePokud si stáhnete aplikaci nebo spustitelný soubor z internetu a nejste si jisti jeho původem, můžete jej nejprve nainstalovat do sandboxu systému Windows a sledovat, jak se chová, aniž by to ohrozilo váš počítač.
- Bezpečnější prohlížení webu: pro Návštěva potenciálně nebezpečných webových stránek, stránek s malwarem nebo phishingových stránekProhlížeč můžete otevřít uvnitř sandboxu. Pokud se něco pokazí, pouhé zavření okna odstraní veškeré stopy.
- Otevírání nedůvěryhodných příloh a souborůPokud obdržíte podezřelou přílohu nebo ZIP soubor, který nevzbuzuje důvěru, zkopírujete jej do sandboxu, otevřete ho tam a po kontrole se rozhodnete, zda má cenu něco extrahovat do skutečného systému.
- Ukázky a testy specifických nástrojůJe ideální pro vytváření softwarových ukázek, testování náhledových verzí, rozšíření nebo doplňků, aniž by to zahlcovalo vaši hlavní instalaci.
- Udržujte více samostatných vývojových prostředíPro každý jazykový zásobník nebo verzi můžete například vytvořit samostatné, izolované prostory sandbox pro každou verzi Pythonu a její závislostiaby experimenty nenarušovaly vaše stabilní prostředí.
Požadavky a licence pro používání Windows Sandboxu
Ne každý může používat Windows Sandbox, ale je již k dispozici v mnoha profesionálních prostředích. Chcete-li ho povolit ve svém počítači, potřebujete:
- Kompatibilní edice pro WindowsWindows 10/11 Pro, Enterprise, Pro Education/SE nebo Education. Edice Home není podporována.
- Podpora virtualizaceJe nezbytné mít virtualizační funkce v BIOSu/UEFI (Intel VT-x, AMD-V nebo ekvivalent).
- Minimální zdrojealespoň 4 GB RAM (doporučuje se 8 GB), 1 GB volného místa na disku — nejlépe SSD — a minimálně 2 jádra CPU (ideálně 4 s hyperthreadingem).
- Aktualizovaný operační systémPočínaje určitými sestaveními (například Windows 10 sestavení 18305 a novější a moderní sestavení Windows 11). V ARM64 se kompatibilita objevila s novějšími sestaveními.
Pokud jde o licencování, edice Pro, Enterprise a Education zahrnují právo používat Windows Sandbox bez nutnosti platit za další licence virtualizačního softwaru. Stačí jej aktivovat a je to.
Jak aktivovat Windows Sandbox bez dalších nástrojů
K jeho spuštění nepotřebujete nic mimo samotný systém:
- Otevřete nabídku Start a vyhledejte možnost "Zapnout nebo vypnout funkce Windows".
- V seznamu funkcí označte Pískoviště Windows a potvrďte.
- Po zobrazení výzvy restartujte počítač.
- Po restartu vyhledejte v nabídce Start „Windows Sandbox“ a spusťte jej.
Pokud dáváte přednost techničtějšímu přístupu, můžete jej také povolit pomocí PowerShellu příkazem `Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online` , za předpokladu, že máte administrátorská oprávnění. Po povolení bude sandbox vždy k dispozici, kdykoli budete potřebovat tento bezpečný „druhý počítač“.
Konfigurační a přizpůsobení soubory
Sandbox systému Windows podporuje jednoduché konfigurační soubory, které umožňují přizpůsobit určité parametry prostředí : například připojení složek hostitele jako pouze pro čtení nebo čtení i zápis, vypnutí sítě, spouštění skriptů při spuštění atd. Tyto soubory jsou k dispozici od konkrétních sestavení systému Windows 10 a 11.
V praxi vám tato funkce pomáhá vytvářet „recepty“ pro sandbox: jednu konfiguraci s vypnutou sítí pro otevírání malwaru , jinou se složkou projektu připojenou v režimu pouze pro čtení pro kontrolu souborů nebo konfiguraci zaměřenou na testování softwaru s určitými nástroji předinstalovanými v základním obrazu.
Jak naučit AI agenty správně používat sandbox
Sandbox je skutečně efektivní pouze tehdy, pokud samotný kódový agent rozumí prostředí, ve kterém pracuje, a ví, kdy může fungovat volně a kdy potřebuje požádat o další oprávnění nebo lidskou pomoc.
Aby toho bylo dosaženo, muselo mnoho platforem důkladně přepracovat infrastrukturu, která popisuje nástroje modelu. Například aktualizace popisů nástrojů shellu tak, aby jasně vysvětlovaly:
- Jaká omezení sandbox ukládá? (přístup k souborovému systému, git, síť).
- Jak může agent požádat o upgrade povolení když něco selže kvůli nedostatku oprávnění.
- Které typy příkazů budou s největší pravděpodobností blokovány?
Tyto změny ne vždy fungují perfektně hned napoprvé: obvykle vyžadují rozsáhlé manuální testování reálných postupů nasazení , analýzu toho, kde se očekávání modelu selhávají, a úpravu výzev a instrukcí. Měřením chování s a bez sandboxu v interních benchmarkech se identifikují vzorce selhání, jako například agenti, kteří opakovaně provádějí stejný příkaz, který sandbox blokuje, místo aby pochopili, že je třeba požádat o další oprávnění nebo upravit svou strategii.
Praktickým vylepšením je zobrazení konkrétního důvodu blokování vynuceného sandboxem ve výsledcích nástroje a dokonce i explicitní návrh, aby agent v případě potřeby požádal o zvýšená oprávnění. Tato malá nápověda drasticky snižuje počet slepých opakování a zlepšuje zotavení z chyb souvisejících se sandboxem, a to jak v offline testování, tak v produkčním prostředí.
Aby se zajistilo, že sandbox nezhorší uživatelský zážitek, mnoho společností se rozhodlo pro postupné zavádění , přičemž před jeho aktivací ve výchozím nastavení shromažďují interní i externí zpětnou vazbu. Data jsou obvykle jasná: značná část požadavků (například zhruba třetina) je nakonec vyřízena v rámci sandboxu na kompatibilních platformách, s výrazným zkrácením doby strávené žádostí o schválení i ruční kontrolou.
Modely izolace a lekce bezpečnosti z reálného světa
V praxi neexistuje jediný „dokonalý sandbox“. Existují důležité rozdíly mezi sdíleným kontejnerem jádra, sandboxem typu gVisor, microVM a plnohodnotným VM . Toto rozlišení je důležité, když mluvíme o tom, zda agent může spouštět Docker, instalovat libovolné balíčky nebo dokonce spouštět složité prohlížeče a vlákna.
Historické bezpečnostní incidenty podtrhují důležitost správného výběru: zranitelnosti jako CVE-2019-5736 nebo CVE-2024-21626 , které umožňovaly přechod z kontejneru na hostitelský počítač nebo manipulaci s binárními soubory systému, ukazují, že pokud je vaším limitem důvěry běhové prostředí kontejneru na hostitelském jádře, může vážná chyba celou bariéru zničit.
U kódovacích agentů se to stává ještě problematičtějším, protože často spouštějí nedůvěryhodný kompilační kód, sestavují obrazy, instalují neauditované závislosti a obecně zpracovávají vysoce heterogenní vstupy. Navíc je tlak na to, aby se jim „daly větší pravomoci“, silný: pokud nemohou spustit určité nástroje, často nedokážou dokončit své úkoly.
Mnoho moderních návrhů sandboxů agentů proto má tendenci posilovat hranici pomocí mikrovirtuálních strojů (microVM) nebo odlehčených virtuálních strojů (Lightweight VM) , a to i za cenu mírně zvýšené složitosti. To snižuje přímou závislost na jádru hostitele a poskytuje další vrstvu izolace proti únikům kontejnerů. V prostředí s více klienty nebo při rozsáhlém provádění nedůvěryhodného kódu zaujímají gVisor nebo Kata Container střední cestu a vyměňují kompatibilitu za větší izolaci.
Lidské schválení, politické schválení a sandboxy: jak to všechno skloubit dohromady
Jedním opakujícím se vzorcem je, že trvalé žádosti o oprávnění se neškálují dobře . V demo režimu je v pořádku, když agent před přístupem k souboru požádá o oprávnění. V produkčním režimu s poloautonomními pracovními postupy a četnými malými akcemi se však model „klikněte na OK pro vše“ stává sítem.
Zralejší přístup kombinuje několik vrstev:
- Silné pískoviště k ochraně hostitele a vymezení prostředí pro provádění.
- Omezující síťová politika ovládat, se kterými koncovými body může agent komunikovat.
- Správa přihlašovacích údajů přes proxytakže je model používá, aniž by je viděl.
- Konfigurace s verzemi na úrovni projektu (oprávnění, hooky, externí servery), aby týmy měly v repozitáři jeden zdroj pravdivých informací.
- Subagenti pouze pro čtení pro průzkum a plánování, přičemž psaní ponecháváme kontrolovanějším instancím.
- Lidské schválení vyhrazeno pro skutečně delikátní činypublikování balíčků, změny infrastruktury, rotace tajných kódů nebo odesílání do kritických větví.
Dále je důležité zvážit kontrolní plochu, kterou agentovi poskytujete prostřednictvím vlastních konfiguračních souborů, pluginů a dovedností. Průvodci od poskytovatelů, jako je OpenAI, jasně varují, že zveřejnění otevřených katalogů funkcí nebo povolení komukoli definovat výkonné instrukce v repozitáři může vést k únikům dat nebo destruktivním akcím, pokud se útočníkovi podaří vložit škodlivé instrukce do souborů README, problémů, dokumentace nebo vzorových souborů.
V rozumném návrhu není sandbox vnímán jako kouzelnický trik, který přes noc vyřeší bezpečnost, ale spíše jako další hranice v rámci architektury, která zahrnuje zásady, nezávislé ověřování, pečlivou správu tajných informací a kontroly konfigurace . I za předpokladu, že agent jednoho dne přečte a bude se řídit škodlivými pokyny, je systém navržen tak, aby omezil dopad: žádný přímý přístup ke klíčům, žádná otevřená síť a žádná možnost tajně upravovat skripty, které pak spouštíte na svém skutečném počítači.
Nastavení dobrého manuálního sandboxu bez spoléhání se na další software v konečném důsledku spočívá v maximalizaci možností systémů macOS, Linux a Windows – profilů Seatbelt, Landlock a seccomp, Windows Sandbox a WSL2 – v kombinaci s jasnými síťovými pravidly, přihlašovacími údaji a správou životního cyklu prostředí. Přidejte k tomu vyškolené agenty, kteří těmto omezením rozumí, rozumné zásady a určitou disciplínu ohledně toho, k čemu mají ve vašem pracovním prostoru přístup, a můžete testovat rizikový kód, nástroje a soubory s mnohem větším klidem, protože víte, že pokud se něco pokazí, problém zůstane v sandboxu a neohrozí váš systém ani kritická data. Sdílejte tyto informace, aby se o nich mohlo dozvědět více uživatelů.