_ananos_

@bugsense Agreed on OS-level sandboxing -- the paper actually argues it is not a sandbox at all. If the host kernel is in the trust path, you have a weaker boundary, and it does nothing for the credential problem either. Our definition starts at hardware-level isolation: the agent runs in a microVM, and everything it can touch crosses a host-mediated virtio boundary.

That boundary is where the credential story changes. The token, the policy engine, and the audit log live on the host side, where the agent cannot reach them. Guardrails inside the agent context (an app-layer "are you sure" wrapper, a system prompt) share the cage with the agent -- a prompt injection can talk its way around them. Guardrails on the trust boundary cannot be talked to at all. The sandbox does not decide whether a granted API call is being abused; it guarantees the thing that decides is out of the agent's reach.

To your actual question: we do neither extreme. Capabilities are deny-by-default and granted per investigation, scoped to endpoints, not "the network". Read paths flow freely -- that is most of an investigation anyway. Mutating calls are a small set, and remediation is proposed, not executed: the mutation goes through an approval step at the boundary. So yes, human gating for mutations. It stays practical because the mutating surface is small by construction.

On shadow environments: honestly, you mostly cannot mirror domain state. You cannot fork Stripe, or a customer's prod cluster, and diff the side effects. Where the substrate supports it we use dry-run / plan-apply, and the microVMs are checkpointed per step, so the agent's own state can be rewound cheaply. An external side effect, once committed, is the one thing no sandbox rewinds. Which is exactly why we keep that set small and gated at the boundary.

Sandboxing for Agentic Execution: A whitepaper with our take on the definition of Sandboxing!

CVE-2026-46316 ("ITScape"). Reported by Hyunwoo Kim (@v4bel). This post discusses the vulnerability and its mitigations at a conceptual level using already-public information: no gadget offsets, no heap-spray primitives beyond what the author's own write-up discloses.

thanks @anenefan -- we'll have to figure out what's wrong with our SEO I guess..

no ads on the website.

wasn't familiar with proot -- with a quick look I think proot is a fancy chroot -- which, in turn, is kind of "the first step" for a generic container.

to achieve the isolation that gvisor offers you would have to intercept syscalls, create a separate mount/user/net namespace etc.

regardless, I don't think proot is somehow related to gvisor ;)

a number of reasons -- power budget, form factor, experimenting as a testbed for more "elaborate" setups (like robotics combined with a low-end TPU like the coral, or a jetson nano)

consider that you can take advantage of all the cloud-native goodies, all wrapped up in a 10x5 box with 5-10W (or 25-30W if you consider jetson boards).

well, jokes aside, what you're describing, is kind of what a "secure" (with many air/literal quotes) MCP/Agentic architecture looks like :D

In this context we're experimenting with gvisor on various platforms, and we're preparing a demo for kubecon about a fine-grained sandboxing approach for AI agent tasks spawned from a sandboxed agent.

yeap -- compute would be nearly the same. I suspect you need some kind of I/O to make your compute useful (get input for the computation / produce output etc.) so, still, this would have a negative effect overall.