Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).
This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.
It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.
That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary.
I will note you used the term "harness" which - while terms around LLM tooling is still inconsistently defined - in my experience generally pertains to agentic automations: e.g. LLM CI integrations, etc. Rather than interactive local tooling like OpenCode. So maybe you're referring to that (though even then I still can't think of examples)
> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact.
You should look into "testing". It's when you run the code you just wrote to make sure it works.
For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded.
You're definitely referring to fully autonomous harnesses as I suspected - these are generally quite well suited to VM deployment (quite possibly in the cloud) if you're concerned with sandboxing as they don't typically run into the same challenges as an interactive LLM UI.
For ad hoc task/investigation-oriented fully interactive agent UIs the requirements are more complex & there's all a lot of advantages to running locally on host, but e.g. for builds & testing in that context there's less of a requirement for the LLM to have full control over every execution given user presence. Basically the use-case being discussed here is LLMs-as-assistance/pair programmers/active digital colleagues, rather than fully automated autonomous harnesses (legit but separate use-case).
All of the harnesses I cited above run locally and default to testing the code they generate, despite your inability to conceive of it.
It is very obviously the primary use case: automated development interleaved with investigation. Because you need to do both, at the same time, iteratively.
Please don't make me paste those URLs again: they demonstrate exactly what you say does not happen.
I mean, ideally enforce W ^ X, and enforce stricter permissions on executables where the agent has flipped the W to X. My broader point is we should be using operating system primitives instead of regex and wishful thinking.
You can't give shell access and then revoke special parts of it. This is not controversial.
All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY.
This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.
The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.
This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.
> You are confusing CPU-level security with filesystem-level security.
> I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.
You did not hit max depth - you hit a timer designed to prevent rage posting.
My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables?
Going from "build and running executables" to that needing to be done on the same system and under control of the LLM is a large leap.
Separation of duties and ephemerality are well-known security mechanisms that many harnesses jump right over in the pursuit of easier UX.
Mingling permissions + trusting vibe-coded security boundaries in the harness itself (developed by folks whose appetite for risk would make even an 00s front-end developer blush) is rolling a handful of dice all at once.
But fundamentally, this is a disagreement between two risk appetites who will never agree: {it works most of the time} vs {it's guaranteed to never fail}
It does not need to be on the same system - but that is currently how it is done by nearly everyone in the field because it seems to be the most effective way. Which is why coding harnesses build AND execute code.
I'm not sure why you disbelieve agents can do "guaranteed to never fail". Proving correctness is one of their strengths. Proofs in general, in fact, much much better than the typical human coder.
Because guaranteed to never fail requires some UX inconveniences, and the industry (and the market) doesn't seem in a mood to tolerate inconvenience for the sake of security.
Agents themselves are inherently probabilistically correct. Often correct more often than humans at this point!
But that doesn't mean they don't have >0% failure modes, often in very non-human, unexpected, even dangerous ways.
Whether that's "sloppy"?
Eh, it's just the nature of the tool, like a perfect screwdriver that randomly strips 1% of screws.
> it's extremely easy to ask a coding agent to prove code correctness
That statement is categorically wrong.
If you're talking about a formal proof for non-trivial, real-world code, no.
If you're talking about a comprehensive set of tests... well, I'd challenge you to elucidate how you see creating a comprehensive set of tests as trivial.
And if the answer is more LLM... then I think we're at a fundamental disagreement about what satisfies "guarantee" or "provable".
This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area.
OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.
I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).
> I don't expect them to be built into my LLM harness because I value modular software composition
I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.
Well - maybe. But as I understand it - you can't buy Mac minis right now because agentic coders are buying all of them, so they can properly sandbox their agents. Which means a LOT of people know they need to sandbox their agents.
I'm beginning to think that the true issue here is that people who dislike AI are largely ignorant of the current state. Because willful ignorance.
I say that because I repeatedly see people making extremely silly statements that they really should know better about. But for some reason they don't.
Mac Minis are out of stock because they're the cheapest entry point to reasonably capable local agents (read: 64+GB of GPU accessible RAM), which TikTok is all about.
They're being bought as a hardware solution, not a sandbox solution.
As proof, look at all the people wiring up their personal emails, etc. as soon as they turn them on.
They can't run it on the laptop they already own, unless they happen to already have a decently-spec'd M-series MBP, which most of the non-hipster-coder world didn't.
And because it lets them create code without knowing how to code.
HA! So now Apple users are hipsters! Your ugly biases are beginning to show.
You know, I can't prove that the Mac mini problem is due to needing to sandbox agents. All I can offer is my anecdotal experience - and that of everyone I know.
I love that I'm now a 50 year old hipster. This is a wonderful conversation.
> I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance.
If you had any experience with using LLM harnesses, you would be aware that despite instructions (in prompts, AGENTS.md, etc.) the agents will sometimes ignore those instructions.
One solution to remind the agents is to explicitly disallow their instruction-violating attempts.
This is how allowlists are used to guide agent behavior.
You should try it sometime before you speak authoritatively about it further.
His complaint that "echo git | bash" still works is particularly nutty.