The pull request was clean. Tight commit message, a one-line fix to a retry helper, green checks. I approved it in the time it takes to drink coffee. It came from an agent we’d wired into our workflow to chew through flaky-test toil, and it had done exactly that all week.

What I almost missed: The change widened the retry window and dropped the jitter on a client that fans out to a downstream service we don’t own. Under normal load, invisible. Under a partial outage, that’s a synchronized retry storm — the kind of thundering-herd regression that reads as one removed line and behaves as an incident. A change-budget gate caught it because the file lived behind a protected path, not because I did. I’d already clicked approve.

That was the moment I stopped trusting my own review as a control. Not because the agent was bad but because it was good enough that the diff looked fine, and ‘the diff looked fine’ is not a control; it’s a vibe.

Why Human Review Stopped Scaling

Code review was designed around a human bottleneck. One engineer writes a few hundred lines a day, another reads them and the slowness is load-bearing — it’s the rate limit that keeps the queue legible. Agents delete that assumption. A single agent can open a dozen PRs an hour, each individually plausible, each touching a different corner of the system.

Plausible is the problem. Agent-authored changes are optimized to pass the smell test. They have clean names, reasonable commit messages and tests that go green, because the agent can see the test suite and write to it. A reviewer scanning 20 of these a day is not really reviewing — they’re rubber-stamping with extra steps, and they’ll wave through the one that matters because it looks like the 19 that didn’t.

You cannot fix this by reviewing harder. The bottleneck you removed isn’t coming back. You fix it by moving the control out of the human’s head and into the pipeline, where it runs the same way on PR number 1 and PR number 200.

Provenance is the New Gate

Here’s the uncomfortable reframe: An AI-authored change is an artifact from an untrusted producer, and we already know how to handle those. We’ve spent years building supply-chain controls for exactly this shape of problem — code entering the pipeline from somewhere you don’t fully trust, that you need to verify before you act on it.

The supply-chain world settled on a clear idea: Don’t trust the artifact, verify its provenance. The SLSA framework formalizes this as a signed attestation that travels with an artifact and answers how it was produced. The in-toto project gives you the attestation format. Sigstore gives you the signing and verification. None of this was built for agents, and all of it applies directly.

So make every agent-authored change carry a provenance record, and make that record machine-checkable. Not a label a human reads — a signed attestation the pipeline enforces. Which model and version produced this change? What prompt or task spec drove it? Which tools was it allowed to call? Which tests and evals gated it? What they returned? If the change shows up without that record, it doesn’t get reviewed. It gets rejected at the door.

This is the inversion that matters. The default is deny. The agent earns its way into the human queue by proving where the change came from, not by looking convincing.

The Gate, in About 20 Lines

The control I trust is boring on purpose. A pipeline stage, vendor-neutral, that refuses to advance an AI-authored change unless it carries a verifiable provenance attestation and clears the eval and policy gates. Nothing here is exotic — it’s the supply chain playbook pointed at a new kind of producer.

# ci: gate for AI-authored changes. deny-by-default.
gate:
  applies_when: change.author_type == "agent"
  require_all:

    # 1. provenance must exist and verify (SLSA-style attestation, sigstore-signed)
    - attestation.present: true
    - attestation.signature_valid: true
    - attestation.fields_present: [model_id, task_spec_ref, tools_allowed, tests_run]

    # 2. executable eval gate — the agent's own tests don't count alone
    - eval_suite.passed: true            # independent suite the agent cannot edit
    - eval_suite.coverage_delta >= 0     # no silent removal of checks

    # 3. policy-as-code — least privilege, protected paths, change budget
    - policy.protected_paths_untouched: true   # iac/prod/*, auth/*, billing/*
    - policy.requested_scopes ⊆ task_spec.granted_scopes
    - policy.lines_changed <= budget.per_pr     # change-budget guardrail

  on_fail: reject            # never auto-merge; route to human with the failing reason
  on_pass: route_to_human    # human reviews a verified change, not a raw one

Three things make this hold up. The eval suite is independent of the agent and the agent can’t write to it, so green isn’t self-certified. The policy checks are mechanical facts about the change — paths, scopes, line counts — not judgments about whether the code is ‘good’ and the failure mode is rejection, not merge. A gate that auto-merges on pass and only flags on fail has the logic backwards; the whole point is that nothing reaches a human until it’s already provably in-bounds.

Staged Autonomy, and What Still Breaks

Provenance and policy tell you whether to trust a change. Staged autonomy decides how much rope the agent gets to begin with. I run agents through four levels:

Observe (read-only, it comments)

Recommend (it drafts, a human commits)

Bounded-write (it merges, but only inside an explicit allowlist of paths and scopes with a change budget)

Governed (wider authority, every action attested and reversible)

An agent earns the next level by accumulating a clean track record at the current one. It doesn’t start at bounded-write because it sounded confident in a demo.

I’ll be honest about the holes, because pretending they’re closed is how you get burned. Provenance proves origin, not correctness — a signed attestation on a wrong change is a well-documented wrong change. Your eval suite is now a security boundary, which means a gap in coverage is a gap in your defenses, and agents are very good at finding the path that your tests don’t watch. Policy as code only constrains what you thought to encode; the regression that bit me was caught by a path rule, but a subtler one could live entirely inside an allowed path. Every signing key and policy engine you add is itself attack surface — the OWASP guidance on supply chain and AI risks is worth reading precisely because these controls become the thing worth attacking.

None of that is an argument against the gates. It’s an argument for treating them as load-bearing infrastructure — versioned, tested, owned — instead of a checkbox. The eval suite and the policy bundle deserve the same on-call rigor as the service they protect.

The Takeaway

The agent proposes; the pipeline disposes. Stop asking whether the diff looks fine, because at agent volume your judgment isn’t the control and was never going to be. Make every AI-authored change prove its provenance, pass an eval gate it can’t edit and clear policy rules a machine enforces the same way every time. Build those controls outside the agent’s reasoning loop, where its confidence can’t reach them.