## Over-permissive GITHUB_TOKEN and GCP WIF secrets granted to third-party reusable workflow on untrusted-triggerable events

**Component:** operator-foundry

A broad `permissions:` block (including `contents: write` and `actions: write`) plus GCP Workload Identity Federation credentials are granted at the workflow level to a third-party reusable workflow (`fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0`), which is invoked on events that can be triggered by untrusted/external actors (issue_comment / pull_request_target style triggers) without an author-association gate. A malicious or compromised trigger could obtain a highly privileged GITHUB_TOKEN and cloud credentials.

### Remediation
Move the broad `permissions:` block from workflow level down to the `dispatch` job and prune to the minimum the reusable workflow actually needs (drop `contents: write` and `actions: write` unless strictly required; the `stop-fix` job already demonstrates per-job narrowing). Pin `fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml` to a full 40-char commit SHA instead of `@v0`. Gate the `dispatch` job on `pull_request_target`/`issue_comment` with an author-association check (OWNER/MEMBER/COLLABORATOR) or a maintainer-applied label before any job that receives `id-token: write` or repo secrets. Restrict the GCP WIF provider's attribute condition to only accept tokens from protected-branch workflow runs.

---
*Source: Ex-Wing/Glasswing Konflux CI security assessment (Mythos), finding FIND-001*