Sandboxes will be left in 2026. We don't need to reinvent isolated environments; not even the main issue with OpenClaw - literally go deploy it in a VM on any cloud and you've achieved all same benefits.
We need to know if the email being sent by an agent is supposed to be sent and if an agent is actually supposed to be making that transaction on my behalf. etc
This is very, very wrong, IMO. We need more sandboxes and more granular sandboxes.
A VM is too coarse grained and doesn't know how to deal with sensitive data in a structured and secure way. Everything's just in the same big box.
You don't want to give a a single agent access to your email, calendar, bank, and the internet, but you may want to give an agent access to your calendar and not the general internet; another access to your credit card but nothing else; and then be able to glue them together securely to buy plane tickets.
No, that's more capabilities than sandboxing. You want fine-grained capabilities such that for every "thread" the model gets access to the minimum required access to do something.
The problem is that it seems (at least for now) a very hard problem, even for very constrained workflows. It seems even harder for "open-ended" / dynamic workflows. This gets more complicated the more you think about it, and there's a very small (maybe 0 in some cases) intersection of "things it can do safely" and "things I need it to do".
Not really. One version of this might look like implementing agents and tools in WASM and running generated code in WASM, and gluing together many restricted fine-grained WASM components in a way that's safe but allows from high-level work. WASM provides the sandboxing, and you have a lot of sandboxes.
You’re repeating the parent commenters position but missing their point: we have isolated environments already, we need better paradigms to understand (and hook) agent actions. You’re saying the latter half is sandboxing and I disagree.
I think at least a few teams are working on information flow control systems for orchestrating secured agents with minimal permissions. It's a critical area to address if we really want agents out there doing arbitrary useful stuff for us, safely.
Well, the challenge is to know if the action supposed to be executed BEFORE it is requested to be executed. If the email with my secrets is sent, it is too late to deal with the consequences.
Sandboxes could provide that level of observability, HOWEVER, it is a hard lift. Yet, I don't have better ideas either. Do you?
The solution is to make the model stronger so the malicious intents can be better distinguished (and no, it is not a guarantee, like many things in life). Sandbox is a basic, but as long as you give the model your credential, there isn't much guardrails can be done other than making the model stronger (separate guard model is the wrong path IMHO).
I think generally correct to say "hey we need stronger models" but rather ambitious to think we really solve alignment with current attention-based models and RL side-effects. Guard model gives an additional layer of protection and probably stronger posture when used as an early warning system.
Sure. If you treat "guard model" as diversification strategy, it is another layer of protection, just like diversification in compilation helps solving the root of trust issue (Reflections on Trusting Trust). I am just generally suspicious about the weak-to-strong supervision.
I think it is in general pretty futile to implement permission systems / guardrails which basically insert a human in the loop (humans need to review the work to fully understand why it needs to send that email, and at that point, why do you need a LLM to send the email again?).
if you extend the definition of sandbox, then yea.
Solutions no, for now continued cat/mouse with things like "good agents" in the mix (i.e. ai as a judge - of course just as exploitable through prompt injection), and deterministic policy where you can (e.g. OPA/rego).
We should continue to enable better integrations with runtime - why i created the original feature request for hooks in claude code. Things like IFC or agent-as-a-judge can form some early useful solutions.
I think sandboxes are useful, but not sufficient. The whole agent runtime has to be designed to carefully manage I/O effects--and capability gate them. I'm working on this here [0]. There are some similarities to my project in what IronClaw is doing and many other sandboxes are doing, but i think we really gotta think bigger and broader to make this work.
That's why I'm developing a system that only allows messaging with authorized senders using email addresses, chat addresses, and phone addresses, and a tool that feeds anonymized information into an LLM API, retrieves the output, reverses the anonymization, and responds to the sender.
Why not bare-cloud? Esp with AI... in 10min or less an agent can deploy almost any stack to an optimal AWS setup for a fraction of the cost of any platform.
Angelo from Railway here, Railway runs our own metal for the sheer reason to preserve margins so we can run for perpetuity.
We're nuts for studying failure at the company and Heroku's margins was one of the things we considered to be one of the many nails in that coffin. (RIP)
It is fucking CRAZY how many cloud companies don't let you set a spending limit.
I had to hunt around for a host in a suitable geography with a spending limit, almost had to go on-prem (which will happen eventually, but not in the startup phase)
Waking up to bankruptcy because of bots out of your control visiting your website seems a little nuts. Adding some other bullshit on top (like cloudflare) seems even more nuts.
Yeah I can manage all that and have the machine stop responding when it hits a spending limit -- but why would I pay for the cloud if I have to build out that infrastructure?
1. Because people vote with their wallets and not their mouths, and most companies would rather have a cost accident (quickly refunded by AWS) rather than everything going down on a saturday and not getting back up until finance can figure out their stuff.
2. Because realtime cost control is hard. It's just easier to fire off events, store them somewhere, and then aggregate at end-of-day (if that).
I strongly suspect that the way major clouds do billing is just not ready for answering the question of "how much did X spend over the last hour", and the people worried about this aren't the ones bringing the real revenue.
> I strongly suspect that the way major clouds do billing is just not ready for answering the question of "how much did X spend over the last hour", and the people worried about this aren't the ones bringing the real revenue.
See: Google's AI studio. Its built on Google Cloud infrastructure so billing updates are slow which peeves users used to instant billing data with Anthropic and OpenAI.
> and the people worried about this aren't the ones bringing the real revenue.
It's this one. If you're in a position to refund a "cost accident", then clearly you don't have to enforce cost controls in real time, and the problem becomes much easier to achieve at billing cycle granularity; the user setting a cost limit is generally doesn't care if you're a bit late to best-effort throttle them.
People act like this is an easy problem. What should a cloud provider do when you hit your limit? Delete your files from storage? Kill your database instance? Automatically terminate your VMs? Erase your backups?
Which only reinforces someone just lit $60M on fire. It's trivial to do this and there are so many ways people do things, having the AI build custom for you is better than paying some VC funded platform to build something for the average
Sure but at least it protects against unauthorized free-for-all access on your host system. If you want to explicitly give it access to external APIs over the internet that's a risk you personally are taking. It's really smart to run something like this in a sandbox, especially in the current beta/experimentation phase.
reply