[wren6991]

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.

[qarl2]

And what would prevent the LLM from downloading and compiling its own version of git? But it names it "not-git".

[lucideer]

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.

[qarl2]

LLM harnesses build executables and run them. That is their primary purpose.

Changing an executable's signature by inserting a single extra printf() is well within that spec.

[lucideer]

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)

[qarl2]

> 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.

Anthropic's harness Claude Code:

https://code.claude.com/docs/en/best-practices — "Claude does the work, runs the check, reads the result, and iterates"

https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135a... — "autonomous loops where Claude writes code, runs tests, and iterates continuously"

https://www.anthropic.com/research/long-running-Claude — "Run pytest tests/ -x -q before every commit"

https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "Claude edits a file with one tool and requests the command that runs it"

https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "writes Python with the file operations sub-tool and runs it with a Bash command"

OpenAI's harness Codex:

https://openai.com/index/introducing-codex/ — "can iteratively run tests until it receives a passing result"

https://openai.com/index/introducing-upgrades-to-codex/ — "iterating on its implementation, fixing test failures, and ultimately delivering a successful implementation"

Aider harness:

https://aider.chat/ — "Automatically lint and test your code every time aider makes changes"

https://aider.chat/docs/usage/lint-test.html — "run your test suite after each time the AI edits your code"

Devin harness:

https://cognition.com/blog/introducing-devin — "Devin writes and debugs code to run a computer vision model"

https://cognition.com/blog/introducing-devin-2-2 — "Devin runs through your app and sends back screen recordings"

https://cognition.com/blog — "Devin now builds, runs, and tests natively in Windows VMs"

SWE-bench harness:

https://www.vals.ai/benchmarks/swebench — "running unit tests against the generated patch"

Copilot:

https://github.blog/changelog/2025-05-19-github-copilot-codi... — "makes changes, and even validates its work with your tests and linter"

https://docs.github.com/copilot/concepts/agents/coding-agent... — "how to build, test and validate its changes"

https://docs.github.com/copilot/how-tos/agents/copilot-codin... — "If Copilot is able to build, test and validate its changes"

https://github.blog/ai-and-ml/github-copilot/github-copilot-... — "coding agent can independently write, run, and test code"

[lucideer]

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).

[layer8]

The executables built by LLMs should only given access to a restricted test environment by default.

[wren6991]

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.

[qarl2]

I don't know what you mean by "enforce W ^ X".

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.

Your complaints are misguided.

[wren6991]

Here: https://en.wikipedia.org/wiki/W%5EX

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.

[wren6991]

Replying inline because this hit max depth:

> 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.

[qarl2]

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?

Respectfully.

[qarl2]

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?