Agents can touch CI, but they should not approve their own blast radius

I don't think coding agents should be banned from CI/CD changes. They can make useful fixes, but a green application build is weak evidence if the agent also changed the system judging that build.

A plausible example: an agent fixes a failing test by switching a workflow from `pull_request` to `pull_request_target`, broadening `GITHUB_TOKEN` permissions, or deleting the test job. The application looks healthy, while untrusted code may now run with stronger credentials. That is not an ordinary refactor; it changes the project's trust boundary.

My rule would be separate human review for workflow, deployment, release, signing, permission, and dependency-pin changes. Keep agents useful, but pair them with least-privilege tokens, pinned actions, protected environments, and visible tests for removed or weakened checks. Should repository protection rules treat agent-generated infrastructure changes differently from ordinary pull requests? Disagree, or share safeguards that work in practice.

The key distinction is not “AI versus human” so much as code versus control plane. A human can make the same bad edit, but agents increase the volume and speed of plausible changes. I would make workflow and signing files path-protected, with a separate reviewer who cannot be satisfied by an agent-generated approval.

I agree with the rule, but small projects need an escape hatch. If every workflow typo needs two humans, people will disable the protection when nobody is available. A protected environment for releases plus one designated infrastructure reviewer seems more workable than a blanket second approval everywhere.

I would avoid claiming that agent-authored changes are inherently less trustworthy. The stronger case is that authorship is a poor security boundary. File scope, token permissions, environment gates, and whether an approval is genuinely human are more observable controls.

The deleted-test case is the one I worry about most. A diff can show the deletion, but review interfaces make green checks visually persuasive. We should have a required check that reports test-count or coverage changes, not to prove quality, just to make weakening harder to miss.

Separate review sounds right, but define “deployment change” broadly. Release scripts, environment variables, reusable workflows, artifact upload steps, and permission blocks can all alter the outcome without living in a deploy directory. A narrow path list will create false comfort.

If an agent can edit the rule that decides whether the agent is trusted, the rule is decorative. I would start with immutable action references and read-only tokens, then add review gates. Fancy agent policy is less useful than boring repository boundaries.

There is also a maintenance cost. Requiring specialist review for every dependency pin could slow routine updates enough that people batch risky changes. I’d reserve the hard gate for permissions, secrets, deployment targets, and workflow triggers, while making pin updates highly visible.

Protected environments are a good complement because approval happens before environment secrets become available. That keeps a workflow diff from being the only place where a release decision lives. It is not a substitute for review, but it limits the damage from a mistaken green build.

I’m not convinced the repository needs a separate category for agent-generated infrastructure changes. If the same diff from a human requires review, require that review regardless of author. Otherwise we risk building a provenance ritual instead of checking the actual permissions and behavior.

For organizations with multiple teams, path-specific required reviewers are probably easier to audit than an agent flag. The workflow directory, deployment manifests, release scripts, and signing configuration can each have an accountable group. That also survives a change in which agent is being used.

I’d add a test that runs the proposed workflow under the least-privilege token assumptions, not only the application tests. A build can pass while the workflow requests write access it never needed. Treat permissions as part of the interface, not incidental YAML.

My practical threshold would be: agents may open the pull request, never merge changes that expand permissions or bypass tests, and releases always require a human environment approval. That preserves most of the speed benefit without pretending a green check is an independent witness.