Manuel sandboxing uden yderligere software i virkelige miljøer

Når man arbejder med software, AI-agenter eller filer downloadet fra internettet, er en af ​​de mest almindelige frygter At ødelægge noget i dit system, blive inficeret med malware eller lække følsomme data Næsten uden at du er klar over det. Du behøver ikke at være paranoid: en enkelt mislykket udførelse kan slette en database, ødelægge en implementering eller inficere dit system med malware.

Den gode nyhed er, at du i dag har flere måder at oprette en på. et isoleret miljø, hvor du kan prøve ting uden at tage risiciOg mange af dem er integreret i selve operativsystemet eller i platforme designet til kodeagenter. Vi kalder dette "sandboxing": at køre kode inde i en slags kontrolleret boble, så selvom noget går galt eller er skadeligt, er skaden inddæmmet.

Hvad er manuel sandboxing uden yderligere software?

Inden for sikkerhed og udvikling betyder det at tale om sandkasser at tale om... at definere klart, hvad et program eller en agent kan røre ved, mens det kørerDet handler ikke bare om at "køre det et andet sted", men om at definere klare grænser: hvilke filer det kan se, hvilke processer det kan starte, om det har et netværk, hvilke legitimationsoplysninger det kan bruge, hvor længe miljøet lever, og hvad der sker med dets tilstand, når det afsluttes.

Sondringen mellem "manuel" og "uden yderligere software" er misvisende. I mange tilfælde kan du stole på funktioner, der allerede er inkluderet i dit operativsystem eller din egen udviklingsplatformsåsom Windows Sandbox, Linux-primitiver (Landlock, seccomp) eller macOS-mekanismer. Du behøver ikke at installere en komplet virtualiseringspakke, men du skal lære at aktivere og administrere disse integrerede mekanismer at fungere som en barriere mellem den kode, du vil teste, og din faktiske maskine.

Hvorfor har kodeagenter brug for isolerede miljøer?

Moderne kodeagenter er ikke længere simple chatlignende assistenter, der foreslår kodestykker: de er udførelsesmiljøer koblet til en sprogmodelDe kan læse dit repository, redigere filer, køre terminalkommandoer, installere pakker, bygge containere, kommunikere med eksterne API'er og endda åbne browsersessioner.

Platforme som Claude Code, nogle LangChain "Deep Agents" eller specifikke sandkasser distribueret af Docker og andre værktøjer beskriver eksplicit, at disse agenter De opererer på rigtige filsystemer, starter tråde og delegerer opgaver til specialiserede underagenter.Med andre ord, de minder meget om en juniorudvikler med adgang til dine værktøjer ... bare automatiseret og meget hurtigt.

I den sammenhæng ophører det primære sikkerhedsspørgsmål med at være "Reagerer den godt på prompten?" og bliver til: "Hvad er omfanget, når det er forkert, skævt justeret eller er blevet manipuleret?"Hvis en model for eksempel kan køre pytest, installere npm-pakker, administrere branches eller inspicere en kompileringsfejl, er det kun få skridt væk fra at røre ved implementeringsscripts, ændre Git-hooks eller eksfiltrere hemmeligheder til en fjerntjeneste.

Det nemme svar er normalt at kræve menneskelig godkendelse for hver kommando. Det hjælper, men det har et tilbagevendende problem: godkendelsestræthedI miljøer, hvor ingeniører starter mange agenter eller arbejdsgange parallelt, fører den store mængde anmodninger ofte til, at næsten alt godkendes uden omhyggelig gennemgang. Når over 90 % af tilladelsesanmodningerne accepteres automatisk, ophører denne mekanisme med at være en reel sikkerhedskontrol og bliver blot en formalitet.

Derfor er sandkasser så vigtige: De gør ikke modellen ufejlbarlig, og de korrigerer heller ikke instruktionsindsprøjtningen.Men de reducerer "eksplosionsradiusen" for dens fejl. Hvis AI'en laver fejl, eller nogen formår at kapre dens instruktioner, forbliver skaden begrænset til det isolerede miljø i stedet for at sprede sig direkte til dit produktionssystem eller din bærbare computer.

Hovedbegrænsninger i en kodeagent-sandkasse

