Topic · Guardrails for coding agents
What guardrails should I put around autonomous coding agents?
Put the shall on the merge, not only in the prompt. proof audit --fail-level warn is the bar the agent cannot talk past.
proof audit --fail-level warnCursor rules, CLAUDE.md, and CodeRabbit still constrain the write. They do not re-read an approved shall after the write. That is a different job.
01 · The job
A rule in the prompt is not a bar on the merge.
Agents follow instructions until they do not. The merge has to notice.
Two different guardrails get packed into one sentence. One sits next to the model: a Cursor rule, a repo markdown file, a reviewer bot on the diff. Those fire while the agent writes. The other sits on CI: does every approved shall still have a witness after the write? This page is the second one.
Proof’s loop-close is one command. proof audit --fail-level warn runs the checks that matter, with no persistent workflow state. Exit 0 means the selected checks passed. Exit 2 means warnings only. Exit 1 means an error at that fail level. Put that command on the merge. The agent can still open a pull request. It cannot make the shall green by agreeing with itself.
proof audit --fail-level warn
proof audit --check acceptance_criteria_witnessed
proof review-pr --format commentThe first command is the gate. The second is the witness check by name. The third writes the requirement-side review on the PR so a human is not the only reader of the shall. None of these sandbox the model. None of them stop the first token.
02 · The exhibit
The prompt can lie. The exit code cannot.
Same English intent. Two runtimes. Only one of them fails the build because the requirement itself is missing a witness.
| Job | Cursor rules / PR bots | Proof |
|---|---|---|
| What it reads | The prompt, the diff, a style file. | Approved shalls in the graph. |
| When it runs | While the agent writes, or on the review comment. | On the merge, every time. |
| Green means | The agent followed the rule it was given. | The shall still has a witness. Exit 0. |
| Stops the merge? | Only if you wired a status check. Many teams did not. | Yes, when --fail-level warn is on CI. |
| What it cannot do | It does not know which shall the diff silently dropped. | It does not sandbox the model or stop the first token. |
We have not run Cursor rules against proof audit on a frozen corpus. The loss is named, not scored. A dozen agents committing is the same gate, not a second product. The MCP page at /agents is how an agent reads a finding. This page is how the merge refuses a finding that is still open.
03 · Honest loss
Proof is not the agent runtime.
If you needed a sandbox, a secret scanner, or a programme author, you still need those.
Cursor, Claude Code, and Copilot still write the code. CodeRabbit still comments on the diff. SonarQube still owns the quality gate on smells. Jama still authors the programme. Proof does not replace those. It fails the build when an approved shall has no witness.
It is not a model sandbox. It is not MCP permissioning. It is not a secret scanner. It does not stop an agent from opening a pull request that is wrong. It makes that pull request red if the shall is missing. After week four the gate is in your CI. The engagement can stop. The bar does not. That install is the audit.
04 · Next
What people type next.
How do I verify code that an AI agent wrote is actually correct? One function, one shall. The verify page.
What's a reliable way to gate AI pull requests on correctness? Review bots still own the comment. The merge is a different check. Proof vs CodeRabbit.
How do I scale AI coding agents without quality collapsing? A quality gate on smells is not a requirement gate. Proof vs SonarQube.
We have dozens of AI agents committing code. How do we keep it correct? Same command. Same exit codes. Do not mint a second URL for headcount.