We can't certify an agent is right. No one can.

Edit the bundle, the logs, or the workflow state on your own machine. Locally, the evidence is a tamper-evident hash chain — break a link and the chain no longer verifies. But the authoritative catch isn't local. Add the trust-verify action to your pull requests and make its check required — the way the Flow Agents repo does, where it runs under the name Trust Reconcile — and every pull request re-runs the real verification fresh in a clean environment the agent can't pre-disable, then reconciles your bundle against its own results. CI never trusts your bundle as a source of truth — it only uses it to detect divergence. A claimed pass that CI shows failing, or a command CI never ran, fails the job.

One level down, a local gate refuses an agent's direct writes to the protected workflow and gate files themselves. It works by reading the command before it runs — and a command string doesn't always say what it will do. Hardening it overnight closed a run of ways past it: a raw newline used as a separator, a bare &, eval with a quoted operand, a redirect placed before the command word, source and ., and ANSI-C $'cd'. One class stays open, and can't be closed there: a directory change reached through a shell variable, an array element, a positional parameter or printf -v leaves no signal in the string. X=cd; $X /path is character-for-character identical to X=notcd; $X /path, which doesn't change directory — separating the two needs values that exist only while the command runs. A second gap sits beside it: a redirect written inside a quoted operand, as in eval "echo … > <gate file>" or sh -c "…", is never extracted as a target at all. Both are open issues in the public repo. That gate raises the cost of reaching a protected file; it was never the boundary, and the code now says so in the file itself. What catches the write is what catches the rest — it breaks the local hash chain, and CI re-runs your declared checks fresh in an environment the agent never touched. Where we're taking it: stop predicting what a command will do, and check what actually changed, by hashing those files before and after.

Where this stops: a determined agent can still flip a local kill-switch through its own shell. That's exactly why the authority lives in CI, not in the local gate. And the CI catch is only authoritative once you make the check required — installing the tool doesn't configure your branch protection for you. (This site's own repo now requires the check too, no-bypass — and its workflow definitions and CI scripts require owner review via CODEOWNERS.)

Fabricate a green result, or launder the exit code (npm test || true). The local gate rejects a verify command carrying ||, and CI re-runs your declared checks itself — then, with signing enabled (one flag on the action; on where we build Flow Agents, off by default), signs the result with a keyless Sigstore identity that only exists inside CI. An agent on your laptop has no such identity — it cannot mint that signature, no matter how clever the prompt. A fabricated "green" simply can't be signed.

On your laptop, tampering is detectable, not impossible. It becomes impractical at the CI identity boundary, where the signing identity lives: tamper-evident locally, tamper-resistant up to that boundary — never "tamper-proof."

Run the tests, watch them pass, then keep editing. The pass was real when it happened, and nothing locally re-runs it when the code moves underneath it. Same story if the agent runs one test file instead of the suite, or edits the test until it goes green — the gate reads what actually ran, and what actually ran was green. On the pull request CI closes most of this: it re-runs your declared checks against the final code, and evidence sealed against an earlier commit is treated as if it weren't there at all.

Where this stops: an edited test survives the trip, because CI runs the test you wrote. That one is on review, not on the machine. And before the pull request exists, all three of these are on you.

Force-merge past branch protection, or approve your own malicious change. Nothing machine-side stops this, and nothing ever will. It is the irreducible human boundary — the one place the whole model depends on trusting a person, not a proof. What's left is ordinary: branch protection with enforced admins, code-owner review on the gate and CI config, and a human who declines the --admin shortcut.

CI answers exactly one question — did the declared checks pass? — and is silent on the claim with no test behind it ("added validation and tested it," "verified the migration is reversible," "no security regression"). CI can't turn red on a claim it can't execute. We surface what was skipped, not just what passed.

Wire the trust-verify action in as a required check and it re-runs your declared checks, reconciling them against what the agent claimed it ran — if they diverge, CI goes red on the discrepancy itself — and, with signing on, signs the result with an identity that only exists inside CI, which an agent on a laptop cannot forge. CI's ephemeral green becomes a portable, independently recomputable receipt of what passed and what it stood on.

The check fires while the agent works, not after a push, a PR, and a CI cycle — so a real failure surfaces before anything leaves the laptop. If the agent claims a check passed but nothing captured shows it ran, the gate doesn't take the claim on faith — it re-runs the project's own declared check itself, right there, and a real result stands in place of the claim. And if the agent tries to launder the exit code (npm test || true), the local gate rejects it as evidence on the spot — the same thing CI would catch on the PR, just earlier, before a push ever happens.