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

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 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

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

Comments

[UnitBuilds]

I think it'd be useful if it did a check to see whether the PR actually requires the permission change, or not. Whether it's scoped or not and what sectors are affected by the permission change.

These can catch mistakes, drafts and help plug newly created holes before it's published to production

[JinHyuk Sung]

Thanks — this is a useful way to frame it.

I agree that read -> write by itself should not automatically mean “bad PR.” A workflow may legitimately need contents: write for things like releases, tags, generated commits, or publishing flows.

The first-run behavior I’m aiming for is narrower:

• surface the permission escalation
• show the exact workflow path
• keep it in warn mode by default
• ask a human to decide whether the increased permission is expected

The next evidence layer is probably what you’re pointing at:

• what job or workflow gained the permission
• whether the changed workflow appears to contain steps that need that permission
• whether the permission is scoped to the smallest job/workflow possible
• which repo areas or release paths could be affected
• whether the right reviewer approved that boundary change

I’d be careful about claiming Agent Gate can fully prove “this permission is required,” because that can become semantic judgment pretty quickly. But I do think it can make the review much more actionable by saying something like:

contents: write was added to .github/workflows/release.yml; this can affect release/tag/repo-content writes; no matching reviewer evidence was found; please confirm whether this is expected.

That feels like a better direction than either silently allowing the change or blocking every permission increase by default.

Appreciate the feedback — this points pretty directly toward a “scope + reviewer evidence” layer after the basic warning.

[UnitBuilds]

Never blindly accept, instead, these are the parameters passed to the reviewer. Chances are these changes are either done by a senior dev, who understands their purpose and this just validates for them that it's done properly, or it's a junior that messed up and created a leak, which with this, the senior dev can quickly see if it's done correctly based on the task and scope assigned.

Imo, this is the kind of thing I'd put as a pre-commit too, so the person creating the PR can look at it first to validate themselves and maybe add notes to each/ each violation on why it was done, maybe with a section where they can dump their scoped assignment, so it's more practical to understand what each commit was made for, who signed off on it, what were the potential problems and what was the criteria of the task. Could actually be a good way to seed training data for a LLM now that I think of it?