_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.

the simplest one (and the one we're targetting) is multi-tenant services. You want to sandbox your service so that it doesn't affect the rest of the services running.

<shameless plug> We're building a container runtime to do this, and we are comparing alternatives, that's how we got there: https://github.com/urunc-dev/urunc</shameless plug>

well, the tricky detail here (which we do not mention in the post, our bad) is that we got the raspbian config (cp /boot/config ... .config && make oldconfig) which includes most modules, and that's why it took more.

But yeap, good point about using the -j flag, it really accelerates the build!

thanks, good to know!

indeed! thanks for that. Could it be a malformed SEO/robots whatever these things are called from our website?

thanks for your comment & suggestion!

I'll drop the HN admins an email to make sure I'm not missing anything.

data corruption, since fsync on the host is essentially a noop. The VM fs thinks data is persistent on disk, but it’s not - the pod running on the VM thinks the same …

well, indeed -- we should have found the proper parameters to make etcd wait for quorum (again, I'm stressing that it's a single node cluster -- banging my head to understand who else needs to coordinate with the single node ...)

well, the actual issue (IMHO) is that this meta-orchestrator (karmada) needs quorum even for a single node cluster.

The purpose of the demo wasn't to show consistency, but to describe the policy-driven decision/mechanism.

What hit us in the first place (and I think this is what we should fix) is the fact that a brand new nuc-like machine, with a relatively new software stack for spawning VMs (incus / ZFS etc.) behaves so bad it can produce such hiccups for disk IO access...

https://gvisor.dev/docs/architecture_guide/performance/#star... should be pretty close, according to the numbers reported in the official docs. Essentially, it depends on what the workload does.

indeed! virtio helps us tailor the transport layer to an acceleration use-case, rather than just frames to be transmitted or blocks to be completed. The interesting turn on vAccelRT (of the runtime system that is) is that apart from the simplicity for running on a VM that the virtio backend gives, it seems that people are eager to use the vAccelRT mechanism, to map a complicated piece of code to a simple function call that is hardware agnostic. We'll see how this will turn out...

After all, API remoting is out there for quite some time (see rCUDA); some people are using it, but we think that a more general, semantic abstraction needs to be introduced... especially for the Serverless use-case.

the virtio-accel frontend is a kernel module. The backend is VMM specific, so there is one for QEMU and one for AWS Firecracker. Check out https://blog.cloudkernels.net/posts/vaccel_v2/ to give it a try and let us know your thoughts!