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

yeap, the initial idea was to cover VMs (and one of the use cases is indeed Serverless, for instance AWS Firecracker), but as it turns out, there are users that might benefit from this simplified abstraction in general.

thanks for your feedback! we will try to clarify things on our next posts!

in short vAccel is a framework that translates function calls from users (upper side of this diagram) to the relevant functions of the respective acceleration framework (lower side of the diagram). For instance, calling a function like image_classify (user function) would result in the respective image_classify of jetson-inference, which would, in turn, execute the image classification function on the GPU and return the result to the user.

hope that makes more sense!

More info on how we use it on AWS Firecracker is available on our blog post: https://blog.cloudkernels.net/posts/vaccel_v2/ and our github pages: https://github.com/cloudkernels/vaccelRT, https://github.com/nubificus/docker-jetson-inference

built a stock ubuntu (cloud-init ready) image: https://cloudkernels.net/ubuntu-18.04.2-preinstalled-server-... sha1sum: 0b1d8b72ea5410fb7928925fd76dd0218b4f7a94

The behaviour should be identical to installing on a RPi3 (user/pass ubuntu/ubuntu, ethernet networking setup correctly etc.)

there is a number of factors to consider when comparing this kind of technologies.

Linux containers provide native performance for almost all applications, true; but there are tons of implications when it comes to multi-tenancy (security, QoS, trusted execution etc.).

Moreover, spawning an application as a docker container can incur significant overhead on startup time, fs setup, FS access etc.

So in theory yes, containers provide native performance. But do we really want to run apps on multi-tenant edge devices as containers ? I would argue not necessarily ;)

agree, I'm just talking about the flexibility to build & deploy a workload in any device (cloud / edge). Think of it like "building your own buildroot image" vs. "docker build" based on busybox or alpine. In the first case you'll end up with exactly what you want, but you'll spend quite some time building it; in the latter case you'll have to mix & match various other stuff, but you'll end up executing the actual application a lot faster.

will do -- that was only a high-level run to make sure there's enough compatibility with our framework & tools to move forward.

stay tuned ;)

there you go: https://cloudkernels.net/rpi4-64-bit-kvm-docker.img.xz sha1sum: 1b96a6be5256182eaceb5894fb993c8ffce8c2a2

it's quite beefy, 2.5GB -- apologies for that. We should be able to craft a much smaller image based on the ubuntu server release. Apparently, something was off about mounting the root partition on the first boot, so we went with our original image.

definitely! that's our initial goal. Quantify the penalty and examine the trade-offs. Clearly, virtualizing workloads on such devices with standard VMMs/hypervisors isn't ideal. And we're working towards this direction; playing with the systems stack is what makes us tick, so, it will be a fun and (hopefully) useful adventure :D

sure! bare-metal would be awesome. But isn't it a shame not to take advantage of all the virtualization/containerization goodies out there? After all, the virtualization overhead nowadays is only referring to I/O (network & storage). CPU/MEM are being virtualized using hardware extensions at (near-)native speeds.