TL;DR: Run agent-written code without a signing key, measure it in a separate keyless process, and keep approval with another authority. This is the next entry after the Ranex slice log.
You delegated work to an agent, then watched it run code it had just written. Would you let that same process hold the key that signs the result? A real delegation is built around the answer “no.”
In this note
- The dangerous moment after the agent edits the tree
- The lesson: separate execution, measurement, and judgement
- A checklist for your own delegated loop
- What this delegation proved — and what it did not
- Your next move
The dangerous moment after the agent edits the tree
The risk is not only that an agent writes the wrong code. The risk is that code it wrote gets to reach the authority that declares the work trustworthy.
A headless agent in a worktree feels contained until you follow the process tree. It can edit the repository. It can trigger the suite. The suite is code it may have changed minutes earlier. If the execute process carries a signing key, the boundary exists only in the story you tell about it.
SLICE-008 began with a blunt defect: there was no front door. A person had to connect dispatch, harness, emission file, and judgement by hand. The earlier gear-mesh proof used a model that did no work and hand-wrote its own evidence. That proved parts could turn. It did not prove that the kernel could judge work an agent actually produced.
There was a sharper failure underneath. The existing ranex run path read the signing key before the bound command spawned. The slice records that RISK-06 reproduced that command taking the key from the process environment. If an agent-controlled test hook can reach that key, it can produce a signature while the rest of the system looks tidy.
Do not file that concern away. Design it out of the execution phase.
The lesson: separate execution, measurement, and judgement
The practical split is direct: run the agent without a signing key, measure its committed work in a separate keyless invocation, then attest later. The judge produces a candidate with named missing claims, never a self-issued PASS.
ranex task delegate dispatches a worktree and starts the harness headless. Its environment is built from empty: a pinned PATH, a scratch HOME outside the worktree, bridge variables, one model-credential variable, an auto-approve flag, and a wall-clock bound. When the signing-key variable is present, delegation refuses before it spawns anything.
“Built from empty” means one concrete thing: the execution environment is deliberately assembled instead of inheriting whatever trust happened to be in the parent shell. That is a much better place to start asking what the worker can reach.
When the agent finishes, the kernel parses its emission and matches the worktree and commit against its own dispatch record. A missing emission blocks. A mismatch blocks. An empty delegation where the commit equals the base is refused rather than judged.
Next, the kernel runs the frozen suite against the emitted commit. The commit is materialised, sealed, and offline for that measurement. The invocation holds no key.
Only after that does a separate, later invocation sign the result. Untrusted code is not running at that time.
The worker can make a change. The measurement can describe the change. Neither action grants approval.
The task judge result is a journalled CANDIDATE naming its missing claims. The stamp stays a human’s and out of band. That distinction is the whole design, not a label applied at the end.
For the wider reason a separate check port matters, read the accountability apparatus. An accountability system needs an inspector outside the actor it inspects.
A checklist for your own delegated loop
You can audit this without adopting a kernel. Start with the process that executes agent-produced code, then trace every secret, timeout, artifact, and verdict out to its owner.
- Start from an empty environment. Write down the exact variables and paths the worker receives. Treat inherited shell state as unreviewed input.
- Refuse execution when a signing key is present. Do this before spawning the agent or its process tree, not after it has begun.
- Inspect the live process tree. Do not accept a source-level assertion that a key was removed. Check what the child and parent can actually reach.
- Bind a task to its worktree before work begins. Make the judge compare the emitted worktree and commit with a dispatch record it owns.
- Measure a frozen suite against the emitted commit. Do not let a worker summary stand in for an independently observed result.
- Bound the whole process group. A wall-clock limit must kill the group on a stall, not leave child processes behind.
- Use a state short of approval. Candidate is an honest output when claims remain missing. A worker should not award itself PASS.
One dad-joke-sized warning: a timeout that kills only the parent is not a timeout. It is a process group hug with the interesting parts still running.
What this delegation proved — and what it did not
SLICE-008 proved an end-to-end delegated run against a real free model. It ended in a journalled CANDIDATE naming missing claims, with no PASS, and a reviewable diff.
It also tested the shapes that tend to become decoration. The execute phase refuses a signing key before spawn. The live process test checks that the delegated command cannot reach the key through environment, file path, or parent. A planted conftest.py may run and fail the suite, but it produces no signed record. Forged and missing emissions block before materialisation.
The wall-clock bound terminates a stalled run’s whole process group, records the timeout, and journals no candidate. The fork’s operator-facing command presents as ranex, while opencode’s MIT attribution remains in the tree.
Those are useful facts. They are not a claim that all delegation is safe.
RISK-06 stayed open when this slice closed. The model credential sat in a network-open loop, where it could be posted elsewhere. The record said to use a scoped, spend-limited key, and that the existing ranex run path still read the key before spawning. Recorded is not mitigated — until it is: SLICE-046 later closed RISK-06 by binding ranex run’s command inside the qualified confinement session, so the worker can no longer take the signing key. The controller that runs that session is still same-uid trusted infrastructure — see the gap list for what that still leaves open.
The slice also does not close merge collisions, verifiable separation, or gate quality. A weak gate can still accept plausible code. You own the target and the quality of the gate. The kernel cannot make either judgement disappear.
The source record lives in docs/slices/done/SLICE-008-first-delegation.md in the Ranex repository. Read it if you are designing this boundary. The failures are part of the useful material.
Questions people actually ask
These answers cover keyless measurement and the remaining model-credential risk.
Can a delegated agent expose its model API key?
The model credential remains in a network-open loop — use a scoped, spend-limited key. RISK-06, the risk that the worker could take the signing key, was open when SLICE-008 closed; SLICE-046 closed it later by binding ranex run inside the confinement session.
What does an environment built from empty protect against?
The delegated harness receives a deliberate environment rather than inherited trust, and delegation refuses to start when the signing-key variable is present.
Did SLICE-008 solve model credential exposure?
No. The credential still sits in a network-open loop, so use a scoped, spend-limited key. SLICE-008 left RISK-06 open for ranex run; SLICE-046 closed it later by binding the command inside the confinement session.
Your next move
Take one agent job that runs tests or scripts. Identify the secret that can authorise its result. Then inspect the live child and parent processes while the job runs. If that secret is reachable, split execution from measurement before you trust another green status.
Write down what remains open too. “Recorded, not mitigated” is not a failure of the notes. It is how the next person avoids mistaking a boundary for a finished fortress.
Try it. Break it. Tell me what broke. If this was useful, star the Ranex repository and leave an honest critique. A hard question is more valuable than a polite nod.
Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.
Top comments (0)