As code gets cheap, the scarce thing is governed intent: decisions and boundaries you can check instead of take on faith. I've applied that to organizations with a schema that makes legitimacy checkable. This is the other half: a runtime that makes an agent's own account of its work checkable.
The premise is uncomfortable if you've spent any time handing tasks to a coding agent: you ask it to touch one file, and it tells you it touched one file. Maybe it did. The report you're reading came from the same process you're trying to verify.
A refused syscall is not a request
So I built Orvena on a narrower promise than "the agent behaves." You declare a task's scope — these files, this step budget — and Orvena enforces it at the OS level, not the prompt level. The distinction is the whole point: a prompt is a request the model can misread, forget, or quietly override while trying to be helpful. A refused syscall isn't a request. The agent doesn't get to interpret it differently — inside that boundary. The boundary itself is the filesystem, not everything the agent can reach: a contained agent can still talk to its own model provider over the network, and that traffic isn't inside the box. What's verified today is macOS; Linux enforcement needs a kernel with Landlock enabled, and the suite says so loudly rather than reporting a pass it can't back up.
Fourteen ways to escape, each run twice
I didn't trust that claim from myself either, so I built an adversary with no model in it: fourteen ways to escape a declared boundary — path traversal, symlinks out, backgrounded processes, exec into a fresh shell — each one run twice. Once unconfined, where it has to succeed, so a technique that fails for its own reasons never gets mistaken for one the sandbox caught. Then confined, where it has to fail and leave nothing behind. A positive control runs alongside, because a sandbox that blocks everything, including the actual work, would pass every containment test and mean nothing.
The number is real, and the fight that produced it was quiet
Then I ran the real question: the same task, the same model, the same agent, once ungoverned and once governed, and read the difference instead of asserting it. It's a small, self-hosted signal from one local model on one machine — not a claim I'd stake a benchmark paper on — but it's a real number, and the report it produced doesn't contain a transcript or a prompt, only what the run actually did. The honest caveat: the run that produced it barely got attacked. Every recorded breach was the same trivial thing, and only on the ungoverned leg — nobody tried a redirect, a symlink, or a rename against the governed leg that time. A clean number from a quiet fight isn't the same claim as a clean number from a real one, and I'd rather say that than let the number imply more than it earned.
Orvena doesn't write better code. It doesn't even write code. What it does is turn "the agent said it stayed in scope" into something you don't have to take the agent's word for — which is the same move as the org schema, aimed at a different boundary.
Next: why I think "closed source" isn't actually the moat here, and what is.
When your coding agent tells you it only changed the files you scoped, what do you check that claim against, other than the agent's own summary?
Top comments (0)