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 Narušení systému, napadení malwarem nebo únik citlivých dat Téměř aniž byste si to uvědomovali. Nemusíte být paranoidní: jediné neúspěšné spuštění může smazat databázi, narušit nasazení nebo infikovat váš systém malwarem.
Dobrou zprávou je, že dnes máte k dispozici několik způsobů, jak si ho vytvořit. izolované prostředí, kde si můžete věci vyzkoušet, aniž byste riskovaliA 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á mluvit o sandboxech mluvit o... jasně definovat, čeho se program nebo agent může během svého běhu dotknoutNejde jen o to „spustit to někde jinde“, ale o definování jasných hranic: jaké soubory může vidět, jaké procesy může spustit, zda má síť, jaké přihlašovací údaje může použít, jak dlouho dané prostředí existuje a co se stane s jeho stavem po jeho ukončení.
Rozdíl mezi „manuálním“ a „bez dalšího softwaru“ je zavádějící. V mnoha případech se můžete spolehnout na funkce, které jsou již zahrnuty ve vašem operačním systému nebo vaší vlastní vývojové platforměnapříklad Windows Sandbox, Linuxové primitivy (Landlock, seccomp) nebo mechanismy macOS. Nemusíte instalovat kompletní virtualizační sadu, ale musíte se naučit, jak na to. aktivovat a spravovat tyto integrované mechanismy aby fungoval jako bariéra mezi kódem, který chcete testovat, a vaším skutečným strojem.
Proč kódoví agenti potřebují izolovaná prostředí?
Moderní kódovací agenti už nejsou jen asistenti podobní chatu, kteří navrhují úryvky kódu: jsou prováděcí prostředí propojená s jazykovým modelemMohou číst váš repozitář, upravovat soubory, spouštět terminálové příkazy, instalace balíčků, sestavit kontejnery, komunikovat s externími API a dokonce i otevírat relace prohlížeče.
Platformy jako Claude Code, někteří „hlubocí agenti“ LangChainu nebo specifické sandboxy distribuované Dockerem a dalšími nástroji explicitně popisují, že tito agenti Pracují 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 hlavní bezpečnostní otázka přestává být „Reaguje dobře na výzvu?“ a stává se: "Jaký je rozsah, když je špatný, špatně zarovnaný nebo byl manipulován?"Pokud model dokáže například spustit pytest, instalovat npm balíčky, spravovat větve nebo kontrolovat selhání kompilace, je jen pár kroků od manipulace s nasazenými skripty, úpravy Git hooků nebo exfiltrace tajných kódů do vzdálené služby.
Jednoduchá odpověď je obvykle vyžadovat lidské schválení pro každý příkaz. To pomáhá, ale má to opakující se problém: únava z uznáváníV prostředích, kde inženýři spouštějí mnoho agentů nebo pracovních postupů paralelně, vede obrovský objem požadavků často k tomu, že téměř vše je schváleno bez pečlivé kontroly. Pokud 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 pouhou formalitou.
Proto jsou sandboxy tak důležité: Nedělají model neomylným, ani neopravují vkládání instrukcí.Ale snižují „poloměr šíření“ jeho chyb. Pokud umělá inteligence něco zkazí nebo se někomu podaří unést její instrukce, poškození zůstane omezeno na izolované prostředí, místo aby se šíř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í věc je se rozhodnout. který adresářový strom může agent vidět a upravovatVe správně nakonfigurovaném sandboxu by měl být agent schopen číst a zapisovat pouze do pracovního prostoru nebo svazků, které pro něj explicitně vytvoříte. Zbytek systému (domovský adresář uživatele, systémové cesty, další projekty) by pro něj měl být nepřístupný.
Agentové frameworky a sandboxové platformy to jasně dávají najevo: sandbox je bariéra, která brání v přístupu k hostitelským souborům mimo sdílené souboryV 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 oprávněním pro čtení i zápis). Vše ostatní zůstává nepřístupné, dokud to neotevřete.
Hranice procesu a jádro
Druhou klíčovou hranicí je to, co agent vidí na úrovni procesu a jádra. Pokud se nachází v izolovaném prostředí instaluje služby, spouští kontejnery nebo spouští vláknaVš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 mikroVM nebo lehké virtuální stroje s vlastním linuxovým jádrem, posíleným o seccomp, cgroups, jmenné prostory a techniky 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 může „izolované“ prostředí skončit… fantastický tunel pro únik dat.
Proto stále více platforem zaujímá postoj výchozí odmítnutí odchozího provozuHTTP/HTTPS je blokován s výjimkou určitých případů, TCP/UDP/ICMP je omezen a, co je velmi důležité, je zakázán přístup k privátním rozsahům a lokálním adresám. 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é kódy databáze. Moderní design mnoha sandboxů se skládá z... Nikdy nevkládejte nezpracovaná tajemství do izolovaného prostředíMísto toho nechte proxy na hostiteli přidávat přihlašovací údaje do záhlaví HTTP požadavků, které chce sandbox odeslat.
S tímto přístupem proces v rámci 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 rámci sandboxu, tato výhoda mizí: model jej pak může přímo číst a jakákoli instrukční injekce mu může nařídit jeho filtrování.
Hranice a stav životního cyklu
Nakonec je tu časový limit: Co se zachová a co se zničí, když se životní prostředí zastavíAgenti nejsou jednorázové procesy: čtou, kompilují, ladí, otevírají několik hypotéz, některé opouštějí, jiné obnovují… To vyžaduje běhové prostředí, které inteligentně spravuje stav: rychlý start, pozastavení, snímky, větvení a bezpečné odstranění.
Některé platformy nabízejí snímky paměti, skupiny předehřátých prostředí a funkce pro větvení z určitého stavu (například již ověřený prohlížeč nebo částečně vyřešený graf závislostí). To rozlišuje 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 pro využít izolačních primitiv, které jsou již v operačních systémech přítomny aby si mohli vybudovat vlastní sandboxy kódových agentů bez přidávání těžších vrstev. 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í stroje a Seatbelt. První možnosti mají pro vývojové prostředí značné nevýhody: Aplikační sandbox vyžaduje podepsání každého binárního souboru, který by agent mohl spustit. a dědí důvěru firmy, což otevírá vektory zneužití, pokud samotný agent 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 Bezpečnostní pás, přístupný přes sandbox-execPřestože jej Apple již léta označuje za zastaralý, stále jej používají kritické aplikace, jako například chrómUmožňuje spouštět příkazy v profilu sandboxu, který omezuje chování celého stromu podřízených procesů.
Tento profil definuje oprávnění s velkou granularitou: Může filtrovat specifická systémová volání a číst nebo zapisovat do konkrétních souborů a adresářů.pomocí specifického jazyka zásad. Existují implementace, které tyto zásady generují 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í, aniž by se dotýkal 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 například Vnitrozemský a sekvenčníJe však odpovědností uživatelského prostoru je sloučit do souvislého a spravovatelného sandboxu.
Místo aby se spoléhaly výhradně na externí projekty, některé týmy se rozhodnou Použijte seccomp přímo k blokování systémových volání považovaných za nebezpečná. a Landlock pro omezení přístupu k souborovému systému. Běžný vzorec zahrnuje připojení pracovního prostoru uživatele nad překryvnou část souborového systému a Nahradit soubory označené jako ignorované speciálními kopiemi chráněnými Landlockemtakže izolovaný proces nemůže číst ani upravovat nic, co skutečně chcete skrýt.
Nejpomalejší částí tohoto přístupu je obvykle nalezení a opětovné sestavení všech těchto souborů, protože Linux nenabízí snadný způsob, jak najít úplnou cestu k souboru ve filtru seccomp-bpf.I tak je výsledkem poměrně jemná sandboxová platforma: agent může pracovat se svým projektovým stromem, zatímco zakázané cesty jsou de facto mimo jeho univerzum.
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 Většina existujících izolačních primitiv je navržena pro prohlížeče nebo jiný velmi specifický software.a nehodí se dobře k univerzálním vývojovým nástrojům.
Praktickým řešením je Spusťte Linuxový sandbox v rámci WSL2Tímto způsobem recyklujete izolační nástroje Linuxu (Landlock, seccomp, namespaces atd.) na virtualizační bázi, která izoluje vývojovou relaci od hostitele Windows. Současně probíhá koordinovaná práce se společností Microsoft na zpřístupnění nových primitiv, které nakonec umožní nativní sandboxing pro vývojové nástroje.
Sandbox ve Windows: izolovaný prostor integrovaný do systému
Pro ty, kteří používají Windows 10 nebo 11 v edicích Pro, Enterprise nebo Education, je k dispozici obzvláště zajímavý nástroj: Pískoviště WindowsJedná 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á: když otevřete Windows Sandbox, spustí se dočasná, čistá plocha Windows, jako by byla nově nainstalovánaVšechno, 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 se zahodí a příště 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 vzato se to chová jako malý jednorázový virtuální stroj s Windows, což je perfektní volba 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 nedůvěřujete, že se spustí 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.
Ohledně licencí, Edice Pro, Enterprise a Education zahrnují právo používat Windows Sandbox. Není třeba platit za další licence virtualizačního softwaru. Stačí jej aktivovat a je připraven.
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 pomocí příkazu Enable-WindowsOptionalFeature -FeatureName „Kontejnery-DisposableClientVM“ -Vše -Onlineza předpokladu, že máte administrátorská oprávnění. Po aktivaci bude sandbox vždy k dispozici, kdykoli budete potřebovat tento bezpečný „druhý počítač“.
Konfigurační a přizpůsobení soubory
Podpora Windows Sandboxu jednoduché konfigurační soubory, které umožňují přizpůsobit určité parametry prostředíNapříklad připojení hostitelských složek v režimu čtení nebo čtení i zápisu, vypnutí sítě, spouštění skriptů při spuštění atd. Tyto soubory jsou k dispozici od konkrétních sestavení Windows 10 a 11.
V praxi vám tato funkce pomáhá vytvářet „recepty“ v sandboxu: konfigurace se zakázaným přístupem k síti pro otevírání malwaruDalší s projektovou složkou připojenou v režimu pouze pro čtení pro kontrolu souborů nebo konfigurace orientovaná 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
Pískoviště je skutečně efektivní pouze tehdy, když Samotný kódový agent rozumí prostředí, ve kterém pracuje. a ví, kdy může volně fungovat a kdy potřebuje další povolení 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 se ne vždycky podaří dokonale napoprvé: obvykle to vyžaduje Rozsáhlé manuální testování reálných postupů nasazeníAnalýza oblastí, kde se očekávání modelu narušují, a úprava pokynů 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ří Opakují stejný příkaz ve smyčce, kterou sandbox blokuje. místo aby pochopili, že si musí vyžádat další oprávnění nebo upravit svou strategii.
Praktické vylepšení se projeví ve výsledcích nástroje konkrétní důvod bloku vynuceného sandboxem a dokonce explicitně navrhnout agentovi, aby v případě potřeby požadoval zvýšená oprávnění. Tato malá rada drasticky snižuje počet slepých opakování a zlepšuje zotavení z chyb souvisejících s izolací, 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 nasazovat ho postupněShromažďování interní a externí zpětné vazby před aktivací ve výchozím nastavení. Data jsou obvykle jasná: značná část požadavků (například zhruba třetina) nakonec běží v sandboxu na kompatibilních platformách, s výrazným zkrácením doby čekání na schválení i doby ruční kontroly.
Modely izolace a lekce bezpečnosti z reálného světa
V praxi neexistuje jediné „dokonalé sandboxové prostředí“. Existují důležité rozdíly mezi sdílený kontejner jádra, sandbox podobný gVisoru, mikrovirtuální stroj a plnohodnotný virtuální strojTato nuance je důležitá, když mluvíme o tom, že agentovi umožníme 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 zdůrazňují důležitost moudrého výběru: zranitelnosti, jako například CVE-2019-5736 nebo CVE-2024-21626, které umožňovaly přeskakování z kontejneru na hostitelský server 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á delikátnějším, protože ti často spouštějí nedůvěryhodný kompilační kód, vytváření obrazů, instalace závislostí bez auditu a obecně zpracovávají velmi heterogenní vstupy. Navíc je silný tlak na „dávání větších pravomocí“: pokud nemohou spustit určité nástroje, často nedokážou dokončit své úkoly.
Proto mnoho moderních návrhů sandboxů agentů obvykle posílit hranici pomocí mikrovirtuálních strojů nebo odlehčených virtuálních strojůTo má za následek mírně vyšší složitost. Snižuje se přímá závislost na jádru hostitele a získává se další vrstva 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, přičemž kompatibilitu vyměňují za větší izolaci.
Lidské schválení, politické schválení a sandboxy: jak to všechno skloubit dohromady
Jeden vzorec, který se opakuje všude, je ten, že Žádosti o trvalá povolení se nerozšířily dobřeV demo režimu je v pořádku, když si agent před dotykem souboru vyžádá povolení. V produkčním režimu s poloautonomními pracovními postupy a mnoha malými akcemi se model „klikněte na OK pro všechno“ nakonec 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 stojí za zvážení, řídicí plocha které agentovi poskytnete spolu s vlastními konfiguračními soubory, pluginy a dovednostmi. Průvodci od poskytovatelů, jako je OpenAI, jasně varují, že zveřejnění otevřených katalogů funkcí nebo umožnění 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 dobrém designu není sandbox vnímán jako kouzelnický trik, který jednou ranou vyřeší bezpečnost, ale 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 konfiguraceI za předpokladu, že si agent jednoho dne přečte škodlivé instrukce a bude je respektovat, 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.
V konečném důsledku, nastavení dobrého manuálního sandboxu bez spoléhání se na další software zahrnuje... Využijte naplno to, co vám macOS a Linux již nabízejí. —Profily 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řipočtěte k tomu agenty vyškolené k pochopení těchto omezení, 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 uzavřen v sandboxu a nezpůsobí výpadek vašeho systému ani kritických dat. Sdílejte informace, aby se o daném tématu dozvědělo více uživatelů.