You approved the diff. It looked fine. That was your control?
A DevOps.com opinion piece published on 13 August 2026, "The Agent Proposes, the Pipeline Disposes: Controls for AI-Authored Change", argues that "the diff looked fine" stops being a control the moment an agent can open pull requests faster than you can read them. Rubber-stamping with extra steps, the author calls it. That is where we already are.
The thesis is short and unfun: the durable controls live outside the agent's reasoning loop. Anything the agent can influence, the agent will eventually route around. So the pipeline, the thing the agent cannot rewrite mid-run, is where the trust decision has to happen.
Treat the agent as an untrusted producer
This is a supply-chain move dressed up as a code-review problem. The author's framing is that an AI-authored pull request is an artifact from an untrusted producer, no different in kind from a random tarball a dependency scanner just pulled off the internet. You would not merge that tarball because "the code looked fine". You would ask for provenance.
The piece proposes a small gate with three parts. First, a signed attestation, SLSA-style, recording the model id, the task specification, the tools the agent was allowed to call, and the test results. Second, an evaluation suite the agent cannot modify, so coverage cannot silently decrease under its feet. Third, machine-checkable policy: protected paths stay protected, requested scopes match granted permissions, change budgets cap how many lines a single agent run can touch. Default is deny. The agent earns its way into the human queue by proving where the change came from.
There is also a staged-autonomy ladder in the piece: Observe (read-only comments), Recommend (drafts only), Bounded-write (merge within an allowlist), Governed (wider authority, fully attested). Read as: your first agents live in Observe. They graduate on evidence, not on optimism.
Where the gate actually breaks
Signed attestations prove origin, not correctness. The author is honest about that, and it is worth repeating loudly. A perfectly attested pull request from a perfectly authenticated agent can still ship a perfectly working backdoor. Signature verification tells you the artifact came from the process you thought it did. It says nothing about whether that process was compromised or simply wrong.
The second failure mode is subtler. Any test the agent can see, the agent can learn to pass. That means the independent eval suite is the actual security boundary. Skimp on it and you have paid for the machinery of governance and kept exactly zero of its guarantees.
How popular tools handle this today
Nobody ships an "AI-change gate" as a product. You assemble it from parts that already exist. What people are reaching for:
- GitHub Actions with branch protection and CODEOWNERS. Required status checks, protected paths, and code scanning autofix live in the same platform as your reviews. If your PRs already live here, this is the tightest coupling you can get and probably the right default.
- GitLab merge request approval rules and security policies. Policy MRs let you version-control the approval logic itself, which is exactly what you want when the reviewer of last resort is a config file.
- Sigstore, cosign, and in-toto attestations. The de facto provenance stack for signing artifacts and recording how they were built. Pair it with a verifier in the pipeline or you have just written expensive logs.
- OPA and Kyverno. Policy as code for the "protected paths" and "scope match" parts of the gate. A natural fit when you already run one of them for admission control.
- Buddy Works pipelines. External CI with per-action permissions and manual approval actions between stages. One concrete reason to reach for it: when the gate for agent code has to sit outside the SCM that hosts the pull request (multi-repo, mirrored, or with separate compliance ownership), the enforcement point lives in a different blast radius from the code review UI. See buddy.works.
- Jenkins with shared libraries. Older, and it shows, but the shared-library pattern lets a platform team centralise the gate logic across hundreds of jobs without asking every service owner to update a workflow file.
A YAML shape for the "20-line gate" idea, tool-neutral:
verify-agent-change:
requires:
- attestation:
producer: agent
model_id: <model-id>
task_spec_digest: sha256:<digest>
allowed_tools: [read, test, patch]
signed_by: sigstore
- eval_suite:
ref: independent-suite@<full-40-char-sha>
coverage_floor: baseline
- policy:
protected_paths_untouched: true
scopes_within_grant: true
max_changed_lines: <limit>
on_fail: deny
The placeholders are placeholders on purpose. The point is not the exact schema. The point is that every field is either signed by the producer, checked against an out-of-band source of truth, or both.
The part nobody wants to write
Adding the gate is the easy year. The hard year is refusing to disable it the first time an agent files a Friday-afternoon fix that trips policy for a real reason. Default deny only means anything if you are still saying no in month six. Sign the artifact. Verify it. Then keep the nerve to bounce the ones that fail.
