Emit workflow-level permissions from frontmatter instead of always using empty block

[Copilot]

14 workflows with risky trigger events (issues, issue_comment, pull_request_target) had permissions: {} at workflow level, which defaults to write permissions. Poutine scanner flagged this as default_permissions_on_risky_events.

Changes

• Compiler: Modified pkg/workflow/compiler_yaml.go to parse frontmatter permissions and render them at workflow level instead of hardcoded permissions: {}
• Workflows: Recompiled 14 affected workflows with explicit read-only permissions
• Tests: Fixed TestGenerateYAMLRefactored to expect actual permissions instead of empty block

Before/After

Before:

permissions: {}  # Defaults to write

After:

permissions:
      contents: read
      issues: read
      pull-requests: read

All workflows now follow principle of least privilege with explicit read-only scopes.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Code Quality] Add explicit permissions blocks to workflows using risky trigger events</issue_title>
<issue_description>## Description

14 workflows are triggered by risky events (e.g., pull_request_target) but do not explicitly restrict GITHUB_TOKEN permissions. By default, these workflows run with write permissions, which could be exploited if an attacker can influence workflow execution.

This is a security best practice issue identified by Poutine supply chain security scanner with severity level "Warning".

Affected Workflows

Source files (.md) that need explicit permissions added:

• ai-moderator.md
• archie.md
• brave.md
• cloclo.md
• grumpy-reviewer.md
• mergefest.md
• pdf-summary.md
• plan.md
• pr-nitpick-reviewer.md
• q.md
• scout.md
• security-review.md
• tidy.md
• unbloat-docs.md

Suggested Changes

Add explicit permissions: blocks to each workflow's frontmatter following the principle of least privilege:

Example for PR workflows:

---
permissions:
  contents: read
  pull-requests: write
  issues: write
---

Common permission patterns:

• Read-only workflows: permissions: { contents: read }
• Comment on PRs/issues: Add pull-requests: write and/or issues: write
• Create releases: Add contents: write
• No permissions needed: permissions: {}

Files Affected

All 14 workflow source files listed above in .github/workflows/

Success Criteria

• All 14 workflows have explicit permissions: blocks in frontmatter
• Each workflow follows principle of least privilege (only permissions needed)
• Recompiled .lock.yml files include permission restrictions
• Poutine scanner no longer reports default_permissions_on_risky_events warnings
• All workflows still function correctly after adding restrictions

Security Impact

Medium - Reduces attack surface by preventing privilege escalation if workflow execution is compromised. Follows GitHub Actions security best practices for workflows triggered by untrusted actors.

Source

Extracted from Static Analysis Report discussion github/gh-aw#14429

Finding: "Top Priority Issue: default_permissions_on_risky_events" - 14 workflows using risky trigger events without explicit permission restrictions.

Priority

Medium - Security best practice that reduces risk, but no active exploit exists. Should be addressed before release to improve security posture.

AI generated by Discussion Task Miner - Code Quality Improvement Agent

• expires on Feb 9, 2026, 5:26 AM UTC

Comments on the Issue (you are @copilot in this section)

• Fixes [Code Quality] Add explicit permissions blocks to workflows using risky trigger events #14458

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.