This looks like it has been this way since /ok-to-test was added in 2ca619ab on 2026-03-05.

The problem is pretty simple:

• .github/workflows/ok-to-test.yaml grabs pr.head.sha
• passes it into qualification.yaml
• qualification.yaml checks out that SHA
• then it runs local actions from ./.github/actions/*
• the caller gives that path id-token: write and security-events: write

So once a maintainer comments /ok-to-test on a fork PR, the PR author controls the local action definitions that run in a privileged workflow.

I don't think "a maintainer had to approve it" is enough protection here. It's too easy to approve a test run without separately auditing changes under .github/actions/** in the fork.

This repo already uses the safer pattern elsewhere: on-push-comment.yaml explicitly calls out guarded checkout to avoid running untrusted code in a privileged workflow.

Reasonable fixes would be either:

• make /ok-to-test unprivileged and skip the jobs that need elevated permissions there, or
• keep the privileged path on trusted base-repo workflow/action code only.