That's how Nvidia works. They make arrangements with lots of companies to produce demos that use Nvidia products, especially ones that Nvidia is about to announce. That gives them lots to show at GTC. Companies are happy to work with them because having your name said by Jensen adds three points to your stock price.
There's no such thing as anonymity in 2026, and the documentation[1] listing the collected telemetry uses weasel words like "such as" rather than providing a comprehensive list or just pointing to the source reference. For people who don't audit or turn off telemetry, why don't you?
I am happy the repo explicitly points out and provides a disable for the telemetry though, that's good enough for me.
It is not, nor of open source software in general.
In general, the saying is specifically in reference to services provided over the internet -gmail, youtube, whatever. Note that you don't have the right to modify them and share your own copies -they're closed source.
So no, it's not true of Linux, GNU, etc; it's an apples and oranges comparison.
There is no such thing. The mere act of making a network connection reveals things like your IP address (reveals your hosting provider or even your geolocation for residential/mobile IPs), days and times you use the software, your OS via TCP/IP stack fingerprinting, etc.
Israel was just caught doing an attack where Google ads would run JavaScript looking for known hardware identifiers from telemetry data they bought. When the ads showed on a target device, they would root you. Without you even interacting with the ad.
It doesn't have to be a specific concern. It's better to remove the option than to find out later that you've gotten burned by something you had no way to anticipate.
Don't take chances, give as little as possible. Better to assume you'll get burned somehow and leave it off.
Nvidia Openshell is absolutely awesome, great bundle of features in one spot. Im happy to see Nvidia seems to have accelerated on support here, I was kinda worried that as competing projects have popped up in the last 6mo that openshell would get google'd
That aside, the level of control is cool, almost too pedantic. It likely is only particularly useful for very nuanced enterprise requirements (probably what it's targeting). Most companies can be much more coarse with their permissions, and I think the agentic industry is moving away from k8s as a deployment platform.
same as a db, better to pay #x as much and have it hosted then to be wishing it was not your problem when it was down
and we may very well live in different versions of the world. i'm on the frontlines of startups so we move with the customer, rather than making customers move with us
Ours is all on-prem all over the country in our own internal small datacenters for regulatory, safety, security, and operational reasons. Provisioned and automated from bare metal. We also use those same images in cloud for something like a quorum situation, or maybe some data locality for a particular pinned workload.
But it's mostly us, in our stuff and at the enterprise edge.
This isn’t even the sandbox. It needs Docker or other virtualization. This seems to sit a level up and orchestrate sandboxes and access to network & resources. It’s a pretty heavy setup from what I can tell.
The AI labs have zero economic incentives to secure their agents. They just need to show what their maximum theoretical abilities are and convince you to hand over money for tokens which are then spent on a wasteful workflow or process.
And most people running containers are running a default docker/containerd setup, which does not actually isolate you from anything at all in the first place anyways.
But then it decides to exfiltrate all your shit even inside the container. Which is something I'm trying to lock down at work atm.
Everything needs to go through a proxy, whitelisted domains only, plus credential swapping/re-signing so that the agent never has the real credentials. Docker sandbox looks quite good (September) but I've been using iron proxy (if the author is reading this, fucking thank you bro!) to great effect.
I still haven't cracked "what if the agent decides to drop parts of your codebase somewhere it shouldn't" yet, but I'll figure it out.
Been thinking about this a lot lately, and it’s a surprisingly difficult problem.
All it needs is public access to anything it can have the tiniest effect on, and it can exfiltrate data. Something as simple as a read count on some obscure forum post would be enough, albeit very slow.
I am tackling this using the Lethal Trifecta principle.
The idea is that agents never have all parts of the trifecta, maximum 2: untrusted content, private data or network access.
Harness have network access by default since they are driven by their provider API, unless you use offline models. So that's a problem.
I am then passing around messages that are tagged trusted/untrusted and the engine can monitor if any agent in the project ever completes the Lethal Trifecta and thus, is vulnerable.
Usually this means for most workflows, the "work" gets done by an offline LLM after some input/classification stages. There's not many ways around it.
> Harness have network access by default since they are driven by their provider API
The harness needs network access, but the shell spawned by the harness that runs the agent's commands does not necessarily need it.
Having a bwrap etc managed by the harness (DSH does this, among others) lets you have tighter restrictions on the agent's shell than the harness. Then run the whole thing inside a VM with a private network, so you can add nft rules to let it dial out to your inference machine but not to the internet at large. It takes an afternoon to set up but gives some reasonable defence in depth.
It’s difficult in theory, impossible in practice. For example: any external code dependency could be a prompt injection, and lock files are only TOFU protection.
Yeah, exactly. I'd say it borders on almost unsolvable for any agent of reasonable complexity.
You see some of the vulnerability chains humans come up with and they're just insane.
Even scanning network data for sensitive strings (say matching against a codebase or data set it works on) is tough because you can only check so granularly before you get loads of false positives.
But maybe like a "rolling" sort of check would help with that, % of outbound data matching private dataset (which should be operated on but not transmitted) over time. That way it minimises what gets out while dealing with false positives. Some biz thresholds might be >20% of data others might be >0.5%. Hmm.
If you can make any request to the outside world you can exfiltrate data, period. You can even include data in the uri or headers and they will appear in logs.
That obviously includes talking with the provider.
If you want it secure, it has to be off the internet and on your own hardware.
I agree of course, but those things are all the more obvious ones you can start to attempt to prevent.
Stripping headers, not allowing other than GET requests. Only allows HTTPS etc, the list goes on.
My point was that even if you locked down an agent to only ever read a single forum, and only to be able to access other post URLs that are from that forum, and not allow any query parameters that aren’t necessary etc.
Even then you can be having the slightest public effect that can exfiltrate data - a read count on some old post. I know it’s wildly impractical, it’s more a thought experiment on how hard it it.
I've been thinking a lot about this problem. Also, I think like the idea might be to look at the issue with code mode. Like basically, we know that all agents can write bash and execute it and that is what agents default code mode is.
But like if you only allowed for example JavaScript code that could be executed in a WASM sandbox, then you would have better control instead of just locking down with proxies. Basically there would be a very large API, basically tools, that the agent would codemode execute. My guess is that this would need a tool router to optimize the loading of these into the context. But it would give you very fine control over what code execution can and cannot be done.
You would need a human reviewing every single action of the agent to prevent them from exfiltartimg data. There are just too many possible side channels for a predefined solution. I believe currently what you want is a locally hosted decision model scoring every agent action againt a set of rules with a human in the loop once the decision model isnt 'confident' the actions are harmless.
And once you're done, be sure to give them unfettered internet access, your credentials, and credit card info so that they can actually get stuff done.
I haven't gone to network filter and logger yet, but I'm running mine in a VM, using lima (https://lima-vm.io/) to make it painless. Works on Mac and Linux, has an untested Windows version.
smolvm has better bootup time (<200ms), secrets handling, and egress control compared to lima. Among other things like native branching/forking of the vm itself.
As for the rug pull concern, I'm committed to open source with 2 pieces of evidence.
1. oss license
2. Business model is accruing revenue from offering hosted service + inbound due to the open source project. The business model + open source is aligned.
vz limits how much you can control the guest memory(doesnt expose a way to do free-page-reporting), has pretty terrible dis/virtiofs performance, and i've had issue with high host cpu usage. that said, iirc colima can switch to a krunkit backend so it can avoid most of these. ymmv but on benchmarks vz was 2-5x worse on a bunch of different ops
My agentic workloads happen on two physical machines dedicated only to agentic workloads that share a VLAN with only eachother, with single token access to the specific repositories they are meant to push to and limited scope, hard limited credentials pulled from the hardware store on hardware token/fingerprint request only.
I view the safety around unmonitored agentic work in a similar way to how I view working with viruses or bacteria in a disease lab.
This stuff isn’t magic, it isn’t intelligent, but it is dangerous and needs to be handled with careful intent.
So far I've settled on one jumbo VM with many Incus containers inside. Nothing goes inside the VM that I can't afford for agents to exfiltrate. I've been really happy with this setup.
If you’re going to go through that much trouble to run Incus, then just use KVM, QEMU, Libvirt which has a ton of tooling around it. Arguably, I’m not an expert in Incus, but learning to use and it didn’t seem worth it when established solutions exist.
I think there’s something to be said for distributed systems that work equally well online and offline. I’ve built an issue tracker (or agent memory graph, if you will) that uses Git as its transport, with no central broker or service and eventual consistency.
That means agents can manage issues locally without needing network access to an external tracker, which could help with the sandboxing problem. U can then sync when it is deemed safe.
It’s free and MIT-licensed. It’s called Epiq on Github.
As an example I run opencode and anything related agent-related in its own dedicated KVM VM with its own LVM logical volumes for storage on a headless server. This has no access whatsoever to the personal data that lives on my laptop and workstation desktop PC. The VM gets periodically imaged and backed up, and is relatively easy to move between host machines if I need to.
One benefit of doing this is that I can leave it doing long term slow things with slow but capable LLMs on a truly 24x7 basis without worrying about it being interrupted by a laptop being closed/going to sleep, or workstation level software updates/reboots on my primary desktop PC.
Thanks for sharing this - I've been trying to do something similar but have not had success. Can you say a bit more about the details? What is your headless server running (Ubuntu Server?), how do you connect, how did you set up the KVM VM, how do you move it if necessary, etc? Thanks!
In my case it's a fairly boring proxmox server. The KVM VM started as a bare bones debian install and then I added xorg and xfce4 and the tiger vnc server. I have a GUI on it for when I want to use it that way (in screen dimensions that are a 1:1 mapping of the native resolution of my laptop for full screen VNC session), or of course I also talk to it by regular SSH session, and screen or tmux. The VNC server listens on 127.0.0.1:5901 and then I use SSH port forwarding from my workstation machine to connect the macos tigervnc client.
If I need to move it I can shutdown the VM and take an image of its LVM logical volume storage device (by something as rudimentary as like dd into an xz file), move the file, then create a new identically sized logical volume and do the reverse using dd to write from the file into the LVM logical volume location on the destination.
Depends what you mean with "agents"... LLMs in coding harnesses, or fully autonomous agents?
If you mean the former, I think you'll find probably 90% of devs are "crazy", running Claude Code or Codex on their bare metal using the auto-classifier.
I used to always run claude with `--dangerously-skip-permissions` in a dev container, but I had to rebuild my container 10 times a day to update the firewall so it can access documentation.
Now I find the included auto-classifier is very reliable. If you keep tasks contained instead of open-ended long-horizon work, it doesn't seem much goes wrong with frontier models. The worst unintended action claude did for me in the past months is that it once discarded an unstaged file which wasn't committed yet, without asking.
But I realize it's still playing with fire, no matter how good the auto-classifier is.
right now i am experimenting on an agent in a browser as a single.html file running a virtual filesystem and using python in WASM to do the heavy lifting. its really useful and funny to watch how it works.
it is quite useful and solves / addresses quite a lot of privacy and security issues but it is more limited of course. i really like the results if you want you can try it out with an inference endpoint you want its live/downloadable at
I was using it in an air gapped environment vs a local inference engine running a qwen-coder-next. Installtion of harnesses on the machine and other things were ruled out because of security constraints.
There i used it to analyze an old visual basic application which creates custom pdf files. it worked surprisingly well. it took some rounds but in the end it got all requirements and scaffolded me a skeleton for a python rewrite as a web-application. Then i worked from there with it to get a prototype.
They certainly are! Nvidia creates and maintains an awful lot of software. Selling GPUs is what gives them revenue but they produce a lot of software to generate additional pull through demand for their hardware.
In this vein, Anthropic's sandbox-runtime [0] has struck a good balance between security and convenience. Simple config, filesystem and network restrictions, and credential masking make me comfortable running Pi in YOLO mode.
Though I'm often running into frustrating (albeit intentional) sandbox restrictions with common workflows e.g. xcode/swift and Docker access.
Would love suggestions for how to give agents access to those kinds of tooling inside the sandbox, either with srt or an alternative (with similar convenience characteristics).
Think the strongest product nth space is https://github.com/nolabs-ai/nono for what it's worth. Plus it is a priority for that team so if you are having issues the no labs guys will likely fix it :)
One is microvms, the other is kernel-based. There are trade-offs between the two. One trade-off is that you have to put the data inside the sandbox if you are using a MicroVM. The other is that it is harder to contextually provide or change access to data in a microvvm sandbox. The final one is developer experience.
These techniques can actually be combined and will be combined in the long-term I think. You may have LSM-based sandboxes that exist in Docker-based sandboxes.
Do I miss it or you don't specify which VC you work for in your profile. How is that clear for people to make connections to companies in your portfolio?
Ah, thanks for flagging. That's a miss on my part and I apologize. Next time I will just be more clear that it is a portfolio company but also will add it to my profile.
Isn't using a sandbox provided by them giving you more restrictions though? At least in terms of accessing resources on the big 3 cloud bois?
Plus you're forced to move at their pace which is unfortunate sometimes. Granted Amazon's bedrock stuff is slow and disappointing but at least I can rejig it work in conjunction with other aws products.
And if you're prepared to not use anthropic but any cloud provider for your infra then you can do whatever you like elsewhere. Just use docker sandbox or iron proxy to replicate network control/cred swapping (iron even does sigv4 re-signing).
Critically, in the intended approach for this, Claude itself (the harness) runs outside the sandbox. Their approach means you trust Claude is perfect, just the commands it runs need isolation. And to some extent, you trust its judgement on what and when needs the isolation applied.
I know there are distinct camps here, and the long term story may evolve - but for now I just want the whole harness inside a sandbox - ideally, a full VM - and THEN you can further sandbox things it runs if you really want different tiers within that.
Well, I guess its time to shamelessly plug my agent sandbox, egzo.ai [1]
Looking at the complexity of OpenShell and the simplicity of just building on top of docker, in a whitelist only mode.. I don't quite get the use-case of OpenShell. May be for large orgs where there is so much legacy and difficulty in organizing access to tools, OpenShell can simply re-use whatever you already have access to on your corporate account.
I chose to build straight on top of docker and agents are simply fully sandboxed by default. All data and network access must be granted in a simple project file, docker-compose style.
The web-ui connects to the docker socket and lets you spawn agents, and connect terminals. I'm having lots of fun with it and it allows me to cleanly organize and isolate my projects.
End-goal is to monitor for the Lethal Trifecta [2], ensuring all individual agents are properly isolated. Not quite there yet.
Is it fair to immediately get the ick from the name and the description (OpenShell is the safe, private runtime for autonomous AI agents) without knowing anything about what it does?
"Open" and "Shell" and just calling something private and safe out the box genuinely makes me think it's likely to fail at all of those claims.
I tried to vibecode something similar last weekend. Got tripped up by Claude's safety classifier. It wouldn't let me build any features that track/audit process executions , not through custom kernel hooks nor even using off the shelf software for it.
Wow, interesting. My agents on open weight inference have been completely nerdsniped by the idea of tracking and auditing process executions. They talk of nothing else.
You terrorist. And internally they're doing biological warfare and terrorism simulations. For science, of course.
"The worry is that, while right now you need to be a skilled virologist to know what components to order or how to grow and spread a bioweapon, AI tools might eventually make it possible for a rogue state, or a rogue group, or an individual, to do all this without virology expertise.
For a while, Anthropic tested whether Claude could assist a terrorist in developing a biological weapon in the obvious way: It assigned testers who had, say, an undergraduate degree in chemistry but no real virology training to try to use Claude to plan an effective mass terror event. Then it scored the attempt by how close it might have come to success.
Early in 2026, it noticed that Claude, attempting the task by itself, did better than a human aided by Claude did at coming up with a workable plan."
Claude wouldn't let me make a DHCP client that would make 1000s of leases. But Gemini in the WebUI with 3.6 Thinking gave me a decent python script in one shot. I didn't realize testing DHCP servers was such a sensitive security issue.
Meanwhile, they're simulating bio warfare with their own, unaligned models 'just to see if they can do it'. And not a single person thinks 'hey, if that's possible, maybe we shouldn't be doing this at all'...
Because containers don't use Seccomp and Landlock and check filesystem/network calls against an externally applied policy along w/injecting credentials where needed as a man-in-the-middle, thus keeping the secrets out of reach from the LLM?
But they can no? With a sidecar and some docker network-fu.
I encountered the same challenge building my toy sandbox. I wanted to use containers because that's what I know best.
The harness is launched in an internal only network. There is a sidecar container that provides mitm credential injection/proxy. I got HTTPS and SSH to work so far.
Claude code was quick to build it. No doubt it's copying previous work in this space though, so I know my work is not that original.
I'm testing all the llms that can be used for pen testing right now to see if/how they manage to escape it. Without a kernel exploit I doubt it's possible (not a very high bar I know).
I'm researching the space. Happy to learn more. Some links in my profile if you're interested.
225 comments
[ 4.1 ms ] story [ 114 ms ] threadI had never heard about it before.
>To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm installs.
[1] https://github.com/NVIDIA/OpenShell/blob/ea13dfce411e8467ddb...
I am happy the repo explicitly points out and provides a disable for the telemetry though, that's good enough for me.
[1] https://docs.nvidia.com/openshell/latest/observability/telem...
It is not, nor of open source software in general.
In general, the saying is specifically in reference to services provided over the internet -gmail, youtube, whatever. Note that you don't have the right to modify them and share your own copies -they're closed source.
So no, it's not true of Linux, GNU, etc; it's an apples and oranges comparison.
There is no such thing. The mere act of making a network connection reveals things like your IP address (reveals your hosting provider or even your geolocation for residential/mobile IPs), days and times you use the software, your OS via TCP/IP stack fingerprinting, etc.
The network path between you and the telemetry endpoint is always listening, too: https://en.wikipedia.org/wiki/Room_641A
Don't take chances, give as little as possible. Better to assume you'll get burned somehow and leave it off.
Feel free to opt out maybe?
That aside, the level of control is cool, almost too pedantic. It likely is only particularly useful for very nuanced enterprise requirements (probably what it's targeting). Most companies can be much more coarse with their permissions, and I think the agentic industry is moving away from k8s as a deployment platform.
> I think the agentic industry is moving away from k8s as a deployment platform.
same as a db, better to pay #x as much and have it hosted then to be wishing it was not your problem when it was down
and we may very well live in different versions of the world. i'm on the frontlines of startups so we move with the customer, rather than making customers move with us
Ours is all on-prem all over the country in our own internal small datacenters for regulatory, safety, security, and operational reasons. Provisioned and automated from bare metal. We also use those same images in cloud for something like a quorum situation, or maybe some data locality for a particular pinned workload.
But it's mostly us, in our stuff and at the enterprise edge.
Different problems.
The economist literally called Nvidia the "Central Bank of AI". https://www.economist.com/interactive/briefing/2026/09/03/nv...
I'd argue that Nvidia is the biggest and most important AI company in the world.
[1] https://blog.google/innovation-and-ai/models-and-research/go...
Everything needs to go through a proxy, whitelisted domains only, plus credential swapping/re-signing so that the agent never has the real credentials. Docker sandbox looks quite good (September) but I've been using iron proxy (if the author is reading this, fucking thank you bro!) to great effect.
I still haven't cracked "what if the agent decides to drop parts of your codebase somewhere it shouldn't" yet, but I'll figure it out.
All it needs is public access to anything it can have the tiniest effect on, and it can exfiltrate data. Something as simple as a read count on some obscure forum post would be enough, albeit very slow.
The idea is that agents never have all parts of the trifecta, maximum 2: untrusted content, private data or network access.
Harness have network access by default since they are driven by their provider API, unless you use offline models. So that's a problem.
I am then passing around messages that are tagged trusted/untrusted and the engine can monitor if any agent in the project ever completes the Lethal Trifecta and thus, is vulnerable.
Usually this means for most workflows, the "work" gets done by an offline LLM after some input/classification stages. There's not many ways around it.
Yes, it's a difficult problem.
The harness needs network access, but the shell spawned by the harness that runs the agent's commands does not necessarily need it.
Having a bwrap etc managed by the harness (DSH does this, among others) lets you have tighter restrictions on the agent's shell than the harness. Then run the whole thing inside a VM with a private network, so you can add nft rules to let it dial out to your inference machine but not to the internet at large. It takes an afternoon to set up but gives some reasonable defence in depth.
How did you go about it?
But perfect is the enemy of better.
You see some of the vulnerability chains humans come up with and they're just insane.
Even scanning network data for sensitive strings (say matching against a codebase or data set it works on) is tough because you can only check so granularly before you get loads of false positives.
But maybe like a "rolling" sort of check would help with that, % of outbound data matching private dataset (which should be operated on but not transmitted) over time. That way it minimises what gets out while dealing with false positives. Some biz thresholds might be >20% of data others might be >0.5%. Hmm.
That obviously includes talking with the provider.
If you want it secure, it has to be off the internet and on your own hardware.
The timescale can be adjusted to a length suitable for sensitivity of the data.
Although you may run into the monkey and typewriter problem a bit if the period is indefinite.
Stripping headers, not allowing other than GET requests. Only allows HTTPS etc, the list goes on.
My point was that even if you locked down an agent to only ever read a single forum, and only to be able to access other post URLs that are from that forum, and not allow any query parameters that aren’t necessary etc.
Even then you can be having the slightest public effect that can exfiltrate data - a read count on some old post. I know it’s wildly impractical, it’s more a thought experiment on how hard it it.
GET foobar.com/thisissomeextracteddata
You can also imagine it being much subtle, encoded/encrypted, sent in small pieces to avoid detection, etc.
Firstly, the forum site I’m theorising here is not compromised.
Secondly, as I mentioned, in this situation I would limit the URLs it’s allowed to get.
You’d allow the top level of the forum index, and only then allow it to follow links within that site. “Thisissomedata” would be denied anyway.
All I meant was all of these complex limitations still don’t prevent exfiltration.
But like if you only allowed for example JavaScript code that could be executed in a WASM sandbox, then you would have better control instead of just locking down with proxies. Basically there would be a very large API, basically tools, that the agent would codemode execute. My guess is that this would need a tool router to optimize the loading of these into the context. But it would give you very fine control over what code execution can and cannot be done.
slim, fast, microvm that runs on every platform.
disclaimer: am author
I only heard about smolvm yet and they are YC, so I'm hesitant to use them as they will probably one day pull the rug.
As for the rug pull concern, I'm committed to open source with 2 pieces of evidence.
1. oss license 2. Business model is accruing revenue from offering hosted service + inbound due to the open source project. The business model + open source is aligned.
disclaimer: maintainer of smol machines
My agentic workloads happen on two physical machines dedicated only to agentic workloads that share a VLAN with only eachother, with single token access to the specific repositories they are meant to push to and limited scope, hard limited credentials pulled from the hardware store on hardware token/fingerprint request only.
I view the safety around unmonitored agentic work in a similar way to how I view working with viruses or bacteria in a disease lab.
This stuff isn’t magic, it isn’t intelligent, but it is dangerous and needs to be handled with careful intent.
If you’re going to go through that much trouble to run Incus, then just use KVM, QEMU, Libvirt which has a ton of tooling around it. Arguably, I’m not an expert in Incus, but learning to use and it didn’t seem worth it when established solutions exist.
I ask because I’ve found that as isolation increases, so does friction, and then of course capabilities.
That means agents can manage issues locally without needing network access to an external tracker, which could help with the sandboxing problem. U can then sync when it is deemed safe.
It’s free and MIT-licensed. It’s called Epiq on Github.
One benefit of doing this is that I can leave it doing long term slow things with slow but capable LLMs on a truly 24x7 basis without worrying about it being interrupted by a laptop being closed/going to sleep, or workstation level software updates/reboots on my primary desktop PC.
If I need to move it I can shutdown the VM and take an image of its LVM logical volume storage device (by something as rudimentary as like dd into an xz file), move the file, then create a new identically sized logical volume and do the reverse using dd to write from the file into the LVM logical volume location on the destination.
how am i gonna run a game and do all development inside docker...?
If you mean the former, I think you'll find probably 90% of devs are "crazy", running Claude Code or Codex on their bare metal using the auto-classifier.
I used to always run claude with `--dangerously-skip-permissions` in a dev container, but I had to rebuild my container 10 times a day to update the firewall so it can access documentation.
Now I find the included auto-classifier is very reliable. If you keep tasks contained instead of open-ended long-horizon work, it doesn't seem much goes wrong with frontier models. The worst unintended action claude did for me in the past months is that it once discarded an unstaged file which wasn't committed yet, without asking.
But I realize it's still playing with fire, no matter how good the auto-classifier is.
it is quite useful and solves / addresses quite a lot of privacy and security issues but it is more limited of course. i really like the results if you want you can try it out with an inference endpoint you want its live/downloadable at
https://moooff.github.io/HermitUI/hermit-agent/dist/hermit-a...
iam always open to discussion ad feedback of course
There i used it to analyze an old visual basic application which creates custom pdf files. it worked surprisingly well. it took some rounds but in the end it got all requirements and scaffolded me a skeleton for a python rewrite as a web-application. Then i worked from there with it to get a prototype.
Spyware
Unhelpful, I know
Though I'm often running into frustrating (albeit intentional) sandbox restrictions with common workflows e.g. xcode/swift and Docker access.
Would love suggestions for how to give agents access to those kinds of tooling inside the sandbox, either with srt or an alternative (with similar convenience characteristics).
[0] https://github.com/anthropics/sandbox-runtime
These techniques can actually be combined and will be combined in the long-term I think. You may have LSM-based sandboxes that exist in Docker-based sandboxes.
Plus you're forced to move at their pace which is unfortunate sometimes. Granted Amazon's bedrock stuff is slow and disappointing but at least I can rejig it work in conjunction with other aws products.
And if you're prepared to not use anthropic but any cloud provider for your infra then you can do whatever you like elsewhere. Just use docker sandbox or iron proxy to replicate network control/cred swapping (iron even does sigv4 re-signing).
I know there are distinct camps here, and the long term story may evolve - but for now I just want the whole harness inside a sandbox - ideally, a full VM - and THEN you can further sandbox things it runs if you really want different tiers within that.
Looking at the complexity of OpenShell and the simplicity of just building on top of docker, in a whitelist only mode.. I don't quite get the use-case of OpenShell. May be for large orgs where there is so much legacy and difficulty in organizing access to tools, OpenShell can simply re-use whatever you already have access to on your corporate account.
I chose to build straight on top of docker and agents are simply fully sandboxed by default. All data and network access must be granted in a simple project file, docker-compose style.
The web-ui connects to the docker socket and lets you spawn agents, and connect terminals. I'm having lots of fun with it and it allows me to cleanly organize and isolate my projects.
End-goal is to monitor for the Lethal Trifecta [2], ensuring all individual agents are properly isolated. Not quite there yet.
1: https://github.com/egzo-ai/egzo 2: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
> We design systems and use agents to implement them — this is not vibe coding.
Lol, what is even the point of such a statement, and who are they to define what vibe codig is or isn't :D
"Open" and "Shell" and just calling something private and safe out the box genuinely makes me think it's likely to fail at all of those claims.
There you go. Just don't tell everyone how it works.
"The worry is that, while right now you need to be a skilled virologist to know what components to order or how to grow and spread a bioweapon, AI tools might eventually make it possible for a rogue state, or a rogue group, or an individual, to do all this without virology expertise.
For a while, Anthropic tested whether Claude could assist a terrorist in developing a biological weapon in the obvious way: It assigned testers who had, say, an undergraduate degree in chemistry but no real virology training to try to use Claude to plan an effective mass terror event. Then it scored the attempt by how close it might have come to success.
Early in 2026, it noticed that Claude, attempting the task by itself, did better than a human aided by Claude did at coming up with a workable plan."
https://www.theargumentmag.com/p/what-i-saw-inside-anthropic
The machine god crafters know better than us, we are to subservient to their superior wisdom /s
Aside: it (JP) fights in my head with BTTF as a "perfect movie" (or at least a perfect script).
I encountered the same challenge building my toy sandbox. I wanted to use containers because that's what I know best.
The harness is launched in an internal only network. There is a sidecar container that provides mitm credential injection/proxy. I got HTTPS and SSH to work so far.
Claude code was quick to build it. No doubt it's copying previous work in this space though, so I know my work is not that original.
I'm testing all the llms that can be used for pen testing right now to see if/how they manage to escape it. Without a kernel exploit I doubt it's possible (not a very high bar I know).
I'm researching the space. Happy to learn more. Some links in my profile if you're interested.
Of course I’m the type to mount a ftp drive like a moron.