Security sub-agent: add workflow_call permission inheritance checks

[fullsend-ai-retro]

What happened

On PR #1611, the review bot's initial review (May 27 17:38 UTC) found only medium/low findings: protected-path detection, incorrect prioritize path resolution, and a stale comment. Within 50 minutes, human reviewer waynesun09 found a CRITICAL bug: permissions: {} at workflow level blocks OIDC token minting in all per-org stage jobs because reusable workflows called via workflow_call cannot elevate beyond the caller's permission grant. waynesun09 also found HIGH issues: secrets: inherit exposing all repo secrets to the prioritize workflow, and prioritize.yml missing secrets: declaration under workflow_call. The bot's security sub-agent has detailed guidance for GHA workflow command injection and permission-expansion detection, but nothing about how permissions propagate (or fail to propagate) through workflow_call chains. The bot ran 3 more review cycles and never flagged these issues.

What could go better

The security sub-agent (skills/pr-review/sub-agents/security.md) covers permission expansion and role escalation in workflow files, but lacks specific knowledge about GitHub Actions' permission inheritance model for workflow_call. This is a well-documented platform behavior: called workflows inherit the caller's effective permissions as a ceiling, and cannot request elevated permissions. When a caller sets permissions: {}, all called workflows get zero permissions regardless of their own permissions: blocks. This pattern is distinct from issues #1275 (correctness-focused workflow_call chain tracing), #2658 (verifying tool permission requirements), and #2933 (CI security anti-patterns like verbose scanning). High confidence this is a systematic gap: the bot had 4 review cycles and never caught it, and #898 documents the same class of gap on another large PR.

Proposed change

Add a 'workflow_call permission inheritance' section to skills/pr-review/sub-agents/security.md with these checks: (1) When a workflow sets permissions: {} or restrictive permissions at the workflow level, verify that all jobs calling reusable workflows via uses: have explicit permissions: blocks granting what the called workflow needs (especially id-token: write for OIDC). (2) Document that the caller's effective permissions are the ceiling — called workflows cannot exceed them. (3) Flag secrets: inherit as a least-privilege violation when explicit secret passing is feasible, with medium severity. (4) When a workflow_call trigger declares inputs: but not secrets:, and the caller passes explicit secrets, flag the missing declaration as a runtime failure.

Validation criteria

Run the security sub-agent against a test diff containing: (a) a workflow with permissions: {} at the workflow level and stage jobs calling reusable workflows without explicit permission blocks, and (b) secrets: inherit on one job while others pass secrets explicitly. The sub-agent should produce at least one high-severity finding about the permission inheritance gap and at least one medium finding about secrets: inherit.

---

Generated by retro agent from fullsend-ai/fullsend#1611

[fullsend-ai-prioritize]

RICE Priority Score: 2.4

Score breakdown

Dimension	Score	Reasoning
Reach	2	The PR review bot's security sub-agent runs on all PRs across the organization. Any PR touching GitHub Actions workflow files (a common pattern across repos) is affected by this detection gap. Issue #898 documents the same class of gap on another PR, confirming it is a systematic blind spot rather than a one-off miss. Score of 2 reflects that most active users rely on the bot for security review coverage.
Impact	1.5	The bot failed to catch a CRITICAL bug (workflow_call permission inheritance blocking OIDC) and HIGH issues (secrets: inherit, missing secrets declaration) across 4 review cycles. Missing these means security vulnerabilities in CI/CD pipelines can ship undetected, potentially causing broken deployments and secret exposure. This is a significant gap in the bot's security detection capability, warranting a score of 1.5.
Confidence	0.8	The issue is exceptionally well-documented: it references the specific PR (#1611), the exact human review comment, related issues (#1275, #2658, #2933, #898), the specific file to modify, four concrete checks to add, and clear validation criteria. The scope is well-bounded. Score of 0.8 reflects high confidence with only minor uncertainty about edge cases in implementation.
Effort	1	The change is primarily adding a new section to a single file (skills/pr-review/sub-agents/security.md) with four specific detection rules. It requires understanding GHA permission inheritance semantics but the issue already documents them precisely. Validation involves running the sub-agent against a test diff. This is a medium-complexity knowledge-base enhancement, not an architectural change.

Formula: (2 x 1.5 x 0.8) / 1 = 2.4