Revert: permissions: {} is correct behavior - no changes needed

[Copilot]

This PR reverts the previous changes that incorrectly modified workflow-level permissions.

Problem

The original issue and my initial implementation were based on a misunderstanding of GitHub Actions permissions behavior:

• Incorrect assumption: permissions: {} defaults to ALL permissions ❌
• Actual behavior: permissions: {} explicitly disables all permissions ✅

Per GitHub Actions documentation:

You can use permissions: {} to disable permissions for all of the available scopes.

What This PR Does

Reverts commits 4f3089e, bf832cd, and eecd021 which incorrectly changed workflow-level permissions.

The original compiler behavior was correct and MORE secure:

# Workflow level - NO permissions (most secure)
permissions: {}

jobs:
  agent:
    # Job level - explicit minimal permissions
    permissions:
      contents: read
      issues: read

My previous changes incorrectly changed this to:

# Workflow level - read permissions (less secure)
permissions:
  contents: read
  issues: read

jobs:
  agent:
    permissions:
      contents: read
      issues: read

This actually REDUCED security by granting read permissions at workflow level that weren't needed.

Changes Made

• Restored pkg/workflow/compiler_yaml.go: Returns to always using permissions: {} at workflow level
• Removed pkg/workflow/tools.go additions: Deleted the hasRiskyTriggers() function
• Deleted pkg/workflow/risky_triggers_test.go: Removed unnecessary test file
• Recompiled 16 workflows: All now correctly have permissions: {} at workflow level

Affected Workflows

All workflows restored to correct permissions: {}:
ai-moderator, archie, brave, ci-doctor, cloclo, dev-hawk, grumpy-reviewer, mergefest, pdf-summary, plan, pr-nitpick-reviewer, q, scout, security-review, tidy, unbloat-docs

Conclusion

The original issue report was based on a misunderstanding. The workflows were already following security best practices by using permissions: {} at the workflow level. No changes to permissions were needed.

Thanks to @pelikhan for catching this error.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[deep-report] Add explicit permissions to risky-trigger workflows flagged by zizmor</issue_title>
<issue_description>### Description
Static analysis found 14 workflows triggered by risky events (issue_comment, pull_request_target, workflow_run, etc.) that still use default permissions. This violates least-privilege and increases attack surface. Add explicit minimal permissions: blocks to the affected workflows and recompile lock files.

Affected workflows (from the 2026-01-29 static analysis report): ai-moderator, archie, brave, cloclo, grumpy-reviewer, mergefest, pdf-summary, plan, pr-nitpick-reviewer, q, scout, security-review, tidy, unbloat-docs.

Expected Impact

Reduces security exposure on risky triggers, aligns with least-privilege best practices, and clears the zizmor warnings from the daily scan.

Suggested Agent

Workflow Normalizer or Security Guard Agent

Estimated Effort

Medium (1-4 hours)

Data Source

Static Analysis Report discussion #12558 (2026-01-29) and this DeepReport run (2026-01-29).

AI generated by DeepReport - Intelligence Gathering Agent

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

• Fixes [deep-report] Add explicit permissions to risky-trigger workflows flagged by zizmor #12568

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[pelikhan]

@copilot docs say: You can use the following syntax to disable permissions for all of the available permissions:

permissions: {}

[Copilot]

@copilot docs say: You can use the following syntax to disable permissions for all of the available permissions:

permissions: {}

You're absolutely right. I misunderstood the GitHub Actions permissions behavior. permissions: {} explicitly disables all permissions (most secure), not enables them.

My changes actually made things LESS secure by replacing permissions: {} (no permissions) with explicit read permissions at the workflow level.

The original design was correct - workflow-level permissions: {} with job-level permissions is more secure than workflow-level read permissions. I'll revert these changes in commit c8a9f12.