Când lucrați cu software, agenți de inteligență artificială sau fișiere descărcate de pe internet, una dintre cele mai frecvente temeri este Defectarea unui sistem, infectarea cu programe malware sau scurgerea de date sensibile Aproape fără să-ți dai seama. Nu trebuie să fii paranoic: o singură execuție eșuată poate șterge o bază de date, poate strica o implementare sau poate infecta sistemul cu programe malware.
Vestea bună este că astăzi aveți la dispoziție mai multe modalități de a crea unul. un mediu izolat unde poți încerca lucruri fără a-ți asuma riscuriȘi multe dintre ele sunt integrate în sistemul de operare în sine sau în platforme concepute pentru agenți de cod. Numim acest lucru „sandboxing”: rularea codului în interiorul unui fel de bulă controlată, astfel încât, chiar dacă ceva nu merge bine sau este rău intenționat, daunele sunt ținute sub control.
Ce este sandboxing-ul manual fără software suplimentar?
În domeniul securității și dezvoltării, a vorbi despre sandbox-uri înseamnă a vorbi despre... pentru a defini clar ce poate atinge un program sau agent în timp ce ruleazăNu este vorba doar despre „a-l rula în altă parte”, ci despre definirea unor limite clare: ce fișiere poate vedea, ce procese poate lansa, dacă are o rețea, ce acreditări poate utiliza, cât timp există acel mediu și ce se întâmplă cu starea sa când se termină.
Distincția dintre „manual” și „fără software suplimentar” este înșelătoare. În multe cazuri, vă puteți baza pe funcții deja incluse în sistemul de operare sau în propria platformă de dezvoltarecum ar fi Windows Sandbox, primitive Linux (Landlock, seccomp) sau mecanisme macOS. Nu trebuie să instalați o suită completă de virtualizare, dar trebuie să învățați cum să activarea și gestionarea acelor mecanisme integrate să acționeze ca o barieră între codul pe care doriți să îl testați și mașina dvs. reală.
De ce au nevoie agenții de cod de medii izolate?
Agenții de codare moderni nu mai sunt simpli asistenți de tip chat care sugerează fragmente de cod: ei sunt medii de execuție cuplate la un model lingvisticAceștia pot citi depozitul dvs., edita fișiere, executa comenzi de terminal, instalați pachete, construi containere, comunică cu API-uri externe și chiar deschizi sesiuni de browser.
Platforme precum Claude Code, unii „Agenți Profunzi” LangChain sau sandbox-uri specifice distribuite de Docker și alte instrumente descriu explicit faptul că acești agenți Acestea operează pe sisteme de fișiere reale, lansează fire de execuție și deleagă sarcini către subagenți specializați.Cu alte cuvinte, sunt destul de similari cu un dezvoltator junior care are acces la instrumentele tale... doar că sunt automatizați și foarte rapizi.
În acest context, principala întrebare de securitate încetează să mai fie „Răspunde bine la solicitare?” și devine: „Care este domeniul de aplicare atunci când este greșit, nealiniat sau a fost manipulat?”Dacă un model poate, de exemplu, să ruleze pytest, să instaleze pachete npm, să gestioneze ramuri sau să inspecteze o eroare de compilare, este la doar câțiva pași distanță de a atinge scripturi de implementare, a modifica hook-uri Git sau a exfiltra secrete către un serviciu la distanță.
Răspunsul simplu este, de obicei, să se solicite aprobarea umană pentru fiecare comandă. Asta ajută, dar are o problemă recurentă: oboseala aprobăriiÎn mediile în care inginerii lansează mulți agenți sau fluxuri de lucru în paralel, volumul mare de solicitări duce adesea la aprobarea a aproape tuturor lucrurilor fără o verificare atentă. Atunci când peste 90% din solicitările de permisiune sunt acceptate automat, acest mecanism încetează să mai fie un control de securitate autentic și devine doar o formalitate.
De aceea contează atât de mult sandbox-urile: Nu fac modelul infailibil și nici nu corectează injecția de instrucțiuni.Dar reduc „raza de explozie” a erorilor sale. Dacă inteligența artificială greșește sau cineva reușește să-i deturneze instrucțiunile, daunele rămân limitate la mediul izolat, în loc să se răspândească direct la sistemul de producție sau la laptop.
Principalele limitări ale unui sandbox pentru agent de cod
Un sandbox serios pentru agenții de codare se bazează pe mai multe tipuri de limite, nu doar „un alt director” sau „un alt container”. Fiecare acoperă un aspect diferit al riscului, iar înțelegerea acestora este esențială pentru un sandboxing manual eficient cu resursele existente.
Limita sistemului de fișiere
Primul lucru este să te decizi. ce arbore de directoare poate vedea și modifica agentulÎntr-un sandbox configurat corect, agentul ar trebui să poată citi și scrie doar în spațiul de lucru sau în volumele pe care le creați explicit pentru el. Restul sistemului (directorul principal al utilizatorului, căile de sistem, alte proiecte) ar trebui să îi fie inaccesibil.
Framework-urile de agenți și platformele sandbox clarifică foarte mult acest lucru: sandbox-ul este bariera care împiedică atingerea fișierelor gazdă dincolo de ceea ce este partajatÎn modelele bazate pe microVM, regula este și mai strictă: doar directorul pe care îl montați (adesea cu funcție de citire-scriere) traversează granița dintre mașina virtuală și gazdă. Orice altceva rămâne inaccesibil dacă nu îl deschideți.
Limita procesului și nucleul
A doua limită cheie este ceea ce agentul vede la nivel de proces și kernel. Dacă în mediul izolat instalează servicii, pornește containere sau lansează thread-uriToate aceste acțiuni trebuie să rămână încapsulate, fără a partaja procese sau un kernel bare cu gazda.
Multe implementări robuste de tip sandbox se bazează pe microVM-uri sau mașini virtuale ușoare cu propriul kernel Linux, întărit cu seccomp, cgroup-uri, namespace-uri și tehnici de jail. Alții folosesc straturi precum gVisor sau Kata Containers pentru a interpune un strat de virtualizare sau emulare între procesul izolat și kernelul nodului. Ideea de bază: dacă cineva exploatează ceva din interior, saltul către gazdă este mult mai dificil decât într-un simplu container cu kernel partajat.
Limita rețelei
Agenții de cod sunt adesea foarte „avide de rețea”: vor să instaleze dependențe, să consulte documentația, să apeleze API-uri LLM, să acceseze depozite la distanță sau chiar să navigheze pe web. Fără o politică clară, un mediu „izolat” poate ajunge să fie... un tunel fantastic de exfiltrare a datelor.
De aceea, tot mai multe platforme adoptă o poziție de refuz implicit al traficului de ieșireHTTP/HTTPS este blocat, cu excepția anumitor cazuri, TCP/UDP/ICMP este restricționat și, foarte important, accesul la intervale private și adrese locale este interzis. Comunicarea este permisă numai cu gazde sau domenii incluse explicit pe o listă de permisiuni și adesea printr-un proxy controlat de gazdă.
Limită de acreditări
Nu este de mare folos să ai agentul blocat dacă, în interiorul cuștii sale, poate citi cheile API, token-urile de implementare sau secretele bazei de date. Designul modern al multor sandbox-uri constă în... Nu injectați niciodată secrete brute într-un mediu izolatÎn schimb, trebuie să folosiți un proxy de pe gazdă pentru a adăuga acreditările în anteturile cererilor HTTP pe care sandbox-ul dorește să le trimită.
Cu această abordare, procesul din cadrul sandbox-ului El folosește acreditările, dar nu le vede niciodată.Acest lucru reduce considerabil impactul unei potențiale deturnări de agent. Cu toate acestea, în momentul în care stocați o cheie într-un fișier sau o variabilă de mediu din cadrul sandbox-ului, acest avantaj dispare: modelul o poate citi direct, iar orice injecție de instrucțiuni îi poate ordona să o filtreze.
Limita și starea ciclului de viață
În cele din urmă, există limita de timp: Ce se păstrează și ce se distruge atunci când mediul înconjurător se opreșteAgenții nu sunt procese unice: citesc, compilează, depanează, deschid mai multe ipoteze, abandonează unele, le reiau pe altele… Acest lucru necesită un runtime care gestionează starea în mod inteligent: pornire rapidă, suspendare, snapshot-uri, ramificare și ștergere în siguranță.
Unele platforme oferă instantanee de memorie, pool-uri de medii preîncălzite și funcții de bifurcare dintr-o stare specifică (de exemplu, un browser deja autentificat sau un graf de dependențe parțial rezolvat). Aceasta face diferența dintre un agent utilizabil - unul care poate itera interactiv - și un agent căruia îi ia mult timp să repete aceeași configurație iar și iar.
Implementări de sandboxing pe macOS, Linux și Windows
Dincolo de produsele comerciale, multe echipe au optat pentru să profite de primitivele de izolare deja prezente în sistemele de operare să-și construiască propriile sandbox-uri pentru agenți de cod fără a adăuga straturi mai grele. Cheia este să înțeleagă ce aduce fiecare platformă.
Sandboxing pe macOS: Centură de siguranță și profiluri dinamice
Mai multe modele au fost evaluate pe macOS: App Sandbox, containere, mașini virtuale și Seatbelt. Primele opțiuni au dezavantaje semnificative pentru un mediu de dezvoltare: App Sandbox necesită semnarea fiecărui fișier binar pe care agentul l-ar putea executa și moștenește încrederea firmei, ceea ce deschide vectori de abuz dacă agentul însuși generează sau modifică fișiere binare; containerele sunt limitate la ecosistemul Linux; mașinile virtuale tradiționale adaugă o latență semnificativă la pornire și un consum semnificativ de memorie.
Alternativa practică a fost să se bazeze pe Centură de siguranță, accesibilă prin sandbox-execDeși Apple l-a marcat ca fiind învechit de ani de zile, este încă utilizat de aplicații critice, cum ar fi ChromeVă permite să rulați comenzi sub un profil sandbox care restricționează comportamentul întregului arbore de procese descendent.
Profilul respectiv definește permisiunile cu mare granularitate: Poate filtra apeluri de sistem specifice și poate citi sau scrie pe anumite fișiere și directoare.folosind un limbaj de politici specific. Există implementări care generează această politică dinamic la momentul execuției, combinând configurarea spațiului de lucru, politicile administratorului și fișierele de ignorare a utilizatorilor, astfel încât agentul să aibă spațiu de manevră fără a atinge zone periculoase.
Sandboxing pe Linux: Landlock și seccomp
Linux oferă atât mai multă flexibilitate, cât și mai multă muncă: nucleul expune primitive precum Lanț închis și seccompDar este responsabilitatea spațiului utilizatorului să le combine într-un sandbox coerent și ușor de gestionat.
În loc să se bazeze exclusiv pe proiecte externe, unele echipe aleg să Folosește direct seccomp pentru a bloca apelurile de sistem considerate periculoase. și Landlock pentru a restricționa accesul la sistemul de fișiere. Un model comun implică montarea spațiului de lucru al utilizatorului peste o suprapunere a sistemului de fișiere și Înlocuiți fișierele marcate ca ignorate cu copii speciale protejate de Landlockastfel încât procesul izolat să nu poată citi sau modifica nimic din ceea ce doriți de fapt să ascundeți.
Cea mai lentă parte a acestei abordări este de obicei localizarea și reasamblarea tuturor acelor fișiere, deoarece Linux nu oferă o modalitate ușoară de a găsi calea completă a unui fișier într-un filtru seccomp-bpfChiar și așa, rezultatul este un sandbox destul de fin: agentul poate lucra cu arborele său de proiect în timp ce căile interzise sunt, de facto, în afara universului său.
Sandboxing pe Windows: bazându-se pe WSL2
În Windows, povestea este diferită. Crearea unui sandbox nativ de uz general este mult mai complicată deoarece Majoritatea primitivelor de izolare existente sunt concepute pentru browsere sau alte programe software foarte specifice.și nu se potrivesc bine cu instrumente de dezvoltare versatile.
O soluție practică este rulează un sandbox Linux în WSL2În acest fel, reciclezi instrumentele de izolare ale Linux (Landlock, seccomp, namespace-uri etc.) pe o bază de virtualizare care izolează sesiunea de dezvoltare de gazda Windows. Simultan, există o colaborare coordonată cu Microsoft pentru a expune noi primitive care vor permite în cele din urmă un sandboxing nativ mai intens pentru instrumentele de dezvoltare.
Windows Sandbox: un spațiu izolat integrat în sistem
Pentru cei care utilizează Windows 10 sau 11 în edițiile Pro, Enterprise sau Education, există un instrument deosebit de interesant: Sandbox-ul WindowsEste o mașină virtuală ușoară, integrată în sistemul în sine, care vă permite să rulați aplicații nesigure sau fișiere suspecte într-un mediu de unică folosință.
Ideea este simplă: când deschizi Windows Sandbox, acesta pornește un desktop Windows temporar și curat, ca și cum ar fi fost instalat recentTot ce copiați sau instalați în cadrul acesteia — programe, documente, scripturi — există doar în acea instanță. Dacă închideți fereastra, mediul este distrus: software-ul, fișierele și starea sunt eliminate, iar data viitoare o veți lua de la capăt.
Caracteristici cheie ale Windows Sandbox
Această caracteristică vine cu câteva proprietăți foarte utile pentru sandboxing-ul manual, fără a se baza pe instrumente terțe:
- Parte din WindowsTot ce ai nevoie este deja inclus în edițiile compatibile (Pro, Enterprise, Education). Nu trebuie să descarci imagini sau să întreții mașini virtuale externe.
- De unică folosință și impecabilFiecare rulare este la fel de curată ca o instalare nouă de Windows. Nimic din ceea ce faci în interior nu este salvat pe dispozitiv odată ce închizi mediul.
- Sigur prin designSe bazează pe virtualizarea bazată pe hardware (Hyper-V) pentru a izola kernelul sandbox de kernelul gazdă. Folosește hypervisorul Microsoft pentru a menține cele două lumi separate.
- eficientPornirea este rapidă, în câteva secunde, cu gestionare inteligentă a memoriei și suport pentru GPU virtual, utilizând mai puține resurse decât o mașină virtuală tradițională.
Tehnic, se comportă ca o mică mașină virtuală Windows de unică folosință, perfect valabil pentru testarea programelor de instalare, vizitarea site-urilor web dubioase sau deschiderea atașamentelor la e-mailuri în care nu aveți încredere că vor rula pe sistemul dvs. real.
Scenarii practice pentru utilizarea Windows Sandbox
Există câteva scenarii tipice în care Windows Sandbox se remarcă ca o soluție simplă de sandboxing manual:
- Încercați software necunoscutCând descărcați o aplicație sau un fișier executabil de pe internet și nu sunteți sigur de originea sa, o puteți instala mai întâi în Windows Sandbox și puteți vedea cum se comportă fără riscuri pentru computerul dumneavoastră.
- Navigare web mai sigură: pentru Vizitarea site-urilor web potențial periculoase, a site-urilor cu programe malware sau a site-urilor de phishingPoți deschide browserul în interiorul sandbox-ului. Dacă ceva nu merge bine, simpla închidere a ferestrei va elimina orice urmă.
- Deschiderea atașamentelor și fișierelor nesigureDacă primiți un atașament suspect sau un fișier ZIP care nu inspiră încredere, îl copiați în sandbox, îl deschideți acolo și, odată analizat, decideți dacă merită să extrageți ceva în sistemul dvs. real.
- Demonstrații și teste specifice ale instrumentelorEste perfect pentru crearea de demonstrații de software, testarea versiunilor de previzualizare, extensiilor sau add-on-urilor fără a aglomera instalarea principală.
- Mențineți mai multe medii de dezvoltare separatePuteți crea spații separate, izolate pentru fiecare stivă de limbi sau versiune, de exemplu un sandbox pentru fiecare versiune de Python și dependențele saleastfel încât experimentele să nu interfereze cu mediul dumneavoastră stabil.
Cerințe și licențe pentru utilizarea Windows Sandbox
Nu toată lumea poate utiliza Windows Sandbox, dar este deja disponibil în multe medii profesionale. Pentru a-l activa pe computer, aveți nevoie de:
- Ediție Windows compatibilăWindows 10/11 Pro, Enterprise, Pro Education/SE sau Education. Ediția Home nu este acceptată.
- Suport pentru virtualizareEste esențial să existe funcții de virtualizare în BIOS/UEFI (Intel VT-x, AMD-V sau echivalent).
- Resurse minimecel puțin 4 GB de RAM (deși se recomandă 8 GB), 1 GB de spațiu liber pe disc — de preferință SSD — și minimum 2 nuclee CPU (în mod ideal 4 cu hyperthreading).
- sistem de operare actualizatÎncepând cu anumite versiuni (de exemplu, Windows 10 versiunea 18305 și versiunile ulterioare și versiunile moderne de Windows 11). Pe ARM64, compatibilitatea a sosit cu versiuni mai recente.
În ceea ce privește licențele, Edițiile Pro, Enterprise și Education includ dreptul de a utiliza Windows Sandbox Nu este nevoie să plătiți pentru licențe suplimentare de software de virtualizare. Trebuie doar să îl activați și sunteți gata.
Cum să activezi Windows Sandbox fără instrumente suplimentare
Pentru a-l pune în funcțiune, nu aveți nevoie de nimic în afara sistemului în sine:
- Deschideți meniul Start și căutați opțiunea „Activați sau dezactivați funcțiile Windows”.
- În lista de caracteristici, marcați Sandbox-ul Windows și confirmați.
- Reporniți computerul când vi se solicită.
- După repornire, căutați „Windows Sandbox” în meniul Start și rulați-l.
Dacă preferi o abordare mai tehnică, o poți activa și cu PowerShell folosind comanda Activare-WindowsOptionalFeature -FeatureName „Containers-DisposableClientVM” -All -Onlinecu condiția să aveți privilegii de administrator. Odată activat, sandbox-ul va fi întotdeauna disponibil oricând aveți nevoie de acea „a doua mașină” securizată.
Fișiere de configurare și personalizare
Windows Sandbox acceptă fișiere de configurare simple care vă permit să personalizați anumiți parametri de mediuDe exemplu, montarea folderelor gazdă în modul de citire sau citire-scriere, dezactivarea rețelei, rularea scripturilor la pornire etc. Aceste fișiere sunt disponibile începând cu anumite versiuni de Windows 10 și 11.
În practică, această funcționalitate vă ajută să creați „rețete” de tip sandbox: o configurație dezactivată de rețea pentru a deschide programe malwareUn altul cu un folder de proiect montat în modul doar pentru citire pentru revizuirea fișierelor sau o configurație orientată spre testarea software-ului cu anumite instrumente preinstalate în imaginea de bază.
Cum să înveți agenții AI să utilizeze corect sandbox-ul
Un sandbox este cu adevărat eficient doar dacă Agentul de cod în sine înțelege mediul în care operează. și știe când poate funcționa liber și când trebuie să solicite permisiuni suplimentare sau asistență umană.
Pentru a realiza acest lucru, multe platforme au fost nevoite să revizuiască temeinic infrastructura care descrie instrumentele modelului. De exemplu, actualizarea descrierilor instrumentelor shell pentru a explica clar:
- Ce restricții impune sandbox-ul? (acces la sistemul de fișiere, git, rețea).
- Cum poate agentul solicitați o actualizare a permiselor când ceva eșuează din cauza lipsei de privilegii.
- Ce tipuri de comenzi sunt cel mai probabil să fie blocate?
Aceste schimbări nu ies întotdeauna perfect de prima dată: de obicei necesită Testare manuală extinsă a fluxurilor de implementare realeAnalizarea punctelor unde așteptările modelului se întrerup și ajustarea solicitărilor și instrucțiunilor. Prin măsurarea comportamentului cu și fără un sandbox în reperele interne, se identifică modele de eșec, cum ar fi agenții care Ei repetă aceeași comandă într-o buclă pe care sandbox-ul o blochează. în loc să înțeleagă că trebuie să solicite alte permisiuni sau să își modifice strategia.
O îmbunătățire practică este de a se reflecta în rezultatele instrumentului motivul specific pentru blocarea impusă de sandbox și chiar să sugereze explicit agentului să solicite permisiuni ridicate atunci când este cazul. Acest mic indiciu reduce drastic reîncercările oarbe și îmbunătățește recuperarea după erorile legate de izolare, atât în testarea offline, cât și în producție.
Pentru a se asigura că sandbox-ul nu degradează experiența utilizatorului, multe companii au optat pentru implementați-l treptatColectarea de feedback intern și extern înainte de activarea implicită. Datele sunt de obicei clare: o fracțiune semnificativă din solicitări (de exemplu, aproximativ o treime) ajung să ruleze într-un sandbox pe platforme compatibile, cu reduceri notabile atât în așteptarea aprobării, cât și în timpul de revizuire manuală.
Modele de izolare și lecții de siguranță din lumea reală
În practică, nu există un singur „mediu de testare perfect”. Există diferențe importante între un container de kernel partajat, un sandbox de tip gVisor, o microVM și o VM completăAceastă nuanță contează atunci când vorbim despre permiterea agentului să ruleze Docker, să instaleze pachete arbitrare sau chiar să lanseze browsere și fire de execuție complexe.
Incidentele istorice de securitate subliniază importanța alegerii cu înțelepciune: vulnerabilități precum CVE-2019-5736 sau CVE-2024-21626, care permiteau trecerea de la container la gazdă sau manipularea fișierelor binare ale sistemului, demonstrează că atunci când limita de încredere este un runtime al containerului pe kernelul gazdă, o eroare gravă poate dărâma întreaga barieră.
Acest lucru devine mai delicat cu agenții de codare, deoarece aceștia execută adesea cod de compilare nesigur, construirea de imagini, instalarea dependențelor fără auditare și, în general, gestionează intrări foarte eterogene. În plus, presiunea de a le „da mai multă putere” este puternică: dacă nu pot rula anumite instrumente, adesea nu reușesc să își îndeplinească sarcinile.
De aceea, multe modele moderne de sandbox-uri pentru agenți tind să consolidarea limitei folosind microVM-uri sau VM-uri ușoareAcest lucru vine cu prețul unei complexități ușor crescute. Dependența directă de kernelul gazdă este redusă și se obține un nivel suplimentar de izolare împotriva evadărilor containerelor. În mediile cu mai mulți chiriași sau în execuția la scară largă a unui cod nede încredere, gVisor sau Kata Container ocupă o poziție de mijloc, renunțând la compatibilitate pentru o izolare mai mare.
Aprobări umane, aprobări politice și medii izolate: cum să le îmbinăm pe toate
Un model care se repetă peste tot este acela că Cererile de autorizații perene nu sunt adaptate bine la nevoile cliențilorÎn modul demo, agentul poate solicita permisiunea înainte de a atinge un fișier. În producție, cu fluxuri de lucru semi-autonome și multe acțiuni mici, modelul „faceți clic pe OK pentru tot” ajunge să fie o sită.
Abordarea mai matură combină mai multe niveluri:
- Cutie cu nisip puternică pentru a proteja gazda și a delimita mediul de execuție.
- Politică de rețea restrictivă pentru a controla cu ce puncte finale poate comunica agentul.
- Gestionarea acreditărilor prin proxyastfel încât modelul le folosește fără să le vadă.
- Configurații versionate la nivel de proiect (permisiuni, hook-uri, servere externe) astfel încât echipele să aibă o singură sursă de informații în depozit.
- Subagenți doar pentru citire pentru explorare și planificare, lăsând acțiunile de scriere unor instanțe mai controlate.
- Aprobarea umană rezervată acțiunilor cu adevărat delicate: publicarea pachetelor, modificări ale infrastructurii, rotația secretelor sau trimiterea către ramuri critice.
În plus, merită să se ia în considerare suprafață de control pe care le furnizați agentului împreună cu propriile fișiere de configurare, plugin-uri și abilități. Ghidurile de la furnizori precum OpenAI avertizează clar că expunerea cataloagelor deschise de capabilități sau permiterea oricui să definească instrucțiuni puternice în cadrul depozitului poate duce la scurgeri de date sau acțiuni distructive dacă un atacator reușește să injecteze instrucțiuni rău intenționate în fișiere README, probleme, documentație sau fișiere exemplu.
Într-un design sonor, sandbox-ul nu este văzut ca un truc magic care remediază securitatea dintr-o singură mișcare, ci ca încă o limită în cadrul unei arhitecturi care include politici, verificare independentă, gestionarea atentă a secretelor și revizuiri ale configurațieiAstfel, chiar presupunând că într-o zi agentul citește instrucțiuni malițioase și le respectă, sistemul este conceput pentru a limita impactul: fără acces direct la chei, fără rețea deschisă și fără posibilitatea de a modifica pe ascuns scripturi pe care apoi le rulați pe mașina reală.
În cele din urmă, configurarea unui sandbox manual bun, fără a te baza pe software suplimentar, implică... Profită la maximum de ceea ce îți oferă deja macOS și Linux. —Profile Seatbelt, Landlock și seccomp, Windows Sandbox și WSL2—, combinate cu reguli clare de rețea, acreditări și gestionarea ciclului de viață al mediului. Adăugați la acestea agenți instruiți să înțeleagă aceste restricții, politici rezonabile și o oarecare disciplină cu privire la ceea ce au voie să acceseze în spațiul dvs. de lucru și puteți testa cod, instrumente și fișiere riscante cu mult mai multă liniște sufletească, știind că, dacă ceva nu merge bine, problema va rămâne în sandbox și nu va afecta sistemul sau datele critice. Distribuiți informațiile pentru ca mai mulți utilizatori să poată afla despre subiect.