ATechGuy

This is very useful. Thanks for sharing!

+1

You built https://github.com/FootprintAI/Containarium for this purpose?

TBH, this looks like an LLM-assisted response.

+1. It is confusing.

And how are you going to define what ocaps/flows are needed when agent behavior is not defined?

Interesting. I'd appreciate an example. Thanks!

Would love to see performance numbers with nested virtualization, particularly that of IO-bound workloads.

> a website can expose functions like searchProducts(query, filters) or orderPrints(copies, page_size) with full parameter schemas

How would this not create backend load and abuse?

That's a good start I'd say, but I agree with you that detection is not trivial. I wonder if there's enough value in distinguishing between AI agents (with full browser) and humans. What use cases would it enable?

Yes, but how can you tell if it was an agent with full browser?

Thanks for your insights!

QQ: does uxwizz also show AI agents visiting websites? have you seen traffic from AI agents?

I agree. However, how to define these permissions when agent behavior is undefined?

I understand the concern. However, you can customize the profile (e.g., allowlist) to only allow network access to required domains. Also, looks like your sandboxing solution is Docker based, which uses VMs on a Mac machine, but will not use VMs on a Linux machine (weak security).

That's right. But they (E2B) rely on the underneath Cloud infra to achieve high scalability. Personally, I'm still not sure about the value they add on top of Cloud hosted VMs. GCP/AWS already offer huge discounts to startups, which should be enough for VM-based sandboxing of agents in the MVP phase.

To the commenters here: thanks for correcting me! So AWS is losing AI sandboxing market to GCP due to high cold start times of EC2...very interesting!

You can customize curr_dir_access_profile.sb to block access to network/fs/etc. Why is this not enough?

sandbox-exec -f curr_dir_access_profile.sb markdownlint

Curious to know what made you DIY this?

These are all wrappers around VMs. You could DIY these easily by using EC2/serverless/GCP SDKs.

> we offer secure cloud VMs that scale up to 100k concurrent instances or more.

High scalability and VM isolation is what the Cloud (GCP/AWS, that E2B runs on) offers.

> I feel more in control of what's being exposed and how

Makes complete sense. Thanks for your insights!

I'm not saying sandboxes are not needed, I'm saying VMs/containers already provide the core tech and it's easy to DIY a sandbox. Would love to understand what value E2B offers over VMs?

I will ask what I've asked before: how to know what resources to make available to agents and what policies to enforce? The agent behavior is not predefined; it may need access to a number of files & web domains.

For example, you said: > I don't expose entire /etc, just the bare minimum How is "bare minimum" defined?

> Inspecting the log you can spot which files are needed and bind them as needed. This requires manual inspection.

In the last one year, we have seen several sandboxing wrappers around containers/VMs and they all target one use case AI agent code execution. Why? perhaps because devs are good at building (wrappers around VMs) and chase the AI hype. But how are these different and what value do they offer over VMs? Sounds like a tarpit idea, tbh.

Here's my list of code execution sandboxing agents launched in the last year alone: E2B, AIO Sandbox, Sandboxer, AgentSphere, Yolobox, Exe.dev, yolo-cage, SkillFS, ERA Jazzberry Computer, Vibekit, Daytona, Modal, Cognitora, YepCode, Run Compute, CLI Fence, Landrun, Sprites, pctx-sandbox, pctx Sandbox, Agent SDK, Lima-devbox, OpenServ, Browser Agent Playground, Flintlock Agent, Quickstart, Bouvet Sandbox, Arrakis, Cellmate (ceLLMate), AgentFence, Tasker, DenoSandbox, Capsule (WASM-based), Volant, Nono, NetFence

> allowNet: ["api.openai.com", "*.anthropic.com"],

How to know what domains to allow? The agent behavior is not predefined.

What about VMs? They offer strong isolation, as they don't share kernels, and have long been a foundational piece for multi-tenant computing. Then, why would we put an extra layer on top and rebrand it as an AI agent sandboxing solution? I'm genuinely curious what pushes everyone to build their own and launch here Is it one of those tarpit ideas: driven by own need and easy to build?

Congrats on launching, and great testimonials!

What problem does it solve compared to bazillion code execution sandboxing agents (and containers/VMs)?

Overall, a lot of people are building their own code execution sandboxing agents around containers/VMs. Curious to know what's missing that makes people DIY this?

Here's my list of code execution sandboxing agents launched in the last year alone:

1. E2B 2. AIO Sandbox 3. Sandboxer 4. AgentSphere 5. Yolobox 6. Exe.dev 7. yolo-cage 8. SkillFS ERA Jazzberry Computer Vibekit Daytona Modal Cognitora YepCode Run Compute CLI Fence Landrun Sprites pctx-sandbox pctx Sandbox Agent SDK Lima-devbox OpenServ Browser Agent Playground Flintlock Agent Quickstart Bouvet Sandbox Arrakis Cellmate (ceLLMate) AgentFence Tasker

> They fail because the environment is flaky: missing deps, slow setup, weird state, unclear feedback loops.

Why can't agents install missing deps based on the error message?

> There's no "OAuth for syscalls" yet.

This exists today in OSes in form of discretionary/mandatory permissions (e.g., SELinux, AppArmor, LandLocked).