Agent-sandkasse

En agent-sandkasse er en indkapslingsgrænse for kode, hvis adfærd vælges under kørsel af en model, der kan tage fejl eller blive manipuleret. Trusselsmodellen antager derfor, at enhver kommando inden for grænsen kan være fjendtlig, og designspørgsmålet er, hvad kommandoen kan læse, skrive, afvikle og nå over netværket. Isolationsstyrken ligger på en skala. Sandkasser på procesniveau lægger kernepolitik på en almindelig proces: seccomp-bpf-filtre på systemkald og Landlock på Linux, uprivilegerede namespace-værktøjer som bubblewrap og Seatbelt-frameworket på macOS. Containere tilføjer namespaces og cgroups, men deler stadig værtens kerne, så en sårbarhed i kernen kan blive til et udbrud, en begrænsning NIST SP 800-190 gennemgår grundigt. gVisor indskyder en kerne i brugerrummet, der selv håndterer de fleste systemkald, og microVM'er som Firecracker giver hver arbejdsbyrde sin egen KVM-gæstekerne og starter på omkring 125 ms med få MiB hukommelsesoverhead, hvilket er grunden til, at mange hostede tjenester til kodeafvikling bruger dem.

Filsystempolitikken monterer typisk kun arbejdsmappen med skriveadgang, holder systemstier skrivebeskyttede og udelader bevidst steder med legitimationsoplysninger som ~/.ssh, ~/.aws eller browserprofiler. Netværkspolitikken er normalt udgående trafik afvist som standard med en tilladelsesliste håndhævet af en proxy, fordi blokering alene på IP-adresser overser exfiltration via DNS og endpoints bag CDN'er. Legitimationsoplysninger, opgaven reelt har brug for, bør være kortlivede og snævert afgrænsede, og nogle design eksponerer dem slet ikke inde i sandkassen, men lader udgangsproxyen indsætte dem i forespørgsler til godkendte værter. Kortlivethed betyder lige så meget som mure: en frisk sandkasse pr. opgave forhindrer vedvarende fodfæste, og snapshots gør det billigt at nulstille.

Claude Codes sandboxede Bash-værktøj viser en lokal implementering: det bruger Seatbelt på macOS og bubblewrap plus en proxy via socat på Linux og WSL2, tillader som standard skrivning i arbejdsmappen og sessionens temp-mappe og begrænser udgående trafik til tilladte domæner. Bemærk, at det ved manglende afhængigheder advarer og kører uden sandkasse, medmindre det er sat op til at fejle lukket, en detalje, som en revision bør tjekke.

Udbredte misforståelser: En sandkasse stopper ikke prompt injection, den begrænser skadens omfang, og den neutraliserer ikke misbrug af de kanaler, den tillader. En agent, der må pushe til GitHub, kan exfiltrere via et commit, og kode skrevet inde i sandkassen kan plante en ondsindet git-hook eller et CI-trin, der senere kører uden for den. Sandkassen er altså håndhævelsesmekanismen for mindste privilegium, supplerer menneske i løkken-godkendelse og mindsker den godkendelsestræthed, der opstår, når hver kommando kræver et klik.