submit-pull-request-review: allowed-events not enforced at runtime by compiled lock file

[PureWeen]

Problem

allowed-events: [COMMENT] declared on submit-pull-request-review in the workflow source is accepted by the compiler (v0.62.2 and v0.69.3) but produces no runtime enforcement.

The compiled lock file's validation.json still permits all three event types:

"event": { "enum": ["APPROVE", "REQUEST_CHANGES", "COMMENT"] }

The GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG shows only "max":1 with no event restriction.

Impact

The only defense against the agent submitting APPROVE or REQUEST_CHANGES reviews is prompt-level instruction. A prompt injection via a crafted PR diff could steer the agent to call submit_pull_request_review(event="APPROVE") and the safe-outputs handler would accept it.

This is especially concerning for REQUEST_CHANGES which creates stale blocking reviews that can't be dismissed (see #27655).

Reproduction

1. Create a workflow with:

safe-outputs:
  submit-pull-request-review:
    max: 1
    allowed-events: [COMMENT]

2. Compile with gh aw compile
3. Inspect the compiled lock file — search for validation.json and HANDLER_CONFIG
4. Observe: allowed-events constraint is not present in either

Expected

The compiled validation.json should restrict the event enum to only ["COMMENT"], and/or the handler config should enforce the restriction server-side.

Discovered in

• dotnet/maui-labs PR Daily Test Coverage Improvement - File Watching and Compilation Functions #118
• PureWeen/PolyPilot PR #653

Workaround

Prompt-level instruction: "Always use event: COMMENT. Never use APPROVE or REQUEST_CHANGES."