I'm using xterm.js with the canvas/gpu renderer in my app, driving these modern coding agents that seems to use every features in the book of terminals and it's perfectly fine.
The dom renderer is also perfectly fine, just needs a little bit more careful CSS to make it look right with some of the fancy line art.
I do use ghostty and it's alright. It's required for some rich TUI ai seems to be pumping out. Otherwise I prefer tilix and the default gnome terminal, but it might be just because of years of habit.
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.
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.
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?
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.
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.
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.
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.
It is very interesting that they believe AI will find different bugs than people. That is, if you found a bug with AI the expectation is that others could find the same bug easily. But if you find it yourself, it is somehow more of a sensitive secret.
I do not imagine that things divide so clearly along these lines.
I think the expectation is that if you found it with an LLM them other people are also going to find it with an LLM, so it's not very private anyway. That's not the same as saying if you find it with an LLM it will not be found by manual review, or vice versa.
I think this idea comes from two directions: firstly, LLMs are relatively predictable, so given the same prompts and review processes you're likely to find the same bugs, and secondly, if you're using the free or cheaper LLM tiers, your conversation is likely to end up in the training data and so become 'known' the the LLM after some time anyway. I think the latter is perhaps being overestimated by the kernel security team (Greg KH's talk on the matter characterised is as "the LLM finds a bug for one person and then decides to hand it over anyone else looking for bugs as well", which really isn't how it works internally).
> I think the expectation is that if you found it with an LLM them other people are also going to find it with an LLM
That "expectation" us far from certainty and it exists for bugs found by humans too, in both cases, caution dictates to follow the standard responsive disclosure procedure.
My impression is that Linus doesn't like dealing with security, it's just an annoying chore he's uncertain about. I hope things change in the future because that attitude percolates down to the kernel team as well and it spells trouble when combined with the size of the project and the new AI developments.
Humans are more diverse than LLMs and there is less human effort than LLM effort going into this at this point, so it's a lot less likely, especially for the kind of obscure, old bugs that are being unearthed at the moment. It's not a decision made with a lack of evidence: the guidance went in when they noticed that LLM-assisted bug reports were often duplicated.
Personally while I'm not going to rail against 'responsible disclosure' I'm not utterly convinced it's the best way to go, and certainly not that it's the only moral option.
It's been the experience over the last 8 months on the security list, with some reports coming in the same week from up to 13 different sources, each not knowing someone else already reported the bug. A significant portion of bugs founds by LLM arrive as duplicates, so keeping them private doesn't protect anyone and makes it much more difficult to get them fixed.
Probably not a clear divide, but it might be some kind of divide, and it might be the opposite of intuition.
The big advantage the LLMs have is their huge context windows, ability to parallelize and delegate, and no attention fatigue or need to sleep. They can think about random combinations of functions and modules all day long until they find a combination that's exploitable. That's hard for a person to do, and its the kind of exploit that probably would never be found otherwise except by another llm-powered thing. Not being a security expert myself, I gather that these AI vulns tend to be small needles in very large haystacks that normal people just would never have the patience to search.
But if you found something yourself, then it's something that's simple enough and involves a small enough number of moving parts that you can keep it in your head all at once and recognize the problem and correctly reason about its consequneces, which probably means it's easier to exploit, and therefore more dangerous if made public.
It feels a little backwards, and it might still be backwards, but if there's any benefit i think it's along those lines.
The policy is based on what is actually occurring. The Linux security team has had a flood of duplicate reports from AI, so they changed their policy to request that security bugs found by AI be reported on public mailing lists to avoid duplicates. They have not yet seen the same for human found bugs, so the old policy remains in place. It is likely that at some point in the future the AI discovered bugs will be a superset of human discovered ones, but for now humans and AI seem to be better at finding different types of bugs. When/if it does happen, the number of human bugs will taper off to nothing because AI will find them all first, so the policy change will take care of itself.
It's a shared tool so it coming to similar conclusions across users wouldn't be unexpected. Like if it were a scanner you could run to find common security problems, you would treat those as public since anyone could just run the scanner.
You are misrepresenting the premise. The premise is "if you found a bug with a COTS toolkit, others using the same toolkit may also find this bug easily". The second assumption is that many people are using the same COTS toolkit, which seems uncontested in my eyes as there's only a handful models in wide circulation.
I agree with this comment. Feels to me like they thought every prompt was "find the bug here," but in reality a lot of people put interesting context or original thoughts into their workflow with LLMs.
“If you resorted to AI assistance to identify a bug, you must treat it as public. While you may have valid reasons to believe it is not, the security team's experience shows that bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day. In this case, do not publicly share a reproducer, as this could cause unintended harm; just mention that one is available and maintainers might ask for it privately if they need it.”
Do not publicly share a reproducer aka ai found bug
No, that's share the bug/where the bad code. Do not share the code that exploits the bug, aka the reproducer, publicly. That part is often much harder to write, but it proves the bug is actually exploitable and not just a bug that isn't actually exploitable.
I don't think AI is of much concern, if you actually have a valid security issue.
No-one, really will care if you discovered it via AI or otherwise. Because, the weight of the bug itself should outweight other concerns. This is how professional security works. There will always be one concern or the other about a bug but what carries more weight will determine the direction that the disclosure process takes.
A valid security bug, by itself should carry enough technical weight that concerns about whether it was discovered through AI or otherwise should become irrelevant.
Anyways, it mostly seems like people don't really care much about computer security at Linux. I would like to think they care more about infrastructure and related security issues because, well, if my computer is an open book, then why would security issues around it be a concern?
>A valid security bug, by itself should carry enough technical weight that concerns about whether it was discovered through AI or otherwise should become irrelevant.
that's not really what the policy is about.
the thinking behind the policy is that if you found it via AI, other people can trivially find it via AI. that is why AI-found bugs are treated as public from the start.
My sinister side wonders if part of it could be that if you found it via AI but it turns out to be a hallucination, then you must accept the public ridicule for not thoroughly vetting the AI output.
The linux kernel maintainers tend to go a little against the grain in terms of approach to security. Primarily they tend to resist the categorisation and ranking of bugs by security impact, instead insisting that more or less all bugs are equal and you should just update to the latest version regularly if you want to remain secure.
Maybe I'm not enough in the weeds to see it as much, but the last few months seem to have been a much slower trickle of "how did we not catch this" exploits, while they are now appearing with much more sophisticated (though still usable in practice) exploit chains on much larger target codebases.
The last few months seem to have been a lot more imunder control with also the frontier labs more warning of "what happens when Mythos-class model get in the hands of everyone" than that actually becoming reality. Now, it appears to be actuually turning into reality.
The problem is fixing the bug and not only fixing the code, but applying the fix in production in a timely manner and without interrupting the business.
Agreed. Even with opus 5.5 which everyone praises for its wonderful coding abilities, I keep catching awful coding abstractions or missing abstractions.
It can keep patching everything left and right whenever a new requirement comes up so it does not "need" to build abstractions, and it will only do it to please the human reviewer.
Unironically this is where I converged. Shipping the feature is the most important thing, Opus 5.5 is good enough with correctness that I merge off the title or description alone.
A year from now Fable 6 will de-slopify, so I don't really care about having pretty abstractions. That's simply not my job anymore. Sacrilege, I know.
This is the way I feel about it too. I admire designing systems and abstractions upfront, but until I have a clear way to do that, I'm happy with whatever the agent produces. I still decide on architecture, pipelines, and algorithms, and let the agent fill in interfaces, methods, and packages. Are any of them good? Certainly not. But they work. And until that needs to change I'm not too concerned, except with my job title which seems to have lost a lot of its meaning.
With a list of "Known gaps" and implemented engines listed with status like "Real", and of course the Quick start first, as Claude loves to do.
It's not "wrong", it just shows low effort. But then again it's just something someone needed and shared it for free so let's not complain too much.
All the products and saas launching with obvious AI landing pages, that the authors did not even care to trim down, that's another story.
reply