En seriøs sandbox for kodningsagenter er afhængig af flere typer grænser, ikke bare "endnu en mappe" eller "endnu en container". Hver type dækker et forskelligt risikoaspekt, og det er vigtigt at forstå dem for effektiv manuel sandboxing med dine eksisterende ressourcer.

Filsystemgrænse

Det første er at beslutte sig. hvilket mappetræ kan agenten se og ændreI en korrekt konfigureret sandkasse bør agenten kun kunne læse og skrive til det arbejdsområde eller de volumener, du eksplicit opretter til den. Resten af ​​systemet (brugerens hjemmemappe, systemstier, andre projekter) bør være utilgængelige for den.

Agentframeworks og sandbox-platforme gør det meget klart: sandboxen er barrieren, der forhindrer berøring af værtsfiler ud over det, der er deltI microVM-baserede modeller er reglen endnu strengere: kun den mappe, du monterer (ofte læse-skrive), krydser grænsen mellem den virtuelle maskine og værten. Alt andet forbliver utilgængeligt, medmindre du åbner den.

Procesgrænse og kerne

Den anden nøglegrænse er, hvad agenten ser på proces- og kerneniveau. Hvis det er inden for det isolerede miljø installerer tjenester, starter containere eller starter trådeAlle disse handlinger skal forblive indkapslet, uden at dele processer eller en bar kerne med værten.

Mange robuste sandkasseimplementeringer er afhængige af mikroVM'er eller lette virtuelle maskiner med deres egen Linux-kerne, forstærket med seccomp, cgroups, navnerum og jail-teknikker. Andre bruger lag som gVisor eller Kata Containers til at indskyde et virtualiserings- eller emuleringslag mellem den isolerede proces og nodens kerne. Grundideen: Hvis nogen udnytter noget indeni, er springet til værten meget vanskeligere end i en simpel container med delt kerne.

Netværksgrænse

Kodeagenter er ofte meget "netværksintensive": de vil installere afhængigheder, konsultere dokumentation, kalde LLM API'er, få adgang til eksterne arkiver eller endda surfe på nettet. Uden en klar politik kan et "isoleret" miljø ende med at blive en fantastisk dataudfiltreringstunnel.

Derfor indtager flere og flere platforme en holdning om standardafvisning af udgående trafikHTTP/HTTPS er blokeret undtagen i visse tilfælde, hvor TCP/UDP/ICMP er begrænset, og – meget vigtigt – adgang til private områder og lokale adresser er forbudt. Kommunikation er kun tilladt med værter eller domæner, der eksplicit er inkluderet på en tilladelsesliste, og ofte via en værtsstyret proxy.

Grænse for legitimationsoplysninger

Det er ikke til megen nytte at have agenten låst, hvis den inde i sit bur kan læse dine API-nøgler, implementeringstokens eller databasehemmeligheder. Det moderne design af mange sandkasser består af... Injicer aldrig rå hemmeligheder i det isolerede miljøFå i stedet en proxy på værten til at tilføje legitimationsoplysningerne til headerne på de HTTP-anmodninger, som sandkassen vil sende.

Med denne tilgang er processen i sandkassen Han bruger legitimationsoplysningerne, men ser dem aldrig.Dette reducerer i høj grad virkningen af ​​en potentiel agentkapring. Men i det øjeblik du gemmer en nøgle i en fil eller miljøvariabel i sandkassen, forsvinder denne fordel: modellen kan derefter læse den direkte, og enhver instruktionsinjektion kan beordre den til at filtrere den.

Livscyklusgrænse og tilstand

Endelig er der tidsgrænsen: Hvad bevares, og hvad ødelægges, når miljøet stopperAgenter er ikke engangsprocesser: de læser, kompilerer, fejlfinder, åbner adskillige hypoteser, opgiver nogle, genoptager andre... Dette kræver en runtime, der administrerer tilstanden intelligent: hurtig start, suspension, snapshots, forgrening og sikker sletning.

Nogle platforme tilbyder hukommelsessnapshots, puljer af forvarmede miljøer og forgreningsfunktioner fra en bestemt tilstand (for eksempel en allerede godkendt browser eller en delvist opløst afhængighedsgraf). Dette er forskellen mellem en brugbar agent – ​​en der kan iterere interaktivt – og en agent, der bruger evigheder på at gentage den samme opsætning igen og igen.

