Amazon publiserte Rex (Trusted Remote Execution) på GitHub under Apache 2.0. Runtime-en kjører Rhai-skripts i en sandkasse uten direkte vert-tilgang. Hver gang skriptet vil åpne en fil, slå opp et hostnavn eller starte en prosess, må kallet først passere en Cedar-policy. Avslag gir authorization-feil, ikke en halvveis utført operasjon.
Det vanlige problemet med automatiseringsskripts er at de arver miljøets tillatelser. Et skript ment for å lese en loggfil kan også slette den, hvis brukeren som kjører det har skrive-tilgang. Rex bryter denne arven: skriptets tiltenkte handlinger er én ting, vertsens tillatelser en helt annen, og policy-laget i midten må eksplisitt godkjenne hver bro.
«Dette er spesielt viktig for KI-agenter, der skripts kan genereres dynamisk uten menneskelig gjennomgang av hvert systemkall. Problemer kan oppstå fra hallusinert kode, prompt injection eller for vid tolkning av oppgaven.» — Amazon, prosjekt-dokumentasjonen
Under panseret bruker Rex Cedar (Amazons egen policy-språk som også driver Verified Permissions i AWS) for å beskrive hva skriptet får lov til. Selve Rhai-motoren har ingen innebygd I/O; alt går gjennom Rust-baserte API-er som runtime-en eier. Rex bruker også fildeskriptorer i stedet for stier der det er mulig, for å redusere symlink-angrep og race conditions.
Hva bør du gjøre?
- Installer og test lokalt:
cargo install rex-runnerpå Linux eller macOS, skriv en minimal Cedar-policy som tillater lesing av én katalog, og prøv å få et skript til å bryte den. - Vurder Rex som mellomlag for agentiske verktøy: Hvis du bygger en agent som kjører kode-genererte skripts, kan Rex erstatte ad-hoc subprocess-kall der du i dag stoler på at LLM-en oppfører seg.
- Sammenlign med eksisterende sandboxes: Bubblewrap, Firecracker og Deno gir prosess- eller VM-isolasjon. Rex jobber på operasjonsnivå med policy-språk, så bruksområdene overlapper bare delvis.