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

[ethbr1]

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}

[qarl2]

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.

[ethbr1]

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.

[qarl2]

Oh good - so you don't see the agents themselves as inherently sloppy - that's just how they're being used by some people.

Because I must warn you - it's extremely easy to ask a coding agent to prove code correctness before committing his work.

[ethbr1]

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