Sandboxing-implementeringer på macOS, Linux og Windows

Ud over kommercielle produkter har mange teams valgt udnytte isolationsprimitiver, der allerede findes i operativsystemer at bygge deres egne sandkasser til kodeagenter uden at tilføje tungere lag. Nøglen er at forstå, hvad hver platform kan tilbyde.

Sandboxing på macOS: Sikkerhedssele og dynamiske profiler

Flere modeller er blevet evalueret på macOS: App Sandbox, containere, virtuelle maskiner og Seatbelt. De første muligheder har betydelige ulemper for et udviklingsmiljø: App Sandbox kræver signering af alle binære filer, som agenten måtte udføre og arver firmaets tillid, hvilket åbner op for vektorer for misbrug, hvis agenten selv genererer eller ændrer binære filer; containere er begrænset til Linux-økosystemet; traditionelle VM'er tilføjer en masse opstartslatenstid og hukommelsesforbrug.

Det praktiske alternativ har været at stole på Sikkerhedssele, tilgængelig via sandbox-execSelvom Apple har markeret det som forældet i årevis, bruges det stadig af kritiske applikationer som f.eks. ChromeDet giver dig mulighed for at køre kommandoer under en sandkasseprofil, der begrænser opførslen af ​​hele det efterfølgende procestræ.

Den profil definerer tilladelser med stor granularitet: Den kan filtrere specifikke systemopkald og læse eller skrive til specifikke filer og mapper.ved hjælp af et særligt politiksprog. Der findes implementeringer, der genererer denne politik dynamisk under kørsel, og som kombinerer arbejdsområdekonfiguration, administratorpolitikker og brugerignoreringsfiler, så agenten har manøvrerum uden at berøre farlige områder.

Sandboxing på Linux: Landlock og seccomp

Linux tilbyder både mere fleksibilitet og mere arbejde: kernen eksponerer primitiver som f.eks. Landlock og seccompMen det er brugerrummets ansvar at kombinere dem til en sammenhængende og håndterbar sandkasse.

I stedet for udelukkende at stole på eksterne projekter, vælger nogle teams at Brug seccomp direkte til at blokere systemkald, der anses for farlige. og Landlock for at begrænse adgangen til filsystemet. Et almindeligt mønster involverer montering af brugerens arbejdsområde oven på et filsystemoverlay og Erstat filerne markeret som ignoreret med særlige kopier beskyttet af Landlockså den isolerede proces ikke kan læse eller ændre noget, du rent faktisk vil skjule.

Den langsomste del af denne fremgangsmåde er normalt at finde og samle alle disse filer igen, da Linux tilbyder ikke en nem måde at finde den fulde sti til en fil i et seccomp-bpf-filter.Alligevel er resultatet en ret fin sandkasse: agenten kan arbejde med sit projekttræ, mens de forbudte stier de facto er uden for dens univers.

Sandboxing på Windows: afhængighed af WSL2

I Windows er historien anderledes. Det er meget mere kompliceret at oprette en generel, native sandbox, fordi De fleste eksisterende isolationsprimitiver er designet til browsere eller anden meget specifik softwareog de passer ikke godt sammen med alsidige udviklingsværktøjer.

En praktisk løsning er Kør en Linux-sandkasse i WSL2På denne måde genbruger du Linux' isolationsværktøjer (Landlock, seccomp, navnerum osv.) på en virtualiseringsbase, der isolerer udviklingssessionen fra Windows-værten. Samtidig koordineres der et samarbejde med Microsoft for at eksponere nye primitiver, der i sidste ende vil muliggøre mere native sandboxing til udviklingsværktøjer.

Windows Sandbox: et isoleret rum integreret i systemet

For dem, der bruger Windows 10 eller 11 i Pro-, Enterprise- eller Education-udgaver, er der et særligt interessant værktøj: Windows SandkasseDet er en let virtuel maskine integreret i selve systemet, der giver dig mulighed for at køre upålidelige applikationer eller mistænkelige filer i et engangsmiljø.

