Provenance, Not Judgment: Gating Pull Requests an Agent Wrote Faster Than You Can Read Them

A column published on devops.com opens with a near-miss: the author approved a clean one-line change to a retry helper, produced by an agent wired into the workflow to grind through flaky-test toil, in about the time it takes to drink a coffee ^[1][2]. The change widened the retry window and dropped the jitter on a client that fans out to a downstream service the team does not own, which under a partial outage is a synchronized retry storm that reads as one removed line and behaves as an incident ^[3][4]. It was caught by a change-budget gate, because the file sat behind a protected path, and not by the reviewer, who had already clicked approve ^[5].

That is the whole argument in one anecdote. The author's conclusion is that "the diff looked fine" was never a control, and that the agent's output was not bad but good enough to pass the smell test ^[6].

The throughput numbers explain why reviewing harder does not help. Code review was built around a human bottleneck: one engineer writes a few hundred lines a day, another reads them, and the slowness is the rate limit that keeps the queue legible ^[7]. A single agent can open a dozen pull requests an hour, each individually plausible, each touching a different corner of the system ^[8]. At that rate one agent produces a reviewer's described daily load of 20 agent-authored pull requests in under two hours ^[9][14]. The author's read is that a reviewer scanning 20 of those a day is rubber-stamping with extra steps, and will wave through the one that matters because it looks like the 19 that did not ^[14].

There is a sharper problem underneath the volume: the agent can see the test suite and write to it, so green checks are partly self-issued ^[10]. Which is why the piece insists eval suites be independent. An agent that can edit the tests can certify its own work ^[15].

The proposed reframe is that an AI-authored change is an artifact from an untrusted producer, and that shape of problem already has an answer ^[11]. The piece points at SLSA, which formalizes provenance as a signed attestation travelling with an artifact to answer how it was produced, in-toto for the attestation format, and Sigstore for signing and verification, noting that none of it was built for agents and all of it applies ^[12]. The record it wants is machine-checkable rather than a label a human reads: which model and version, what task spec, which tools the agent was allowed to call, which tests and evals gated the change and what they returned ^[13]. Default deny. No attestation, no review ^[16].

Worth noting what the source does not deliver. The gate is presented as roughly 20 lines of vendor-neutral pipeline config requiring an attestation to be present, its signature valid, and named fields populated, but the published field list is cut off mid-word in the material we have, at model_id, task_spec_ref, tools_allowed and a truncated test field ^[17][18].

Watch who holds the signing key for an agent's attestations, and whether eval repositories are actually moved outside the agent's write scope or merely declared off-limits. Also watch what happens to the rejected-at-the-door queue: a deny-by-default gate converts silent bad merges into visible backlog, and someone has to own that backlog before the gate gets turned off for being noisy.