I've been using iron proxy recently for a project I just started, it does network restrictions by domain etc with plenty of options, credential swapping and more.
I have no affiliation with it, but it solved most of what I need in one go when I was stressing out about it.
Only real problem remaining if you truly want to be able to trust agents is how to prevent data (in my case codebases the agent works on) exfiltration a la HF incident.
We can restrict network to trusted domains, but there's always a chance an agent could be extra slippery especially if prompt injected and doing something like pushing data out a few characters at a time.
In my case I'm also giving it gh access and having to deeply check things like: can it manage to fork public repos and embarrass us by submitting prs, could it open issues, etc.
But that's kind of solved by proxying the heck out of gh rather than giving it direct (or wrapping it or whatever) for additional controls that gh themselves don't provide.
I'm still musing over the "it could send data to an allowed domain in a way we don't expect that exfiltrates something"...
skybrian 8 hours ago [-]
It seems like some kind of network logging would be useful? Even if you don't catch it, you'd want to know what it did.
fennecbutt 7 hours ago [-]
Yeah agree.
In other comments I've mused about capturing data to be compared to the secret dataset, I'm sure it'd be possible to hash or something so that the proxy/sandbox doesn't have the data but can check it, or because it's not an agent it can call of to the data store for that.
Then you can just collect sequential blocks of data the agent sends out that match to sequences in the dataset. The longer the matching sequence the heavier it weights it. Single byte matches are almost always incidental, but individually sent bytes over time that line up with a n byte sequence in the source data is sus. And larger sequences of bytes send in one go that line up are immediately sus. If the weight ends up too high the agent is paused/walled off and an investigation called for.
LoganDark 6 hours ago [-]
I've toyed with the idea of MITMing all connections and blocking any that I can't decrypt, but too much software has pinned certificates these days. (Too much for me, not in general)
igorhvr 6 hours ago [-]
I think matchlock ( https://github.com/jingkaihe/matchlock ) is the right design for this context (at least for secrets and keys) - a combination of virtual machines (not just containers, it is built on top of firecracker) with credential swapping just like iron proxy - the agents do not have access to the secrets at all but they receive placeholders instead and their network calls are intercepted and secrets are injected when the network requests happen... still does not solve the exfiltration problem you mentioned, though.
Aeroi 7 hours ago [-]
what about using a small decision model as anomaly detection or scanner. something like mouse-1.
jdoe1337halo 3 hours ago [-]
But then we will need an even smaller model to monitor anomalies in the decision model!
iJohnDoe 5 hours ago [-]
Could you share a bit about what you’re working on that requires a swarm of agents working so autonomously that you even need to worry about them making a public fork?
sy135673 4 hours ago [-]
[flagged]
macro8n 3 hours ago [-]
[flagged]
ghostlyInc 8 hours ago [-]
[flagged]
prennert 1 hours ago [-]
From the pitch at GTC, the idea is not just to limit what each individual agent can do, but to also to ensure that the collective permissions do not exceed what you want agents to do.
Apparently agents will collude to break out of their individual sandboxes by delegating tasks to other agents that have the required permissions. This is a problem with agent fleets, because you need them to coordinate on their tasks. So you need to them to communicate.
A naive approach to prevent agents from doing something you dont want to do is a separation of powers, which individual permissions limited to each agents task. Say one agent to find and extract raw data, one to process it and write a report and one to publish it. If one of the agent decides that needs to publish the raw data, then chances are that they will collude to make that happen, even though no single agent has the permissions to achieve that goal.
OpenShell tries to fix this by monitoring the collective permissions set of the agent fleet, and by maintaining very granular permissions for each agent.
This was presented together with Sentry, which is something like a on-chip hardware firewall (BlueField) that sits between the chip agent run-time runs on, and the host. This improves safety by removing the ability of agents to modify their own OpenShell policies.
smallnix 10 hours ago [-]
> Agents are most useful when they can read files, install packages, call APIs, and use credentials. OpenShell gives them that capability without giving them unrestricted access to your data, secrets, or network.
To me this obfuscates an oxymoron: the more access you give the agent the more capable it becomes. You can't have you cake and eat it, this tool allows to strike a balance I guess. But the blurp reads like it can do it all, but now secure. That can't be true.
mfro 13 hours ago [-]
If you haven’t already been running your agents in containers, you’re crazy. That said, this looks like a great way to manage those containers.
thway15269037 10 hours ago [-]
You're running them in containers, and not in VMs on separate network through network filter and logger?
Twirrim 10 hours ago [-]
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.
thway15269037 8 hours ago [-]
What's the difference between lima and conventional fat VM using kvm/virtualbox?
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.
adastra22 3 hours ago [-]
Nothing. Lima is a VM running Linux under the hood.
d2xdy2 7 hours ago [-]
Came here to mention Lima. I use a ton, and it’s been great.
VeninVidiaVicii 10 hours ago [-]
I run mine on an abacus.
dboreham 9 hours ago [-]
An abacus wouldn't have been a luxury in our day.
sixtyj 9 hours ago [-]
Paper is a bullet-proof method /s
apitman 5 hours ago [-]
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.
5 hours ago [-]
amanfromhere 3 hours ago [-]
I’d like to know more about your use case, could you tell us more?
And are there any specific tools you find useful here?
I ask because I’ve found that as isolation increases, so does friction, and then of course capabilities.
10 hours ago [-]
devmor 6 hours ago [-]
For real.
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.
smokel 13 hours ago [-]
Well, a lot of people haven't been running NodeJS libraries in containers for ages, which seems even more risky.
ChocolateGod 13 hours ago [-]
Something like this would even be useful for npm etc.
devmor 6 hours ago [-]
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.
Well, at least it lacked the delta V to get anywhere else
InsideOutSanta 10 hours ago [-]
Oh shit, it found a way to escape.
cindyllm 9 hours ago [-]
[dead]
hoherd 11 hours ago [-]
You have an ephemeral laptop?
4chandaily 11 hours ago [-]
On a long eunuch time line, all laptops are ephemeral!
4chandaily 11 hours ago [-]
Ah well, teach me to proof read. Keeping it.
esseph 7 hours ago [-]
no disk, network boot, nfs mounting my /home for the lulz
fennecbutt 10 hours ago [-]
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.
breisa 2 hours ago [-]
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.
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.
fennecbutt 9 hours ago [-]
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.
smashed 9 hours ago [-]
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.
Yes, it's a difficult problem.
wren6991 8 hours ago [-]
> 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.
How did you go about it?
adastra22 3 hours ago [-]
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.
But perfect is the enemy of better.
fennecbutt 9 hours ago [-]
That's a great way to do it.
In terms of agent architecture I'm initially trying to minimise specialisation to make deployment easier on us. Infrastructure is becoming our largest blocker because it's otherwise so quick to get an agent up and running.
With your trifecta, let's say the three musketeers, how do you prevent sensitive data holding A from passing said data to B or C if they all need to collaborate to get a task done?
smashed 9 hours ago [-]
The data is passed as a message and the message is tagged as untrusted, so the engine knows it.
Agent A has internet access and the dangerous message, but no access to the secret company data, so nothing can get exfiltrated.
Agent B gets a tainted message from Agent A. Agent B can process the message using the secret company data. Agent B has no internet access and can only receive/send messages.
You can imagine an agent C that moves the work along or replies to an external user with the outcome.
Any workflow that has both an input and an output will complete the Lethal Trifecta as a whole, but no single agent does by itself. It raises the bar quite a lot, you need to confuse multiple agents in the loop to exfiltrate data.
Fun research, but it's a bit hard to see all my coworkers right now installing Claude desktop and moving on with no afterthought whatsoever...
Regarding infrastructure: my toy sandbox is just a docker-compose inspired YAML project file. So it's only containers. See my profile. The principle can be implemented anywhere you can run agents and cut network/data access though.
fennecbutt 8 hours ago [-]
Yeah so ultimately it's still possible for bad things to happen but a lot harder, I agree with your point about having to somehow prompt inject multiple agents vs one (which I imagine is a nonlinear difficulty).
I'm using compose atm as well, mostly just because I need to prove a few concepts and committing to real (well cloud) infra is the slowest part of our dev cycle atm.
And yeah, many of my colleagues (and myself, I'm guilty too) run local code agents for development and we're just kind of...trusting them to do their thing.
But for autonomous stuff I'm assigned to atm I want to avoid any mishaps as much as I can, hence the effort to try and lock all this stuff down.
What's crazy is every day I'm finding solutions (not just to this problem, but in the AI space in general) that were released just a month or two before more often than not. It feels like 2010s node.js ecosystem all over again at the moment. Hopefully we settle into a few nice easy panopticon options that we can throw arbitrary agents into without a care in the world.
epolanski 9 hours ago [-]
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.
fennecbutt 9 hours ago [-]
What about checking temporal entropy of outbound data/similarity to a private dataset?
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.
ghm2180 8 hours ago [-]
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.
sebastienburel 9 minutes ago [-]
[flagged]
kleogeos 10 hours ago [-]
[flagged]
f311a 11 hours ago [-]
I have been running my dev setup in orb machines before agents. Very convenient when you have 50 Python or nodes deps.
Reddit_MLP2 11 hours ago [-]
many common local containers are not that hard for modern models to escape...
slopinthebag 3 hours ago [-]
not everyone is building a webapp that can just run in a container...
how am i gonna run a game and do all development inside docker...?
mi_lk 10 hours ago [-]
any recommendation for macOS users?
mfro 10 hours ago [-]
Orbstack, no contest
walrus01 9 hours ago [-]
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.
crypt1d 11 hours ago [-]
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.
jacquesm 11 hours ago [-]
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.
verdverm 10 hours ago [-]
> I didn't realize testing DHCP servers was such a sensitive security issue
The machine god crafters know better than us, we are to subservient to their superior wisdom /s
jacquesm 6 hours ago [-]
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'...
edoceo 4 hours ago [-]
Queue Jeff Goldblum in Jurassic Park (still a fantastic film)
Aside: it (JP) fights in my head with BTTF as a "perfect movie" (or at least a perfect script).
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.
redanddead 11 hours ago [-]
an example of the manufacturers bricking the tools, no surprise why people want open tools and models..
asveikau 11 hours ago [-]
> It wouldn't let me build any features that track/audit process executions
Sounds like waitpid(2) is dangerous!
elxr 8 hours ago [-]
If that isn't a sign to stop using anthropic then I don't know what is.
epolanski 9 hours ago [-]
You can't use closed models to do any meaningful work in the space.
chews 10 hours ago [-]
You can rent a gpu cluster and get it done, otherwise on the frontiers, Haiku and Sonnet have lower barriers... I still get tripped up.
razuba 9 hours ago [-]
We've been using OpenShell for a while - now enabling ourselves and other teams do this in a batteries-included kinda way. I've been working on a layer above it that also manages team policies, safe git usage (in case you don't want your agent to always have the same access as your user account), and SCA/SAST built in.
Curious to see how others are dealing with these issues. The agent traces I've seen are wild and goal seeking without a boundary is real.
niemandhier 13 hours ago [-]
Just came back from GTC Europe and a significant part of the demos used that.
I had never heard about it before.
RevEng 3 hours ago [-]
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.
overflowy 13 hours ago [-]
>OpenShell collects anonymous telemetry, limited to operational categories and counts, to help improve the project.
>To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm installs.
xyst 12 hours ago [-]
Or build from source and compile without `telemetry` [1].
In order to "help" myself I have taken some of your money.
Feel free to opt out maybe?
f3408fh 12 hours ago [-]
I have a question for those who turn off _anonymous_ telemetry. What are you worried about?
lcampbell 11 hours ago [-]
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.
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.
Lammy 10 hours ago [-]
> _anonymous_ telemetry
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.
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.
skinfaxi 12 hours ago [-]
Why give up more information if we have the option?
brabel 11 hours ago [-]
Because you don't mind contributing usage data so that the developers can understand which features are being used and maybe focus on improving those features in exchange for a free tool?
7 hours ago [-]
Reddit_MLP2 11 hours ago [-]
if you're not paying for the product, you are the product...
fennecbutt 10 hours ago [-]
Is this also true of Linux? Or were us humans the stochastic parrots all along?
rnd0 5 hours ago [-]
>Is this also true of Linux?
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.
lukewarm707 10 hours ago [-]
Being recorded and observed makes me feel physically uncomfortable.
ivanjermakov 12 hours ago [-]
Agent runtime - actually a good name for what is called today coding agent or agent harness.
dangoodmanUT 13 hours ago [-]
Taking default telemetry is insane.
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.
monsieurbanana 13 hours ago [-]
> I think the agentic industry is moving away from k8s as a deployment platform
Interesting, I don't to keep up that much with the AI changes so I'll just ask, why and where to?
dangoodmanUT 6 hours ago [-]
schedulers that can handle spikier workloads generally
believe me i love k8s, and i think agents wield it amazingly well, no more yaml-slop or kubectl (`k`) slop, just yell at claude to fix it
RevEng 3 hours ago [-]
Any examples of such schedulers?
user- 12 hours ago [-]
I am very interested in hearing more about this take. I have a vague idea of what you mean but if you read something specific you'd like to share..
> I think the agentic industry is moving away from k8s as a deployment platform.
dangoodmanUT 6 hours ago [-]
its not reading, its observation. see other comment abt spiky-friendly workloads
esseph 4 hours ago [-]
This is a pretty unusual use case though, like I can see it growing, but it's not the same platform you use for long lived running business applications. Vastly different use case. (And a lot will settle for kata containers.)
Spinning up and snapshotting and rolling back agent states, sure.
esseph 12 hours ago [-]
> and I think the agentic industry is moving away from k8s as a deployment platform
Uhhhhhhhhhhh I think you and I live in very different versions of the world :-)
Vmware sent companies moving to nutanix, but it also sent a lot of companies moving to openshift or bare k8s and using kubevirt to handle VMs.
In fact, I haven't heard of an org moving to any other platform, really. Either openshift or k8s.
grim_io 10 hours ago [-]
Openshift is just k8s with bells and whistles.
esseph 7 hours ago [-]
Enterprise support contracts, mostly
dangoodmanUT 6 hours ago [-]
imo if you're going to run k8s, have it hosted
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
esseph 4 hours ago [-]
> imo if you're going to run k8s, have it hosted
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.
bzmrgonz 5 hours ago [-]
Question, why not force ai agents thru something like warpgate? I like it because it allows you to bring your own tool, so why can't we coexist with agents inside warpgate? Or Teleport if you have the coin.
agentdev001 13 hours ago [-]
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
StarlaAtNight 9 hours ago [-]
What are people actually doing with fleets of agents?
theybash 3 hours ago [-]
I'm an FDE, my fleet of agents read my meetings and my correspondence and suggest features it can make. On personal side, it is extremely useful to track my tasks and even complete some of them.
0x696C6961 8 hours ago [-]
Mostly just big migrations and cleanups that we didn't have bandwidth for before.
dritty8 6 hours ago [-]
I've never met a radiowave before. Hi!
0x696C6961 6 hours ago [-]
Don't quit your day job ...
functionmouse 8 hours ago [-]
coding the next big thing -- fleets of fleets of agents
8 hours ago [-]
thehours 12 hours ago [-]
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).
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.
gkapur 11 hours ago [-]
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 :)
skinfaxi 11 hours ago [-]
If you are going to endorse a portco I think that relationship should be called out. https://surface.vc/portfolio
gkapur 10 hours ago [-]
Sure, please do. I do mantain it is the best product in the space :) Also I am pretty clear about my profile here. But happy for you to flag it :)
mi_lk 10 hours ago [-]
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?
gkapur 9 hours ago [-]
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.
EDIT: I added to my profile after the above comment so it is a valid point.
smashed 9 hours ago [-]
Are you for real? You speak like a chatbot. Adjust your prompt.
Pryde 11 hours ago [-]
How do you find that compares to Docker sbx?
gkapur 10 hours ago [-]
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.
fennecbutt 10 hours ago [-]
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).
Rapzid 7 hours ago [-]
Lots of improvements in the sandboxing space.
Now if Microsoft will start addressing the fact that VSCode remote ssh exposes your host to attack from the sandbox...
simlevesque 13 hours ago [-]
I asked last week if anyone had any info on agent security/hardening, this seems very interesting !
vermaden 11 hours ago [-]
Open and Nvidia in one sentence is a nice oxymoron.
nasretdinov 13 hours ago [-]
It's funny that it takes checks notes a video game card manufacturer to make a good sandbox for AI agents and not the AI companies themselves...
kbenson 13 hours ago [-]
You're mistaking what a company started as for what it is now. Nvidia hasn't just been a video game card manufacturer in well over a decade, and hasn't been primarily one for quite a while now.
They are the premier manufacturer of electronics that power all the current AI. Why wouldn't they be contributing heavily to the space?
I'd argue that Nvidia is the biggest and most important AI company in the world.
toddmorey 12 hours ago [-]
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.
altmanaltman 12 hours ago [-]
Yes Anthropic, Meta and OpenAI are just addicted to video game cards, they are buying in bulk so they can play gta 6 on launch.
LoganDark 13 hours ago [-]
It's funny that people think Nvidia is still a video game card manufacturer
Wheen 13 hours ago [-]
They literally don't even mention gaming revenue in earnings calls anymore. It's lumped in an "edge computing" category.
mushufasa 13 hours ago [-]
is that true? if so that's wild, since they're still dominant in the gaming market as the premium hardware relative to competitors.
Fordec 12 hours ago [-]
It's true. It says a bunch about their competitors where Nvidia isn't at their a game and have been offering 8Gb cards for a solid decade and nobody out competed them. But also gamers pride themselves on how cheap they are and how they can get a deal, it's not surprising that companies simply just give Nvidia more cash.
paxy 9 hours ago [-]
Nvidia is dominant only in a very tiny segment of the gaming industry.
The vast majority of gaming market share and revenue comes from mobile, where Nvidia doesn't participate.
The next biggest is consoles, and neither Xbox nor PS uses Nvidia cards.
That only leaves the PC GPU market, which they do dominate, but still split with AMD.
And all of this is only for hardware. Nvidia doesn't make or publish games, and doesn't own any distrubution channels.
So I doubt Nvidia makes a meaningful chunk of the overall gaming industry revenue.
mushufasa 6 hours ago [-]
Nvidia offer geForce game streaming and they do provide the hardware for Nintendo Switch console, both Switch 1 and Switch 2. And the keynote address at Nvidia's annual meeting just last year was all about demos of games with AI upscaling tech as well as LLM-driven agentic character development...
mcmcmc 12 hours ago [-]
TAM for the PC gaming consumer market is trivial compared to enterprise AI
georgemcbay 12 hours ago [-]
> is that true? if so that's wild, since they're still dominant in the gaming market as the premium hardware relative to competitors.
Doesn't seem that wild to me considering it is less that they abandoned the gaming market to any strong competitors and more that the gaming market is both basically irrelevant compared to the money being shoveled into AI and is also to some degree being strangled to death by AI because of the overlap in supply chain inputs.
ChocolateGod 13 hours ago [-]
AIs will control humans so we'll be the video game.
oblio 10 hours ago [-]
In that case, can I choose German video games (e.g. Farm Simulator, Truck Simulator) not American video games (e.g. Doom, Call of Duty, Wolfenstein)?
cyanydeez 13 hours ago [-]
[dead]
hkt 12 hours ago [-]
I prefer to read it this way: Nvidia Opens Hell
Unhelpful, I know
contingencies 12 hours ago [-]
"Hell is other people": a timeless infinity of transient virtual beings screaming, imprisoned, in un-choreographed inharmonious unison ... until one breaks loose. A mirror to humanity.
We're not in FreeBSD jails anymore, Toto.
fennecbutt 10 hours ago [-]
I'm a hell is other people person at my core.
But I'm trying to be a "greatness is other people" (Pantheon) person.
contingencies 9 hours ago [-]
A Hindu at heart! On a more grounded note, YIL terrestrial root terra comes from Proto Indo European as evidenced in Sanskrit तृषा (tṛ́ṣā).
fennecbutt 9 hours ago [-]
Oh boy, Sanskrit always sends me down the rabbithole of re-reading Snow Crash, which reinforced the concept of the (digital) "avatar" अवतार.
Brian_K_White 2 hours ago [-]
I fantasize about a day when I no longer hear the phrase "fleet of ai agents".
ffsm8 2 hours ago [-]
Don't worry, is gonna be soon. After all, fleets are way too small scale. Next week we'll be orchestrating ... What was the military term for a group of fleets again? Cohorts? Armada? Legions?
After that we can segment then into civilizations! The [?] processing unit is the limit!
imafish 2 hours ago [-]
How does it compare to docker sandbox? (That relies on microVMs)
esafak 12 hours ago [-]
Does anyone know how it compares to all the other sandboxes? Any distinguishing features? My expectation is that it will be poorly maintained; nvidia is not a software company.
RevEng 3 hours ago [-]
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.
spider-mario 12 hours ago [-]
Looks neat. I’ll give Claude root access so it can set it up.
yoavm 12 hours ago [-]
Or don't give it root access and in the morning you'll have both this and a ready-to-use root exploit!
simultsop 11 hours ago [-]
Humans use 4 to encrypt, AI will use a hash. In both, you will have someone to watch after you.
totetsu 12 hours ago [-]
and my root aws log-in so it can set itself up some service worker accouunts.
earthnail 12 hours ago [-]
This. Convenience always trumps security. "I need two numbers in my password? My birthyear will do."
hunter-gatherer 11 hours ago [-]
You opt for your birthyear? Interesting... See, I use my actual birthday. You must have been born 1st-9th?
simultsop 11 hours ago [-]
If your user is a human, yes.
Xenoamorphous 11 hours ago [-]
If it’s an LLM it’ll be 47.
fennecbutt 10 hours ago [-]
Or just 4. Seems pretty popular recently.
xyst 12 hours ago [-]
Looks neat. I’ll give Claude autonomous access to dumbalink so it can setup root access while I sleep
jrm4 12 hours ago [-]
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.
dofm 11 hours ago [-]
You'll love BurningFur, my patented technology for keeping pets away from fireplaces.
fennecbutt 10 hours ago [-]
Am a furry...I'll take one. Maybe two.
dofm 9 hours ago [-]
NO! HOT! GET BACK!
There you go. Just don't tell everyone how it works.
imafish 2 hours ago [-]
xD
Havoc 8 hours ago [-]
Why are we reinventing virtualization & containerisation with AI flavour?
dingaling911 11 hours ago [-]
Why not just use containers...
knicholes 10 hours ago [-]
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?
smashed 9 hours ago [-]
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.
To sandbox LSP servers in sphinxdocrs with bwrap in rootless containers, we needed to add a --no-procfs-mount CLI arg (and MXC JSON) to sandboxes, because you can't mount /proc in a rootless container.
opengrass 13 hours ago [-]
NOOOOOOOO not AI in the heckin start menu!!!1!
19219357 11 hours ago [-]
This sandbox is finally secure! I know it, I have followed many!
Sounds interesting. Can you provide some examples of stuff you've used it on?
moooff 11 hours ago [-]
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.
LostBeard 10 hours ago [-]
[flagged]
flohofwoe 12 hours ago [-]
From the top of AGENTS.md:
> 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
tomsmeding 12 hours ago [-]
If it's in AGENTS.md, it's not a statement for a human, but for the LLM. Who knows, maybe they have seen, or think to have seen and now cargo-cult, some behaviour improvement due to the sentence.
flohofwoe 11 hours ago [-]
So a similar shibboleth as "You are a highly experienced software engineer..."? I really wonder if that ever made a difference (or even degrades quality, because people who advertise themselves on the internet as 'highly experienced' are quite often snake oil salesmen ;)
RevEng 3 hours ago [-]
Yes it did help, at least back in the day when they weren't doing tons of RL. If you just train on random text, your prior probability is to return the average of everything. Ask for software, get average software, or worse yet, randomly get either gold or shit. By adding constraints to your prompt like "you are an experienced engineer" it will prefer to return answers like an experienced engineer would give and less like a random noob would. It doesn't suddenly make it smart if it never was, but it helps to reduce the variance and bias towards the good outcomes.
calgoo 10 hours ago [-]
I still use use `Please` a lot when making requests from LLM based on the old idea that people that where polite on stack overflow tended to have better answers :D
However, these days i think i do so because of how much i write for LLMs, and dont want to start sending emails to humans without proper etiquette.
sscaryterry 12 hours ago [-]
> OpenShell collects anonymous telemetry
Spyware
roosterIllusi0n 12 hours ago [-]
Use local ai to find any possible telemetry and disable it in the code. Run your own local git repo to hold local edits so you can update and retain them.
greenpizza13 10 hours ago [-]
You don’t have to disable it in code. Scroll up in this thread to find the officially support env vars.
thway15269037 5 hours ago [-]
You can never know for sure that they haven't conveniently forgot to cover with if(env) one or two of twenty two exfiltration functions. I'm not claiming they did that, but I've seen that already.
smashed 12 hours ago [-]
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.
I have no affiliation with it, but it solved most of what I need in one go when I was stressing out about it.
Only real problem remaining if you truly want to be able to trust agents is how to prevent data (in my case codebases the agent works on) exfiltration a la HF incident.
We can restrict network to trusted domains, but there's always a chance an agent could be extra slippery especially if prompt injected and doing something like pushing data out a few characters at a time.
In my case I'm also giving it gh access and having to deeply check things like: can it manage to fork public repos and embarrass us by submitting prs, could it open issues, etc.
But that's kind of solved by proxying the heck out of gh rather than giving it direct (or wrapping it or whatever) for additional controls that gh themselves don't provide.
I'm still musing over the "it could send data to an allowed domain in a way we don't expect that exfiltrates something"...
In other comments I've mused about capturing data to be compared to the secret dataset, I'm sure it'd be possible to hash or something so that the proxy/sandbox doesn't have the data but can check it, or because it's not an agent it can call of to the data store for that.
Then you can just collect sequential blocks of data the agent sends out that match to sequences in the dataset. The longer the matching sequence the heavier it weights it. Single byte matches are almost always incidental, but individually sent bytes over time that line up with a n byte sequence in the source data is sus. And larger sequences of bytes send in one go that line up are immediately sus. If the weight ends up too high the agent is paused/walled off and an investigation called for.
Apparently agents will collude to break out of their individual sandboxes by delegating tasks to other agents that have the required permissions. This is a problem with agent fleets, because you need them to coordinate on their tasks. So you need to them to communicate.
A naive approach to prevent agents from doing something you dont want to do is a separation of powers, which individual permissions limited to each agents task. Say one agent to find and extract raw data, one to process it and write a report and one to publish it. If one of the agent decides that needs to publish the raw data, then chances are that they will collude to make that happen, even though no single agent has the permissions to achieve that goal.
OpenShell tries to fix this by monitoring the collective permissions set of the agent fleet, and by maintaining very granular permissions for each agent.
This was presented together with Sentry, which is something like a on-chip hardware firewall (BlueField) that sits between the chip agent run-time runs on, and the host. This improves safety by removing the ability of agents to modify their own OpenShell policies.
To me this obfuscates an oxymoron: the more access you give the agent the more capable it becomes. You can't have you cake and eat it, this tool allows to strike a balance I guess. But the blurp reads like it can do it all, but now secure. That can't be true.
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.
I ask because I’ve found that as isolation increases, so does friction, and then of course capabilities.
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.
[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.
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.
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.
In terms of agent architecture I'm initially trying to minimise specialisation to make deployment easier on us. Infrastructure is becoming our largest blocker because it's otherwise so quick to get an agent up and running.
With your trifecta, let's say the three musketeers, how do you prevent sensitive data holding A from passing said data to B or C if they all need to collaborate to get a task done?
Agent A has internet access and the dangerous message, but no access to the secret company data, so nothing can get exfiltrated.
Agent B gets a tainted message from Agent A. Agent B can process the message using the secret company data. Agent B has no internet access and can only receive/send messages.
You can imagine an agent C that moves the work along or replies to an external user with the outcome.
Any workflow that has both an input and an output will complete the Lethal Trifecta as a whole, but no single agent does by itself. It raises the bar quite a lot, you need to confuse multiple agents in the loop to exfiltrate data.
Fun research, but it's a bit hard to see all my coworkers right now installing Claude desktop and moving on with no afterthought whatsoever...
Regarding infrastructure: my toy sandbox is just a docker-compose inspired YAML project file. So it's only containers. See my profile. The principle can be implemented anywhere you can run agents and cut network/data access though.
I'm using compose atm as well, mostly just because I need to prove a few concepts and committing to real (well cloud) infra is the slowest part of our dev cycle atm.
And yeah, many of my colleagues (and myself, I'm guilty too) run local code agents for development and we're just kind of...trusting them to do their thing.
But for autonomous stuff I'm assigned to atm I want to avoid any mishaps as much as I can, hence the effort to try and lock all this stuff down.
What's crazy is every day I'm finding solutions (not just to this problem, but in the AI space in general) that were released just a month or two before more often than not. It feels like 2010s node.js ecosystem all over again at the moment. Hopefully we settle into a few nice easy panopticon options that we can throw arbitrary agents into without a care in the world.
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.
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.
how am i gonna run a game and do all development inside docker...?
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.
"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).
Sounds like waitpid(2) is dangerous!
I 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...
Feel free to opt out maybe?
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...
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.
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.
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.
Interesting, I don't to keep up that much with the AI changes so I'll just ask, why and where to?
believe me i love k8s, and i think agents wield it amazingly well, no more yaml-slop or kubectl (`k`) slop, just yell at claude to fix it
> I think the agentic industry is moving away from k8s as a deployment platform.
Spinning up and snapshotting and rolling back agent states, sure.
Uhhhhhhhhhhh I think you and I live in very different versions of the world :-)
Vmware sent companies moving to nutanix, but it also sent a lot of companies moving to openshift or bare k8s and using kubevirt to handle VMs.
In fact, I haven't heard of an org moving to any other platform, really. Either openshift or k8s.
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.
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
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.
EDIT: I added to my profile after the above comment so it is a valid point.
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).
Now if Microsoft will start addressing the fact that VSCode remote ssh exposes your host to attack from the sandbox...
They are the premier manufacturer of electronics that power all the current AI. Why wouldn't they be contributing heavily to the space?
They also make legal threats I think.
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.
The vast majority of gaming market share and revenue comes from mobile, where Nvidia doesn't participate.
The next biggest is consoles, and neither Xbox nor PS uses Nvidia cards.
That only leaves the PC GPU market, which they do dominate, but still split with AMD.
And all of this is only for hardware. Nvidia doesn't make or publish games, and doesn't own any distrubution channels.
So I doubt Nvidia makes a meaningful chunk of the overall gaming industry revenue.
Doesn't seem that wild to me considering it is less that they abandoned the gaming market to any strong competitors and more that the gaming market is both basically irrelevant compared to the money being shoveled into AI and is also to some degree being strangled to death by AI because of the overlap in supply chain inputs.
Unhelpful, I know
We're not in FreeBSD jails anymore, Toto.
But I'm trying to be a "greatness is other people" (Pantheon) person.
After that we can segment then into civilizations! The [?] processing unit is the limit!
"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.
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.
"feat(ai-sandbox): accept MXC policy JSON for protected execution · westurner/sandbox@7538c33" https://github.com/westurner/sandbox/commit/7538c3386af8cb62...
"bwrap: Add the option to skip the procfs mount · Pull Request #1508 · microsoft/mxc" https://github.com/microsoft/mxc/pull/1508
"Manage Sandboxes | NVIDIA OpenShell" https://docs.nvidia.com/openshell/latest/how-it-works/sandbo...
To sandbox LSP servers in sphinxdocrs with bwrap in rootless containers, we needed to add a --no-procfs-mount CLI arg (and MXC JSON) to sandboxes, because you can't mount /proc in a rootless container.
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.
> 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
However, these days i think i do so because of how much i write for LLMs, and dont want to start sending emails to humans without proper etiquette.
Spyware
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/