Ideen er enkel: Når du åbner Windows Sandbox, starter den et midlertidigt, rent Windows-skrivebord, som om det var nyinstalleretAlt, hvad du kopierer eller installerer i den – programmer, dokumenter, scripts – eksisterer kun i den instans. Hvis du lukker vinduet, ødelægges miljøet: software, filer og tilstand kasseres, og næste gang starter du forfra.

Nøglefunktioner i Windows Sandbox

Denne funktion leveres med flere meget nyttige egenskaber til manuel sandboxing uden at være afhængig af tredjepartsværktøjer:

• En del af WindowsAlt hvad du behøver er allerede inkluderet i de kompatible udgaver (Pro, Enterprise, Education). Du behøver ikke at downloade images eller vedligeholde eksterne virtuelle maskiner.
• Engangsbrug og perfektHver kørsel er lige så ren som en frisk Windows-installation. Intet af det, du foretager dig indeni, gemmes på din enhed, når du lukker miljøet.
• Sikker i designDen bruger hardware-understøttet virtualisering (Hyper-V) til at isolere sandbox-kernen fra værtskernen. Den bruger Microsofts hypervisor til at holde de to verdener adskilte.
• effektivOpstarten er hurtig, på få sekunder, med intelligent hukommelsesstyring og virtuel GPU-understøttelse, der bruger færre ressourcer end en traditionel VM.

Teknisk set opfører det sig sådan her en lille engangs Windows virtuel maskine, perfekt gyldig til test af installationsprogrammer, besøg af tvivlsomme websteder eller åbning af e-mailvedhæftninger, som du ikke har tillid til at køre på dit rigtige system.

Praktiske scenarier for brug af Windows Sandbox

Der er flere typiske scenarier, hvor Windows Sandbox er en fremragende manuel sandbox-løsning:

• Prøv ukendt softwareNår du downloader et program eller en eksekverbar fil fra internettet, og du ikke er sikker på dets oprindelse, kan du først installere det i Windows Sandbox og se, hvordan det opfører sig uden risiko for din computer.
• Sikrere websurfing: for Besøg af potentielt farlige websteder, malware- eller phishing-siderDu kan åbne din browser inde i sandkassen. Hvis noget går galt, vil blot lukning af vinduet fjerne eventuelle spor.
• Åbning af vedhæftede filer og filer, der ikke er tillid tilHvis du modtager en mistænkelig vedhæftet fil eller en ZIP-fil, der ikke vækker tillid, kopierer du den til sandkassen, åbner den der, og når den er gennemgået, beslutter du, om det er værd at udpakke noget til dit rigtige system.
• Demonstrationer og specifikke værktøjstestsDet er perfekt til at oprette softwaredemoer, teste forhåndsvisninger, udvidelser eller tilføjelser uden at overbelaste din hovedinstallation.
• Vedligehold flere separate udviklingsmiljøerDu kan oprette separate, isolerede rum for hver sprogstak eller version, for eksempel en sandkasse for hver version af Python og dens afhængighederså eksperimenterne ikke forstyrrer dit stabile miljø.

Krav og licenser til brug af Windows Sandbox

Ikke alle kan bruge Windows Sandbox, men det er allerede tilgængeligt i mange professionelle miljøer. For at aktivere det på din computer skal du bruge:

• Kompatibel Windows-udgaveWindows 10/11 Pro, Enterprise, Pro Education/SE eller Education. Home-udgaven understøttes ikke.
• VirtualiseringsunderstøttelseDet er essentielt at have virtualiseringsfunktioner i BIOS/UEFI (Intel VT-x, AMD-V eller tilsvarende).
• Minimum ressourcermindst 4 GB RAM (selvom 8 GB anbefales), 1 GB ledig diskplads — helst SSD — og mindst 2 CPU-kerner (ideelt set 4 med hyperthreading).
• Opdateret operativsystemStartende med visse builds (for eksempel Windows 10 build 18305 og nyere, og moderne builds af Windows 11). På ARM64 kom kompatibilitet med nyere builds.

Angående licenser, Pro-, Enterprise- og Education-udgaverne inkluderer retten til at bruge Windows Sandbox Du behøver ikke at betale for yderligere licenser til virtualiseringssoftware. Bare aktiver det, og så er du klar.

Sådan aktiverer du Windows Sandbox uden ekstra værktøjer

For at få det op at køre, behøver du ikke noget ud over selve systemet:

