pre_activation role check fails for workflow_run events (should use workflow-based trust)

[microsasa]

pre_activation role check fails for workflow_run events (should use workflow-based trust)

Problem

When a gh-aw workflow is triggered via workflow_run, the pre_activation job always fails the role check because check_membership.cjs evaluates github.actor, which is github-actions[bot] for workflow_run events. Since github-actions[bot] has no repository collaborator role, the check outputs activated = false and the entire workflow silently skips.

This makes it impossible to chain gh-aw agentic workflows via workflow_run while keeping the role-based security gate.

Repro

1. Create a gh-aw workflow (agent.md) with workflow_run trigger:

   on:
     workflow_run:
       workflows: ["CI"]
       types: [completed]

2. Compile with gh aw compile

3. Trigger the upstream CI workflow (via PR, push, or another agent)

4. CI completes → workflow_run fires → pre_activation runs

5. check_membership.cjs checks github.actor = github-actions[bot]

6. Bot has no repo role → activated = false → workflow silently skips

Root Cause

check_membership.cjs uses context.actor to determine who triggered the workflow. For workflow_run events, GitHub Actions sets github.actor to the automation bot, not the original actor.

Why triggering_actor alone doesn't solve this

GitHub provides github.triggering_actor which preserves the original human in simple chains:

Context	pull_request event	workflow_run (human-initiated)
github.actor	alice	github-actions[bot]
github.triggering_actor	alice	alice

However, workflow_run chains are also commonly initiated by other agents or automated workflows (e.g., an overnight linter bot creates a PR → CI runs → downstream agent workflow triggers). In that case, github.triggering_actor is also github-actions[bot] — it's bots all the way down, and the role check still fails.

Current Workaround

Setting roles: all in the workflow frontmatter disables the pre_activation job entirely. This works but removes the role-based security gate, which is the only thing preventing untrusted actors from triggering agentic workflows.

Proposed Fix

For workflow_run events, the trust model should be based on which upstream workflow triggered the run rather than actor identity. GitHub's workflow_run already validates that the triggering workflow is in the same repository and provides github.event.workflow_run.workflow_id to identify it.

A possible approach:

1. For workflow_run events where github.triggering_actor is a human, check that human's role (current behavior but using triggering_actor)
2. For workflow_run events where github.triggering_actor is a bot, trust the event if the triggering workflow is in the same repository and is not from a fork — the upstream workflow's own activation already validated the original actor
3. Optionally allow an allowlist of trusted upstream workflow IDs in the frontmatter

This would allow workflow_run chains to work without roles: all while maintaining security against fork-based attacks.

References

• Differentiating triggering actor from executing actor
• Events that trigger workflows: workflow_run

[pelikhan]

Use the bots field.

[microsasa]

Ok, I was not aware of that. It works for me!