Would you block a PR that changes GitHub Actions contents permission from read to write?

The Scenario

A sandbox PR changed one GitHub Actions workflow permission: permissions: contents: write. The base branch had: permissions: contents: read. That is the concrete case I am trying to calibrate.

Agent Gate reported:

• Agent Gate: NEEDS HUMAN DECISION
• Decision: warn
• Why: contents permission increased from read to write
• Path: .github/workflows/demo-release.yml
• Recommended next step: review the workflow permission change before merging
• Policy status: warning today; eligible to become a merge gate after tuning
• Rule: workflow/permission-escalation
• Policy source: built-in default

Live PR comment proof: https://github.com/sjh9714/agent-gate-install-smoke-20260617/pull/13#issuecomment-4828248162

What Matters

What matters to me is that this did not depend on an LLM noticing the change. The Action did not:

• checkout PR code
• run repository scripts
• call an LLM at runtime
• load policy from the PR head branch

The first-run repo config was also absent. Agent Gate used its built-in default policy and recorded: configSource: default.

The Question

I am not trying to claim that the PR is automatically bad. A permission increase can be intentional. The question is what CI should do when it sees this kind of boundary change.

My current default is:

• warn on first run
• keep the report human-readable
• let teams promote this finding to block after tuning

For AI-generated PRs, I think deterministic CI evidence is useful because agent changes can touch workflow and security boundaries as part of ordinary work. But this specific finding is broader than AI: any PR that raises GitHub Actions permissions may deserve deliberate review.

Question: In your repo, is this block, warn, or noise? What extra evidence would make it actionable?

Repo: https://github.com/sjh9714/Agent-Gate