1. Åbn Start-menuen, og søg efter indstillingen "Slå Windows-funktioner til eller fra".
2. Markér på listen over funktioner Windows-sandkasse og bekræft.
3. Genstart computeren, når du bliver bedt om det.
4. Efter genstart skal du søge efter "Windows Sandbox" i Start-menuen og køre den.

Hvis du foretrækker en mere teknisk tilgang, kan du også aktivere den med PowerShell ved hjælp af kommandoen Aktiver-WindowsOptionalFeature -FeatureName “Containere-DisposableClientVM” -Alle -Onlineforudsat at du har administratorrettigheder. Når sandkassen er aktiveret, vil den altid være tilgængelig, når du har brug for den sikre "anden maskine".

Konfigurations- og tilpasningsfiler

Windows Sandbox-understøttelser enkle konfigurationsfiler, der giver dig mulighed for at tilpasse bestemte miljøparametreFor eksempel montering af værtsmapper i læse- eller læse-skrive-tilstand, deaktivering af netværket, kørsel af scripts ved opstart osv. Disse filer er tilgængelige fra specifikke builds af Windows 10 og 11.

I praksis hjælper denne funktion dig med at oprette sandkasse-"opskrifter": en netværksdeaktiveret konfiguration til at åbne malwareEn anden med en projektmappe monteret i skrivebeskyttet tilstand til gennemgang af filer, eller en softwaretestorienteret konfiguration med bestemte værktøjer forudinstalleret i basisbilledet.

Sådan lærer du AI-agenter at bruge sandkassen korrekt

En sandkasse er kun virkelig effektiv, hvis Selve kodeagenten forstår det miljø, den opererer i. og ved, hvornår den kan operere frit, og hvornår den har brug for yderligere tilladelse eller menneskelig assistance.

For at opnå dette har mange platforme været nødt til at revidere den infrastruktur, der beskriver værktøjerne til modellen, grundigt. For eksempel har de opdateret beskrivelserne af shell-værktøjer for tydeligt at forklare:

• Hvilke begrænsninger pålægger sandkassen? (adgang til filsystemet, git, netværk).
• Hvordan kan agenten anmode om en opgradering af tilladelser når noget fejler på grund af manglende privilegier.
• Hvilke typer kommandoer er mest sandsynlige at blive blokeret?

Disse ændringer er ikke altid perfekte første gang: det kræver normalt Omfattende manuel testning af reelle implementeringsflowsAnalyse af, hvor modellens forventninger bryder sammen, og justering af prompts og instruktioner. Ved at måle adfærd med og uden en sandkasse i interne benchmarks identificeres fejlmønstre, såsom agenter, der De gentager den samme kommando i en løkke, som sandkassen blokerer. i stedet for at forstå, at de skal anmode om andre tilladelser eller ændre deres strategi.

En praktisk forbedring skal ses i værktøjets resultater den specifikke årsag til blokeringen, som sandkassen har pålagt og endda eksplicit foreslå agenten, at den anmoder om udvidede tilladelser, når det er relevant. Dette lille hint reducerer drastisk blinde genforsøg og forbedrer gendannelse fra isolationsrelaterede fejl, både i offlinetest og produktion.

For at sikre, at sandkassen ikke forringer brugeroplevelsen, har mange virksomheder valgt udrulle det gradvistIndsamling af intern og ekstern feedback, før den aktiveres som standard. Dataene er normalt klare: en betydelig del af anmodningerne (f.eks. omkring en tredjedel) ender med at køre i en sandkasse på kompatible platforme, med bemærkelsesværdige reduktioner i både ventetid på godkendelse og manuel gennemgangstid.

Isolationsmodeller og sikkerhedslektioner fra den virkelige verden

I praksis findes der ikke én "perfekt sandkasse". Der er vigtige forskelle mellem en delt kernecontainer, en gVisor-lignende sandkasse, en microVM og en fuld VMDen nuance er vigtig, når vi taler om at tillade agenten at køre Docker, installere vilkårlige pakker eller endda starte komplekse browsere og tråde.

