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: with the Trust Verify job wired in as a required check — the way the Flow Agents repo itself runs it — every pull request re-runs the real verification fresh in a clean environment the agent can't pre-disable, and 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.

Honest residual: 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.

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.

Precise words: tamper-evident locally, tamper-resistant up to the CI identity boundary — never "tamper-proof."

Force-merge past branch protection, or approve your own malicious change. Nothing machine-side stops this. It is the irreducible human boundary — the one place the whole model depends on trusting a person, not a proof. We name it in the open instead of hiding it. The mitigation is ordinary and honest: 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 reconcile job 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.