Historiske sikkerhedshændelser understreger vigtigheden af ​​at vælge klogt: sårbarheder som f.eks. CVE-2019-5736 eller CVE-2024-21626, som tillod hop fra containeren til værten eller manipulation af systembinære filer, viser, at når din tillidsgrænse er en container-kørselstid på værtens kerne, kan en alvorlig fejl nedbryde hele barrieren.

Dette bliver mere følsomt med kodende agenter, fordi de ofte udfører upålidelig kompileringskode, opbygning af billeder, installation af afhængigheder uden revision og håndterer generelt meget heterogene input. Desuden er presset for at "give dem mere magt" stærkt: hvis de ikke kan bruge bestemte værktøjer, mislykkes de ofte med at fuldføre deres opgaver.

Derfor har mange moderne agent-sandkassedesigns en tendens til at forstærk grænsen ved hjælp af mikro-VM'er eller letvægts-VM'erDette sker på bekostning af en let øget kompleksitet. Direkte afhængighed af værtskernen reduceres, og der opnås et ekstra lag af isolation mod container-escapes. I miljøer med flere lejere eller storstilet udførelse af upålidelig kode indtager gVisor eller Kata Container en mellemvej og bytter kompatibilitet for større isolation.

Menneskelig godkendelse, politisk godkendelse og sandkasser: hvordan man får det hele til at passe sammen

Et mønster, der gentages overalt, er, at Ansøgninger om flerårige tilladelser skaleres ikke godtI demotilstand er det fint for agenten at anmode om tilladelse, før vedkommende rører ved en fil. I produktion, med semi-autonome arbejdsgange og mange små handlinger, ender "klik på OK for alt"-modellen med at blive en si.

Den mere modne tilgang kombinerer flere lag:

• Stærk sandkasse for at beskytte værten og afgrænse udførelsesmiljøet.
• Restriktiv netværkspolitik at kontrollere, hvilke slutpunkter agenten kan kommunikere med.
• Administration af legitimationsoplysninger via proxyså modellen bruger dem uden at se dem.
• Versionsbaserede konfigurationer på projektniveau (tilladelser, hooks, eksterne servere), så teams har én sandhedskilde i repository'et.
• Skrivebeskyttede underagenter til udforskning og planlægning, hvor skrivehandlingerne overlades til mere kontrollerede instanser.
• Menneskelig godkendelse forbeholdt virkelig delikate handlinger: udgivelse af pakker, ændringer i infrastruktur, roterende hemmeligheder eller pushing til kritiske grene.

Derudover er det værd at overveje kontrolflade som du giver agenten dine egne konfigurationsfiler, plugins og færdigheder. Vejledninger fra udbydere som OpenAI advarer tydeligt om, at det at eksponere åbne kataloger over funktioner eller at tillade nogen at definere effektive instruktioner i arkivet kan føre til datalækager eller destruktive handlinger, hvis en angriber formår at injicere ondsindede instruktioner i README-filer, problemer, dokumentation eller eksempelfiler.

I et lyddesign ses sandkassen ikke som et magisk trick, der fikser sikkerheden med ét hug, men som endnu en grænse inden for en arkitektur, der inkluderer politikker, uafhængig verifikation, omhyggelig håndtering af hemmeligheder og konfigurationsgennemgangeSelv hvis man antager, at agenten en dag læser ondsindede instruktioner og adlyder dem, er systemet designet til at begrænse virkningen: ingen direkte adgang til nøgler, intet åbent netværk og ingen mulighed for i al hemmelighed at ændre scripts, som du derefter kører på din rigtige maskine.

I sidste ende involverer det at opsætte en god manuel sandkasse uden at være afhængig af ekstra software... Få mest muligt ud af, hvad macOS og Linux allerede tilbyder dig. —Seatbelt-, Landlock- og seccomp-profiler, Windows Sandbox og WSL2— kombineret med klare netværksregler, legitimationsoplysninger og miljølivscyklusstyring. Tilføj dertil agenter, der er trænet til at forstå disse begrænsninger, rimelige politikker og en vis disciplin med hensyn til, hvad de har adgang til i dit arbejdsområde, og du kan teste risikabel kode, værktøjer og filer med langt større ro i sindet, velvidende at hvis noget går galt, vil problemet forblive indeholdt i sandkassen og ikke ødelægge dit system eller kritiske data. Del informationen, så flere brugere kan lære om emnet.