Scope id-token: write to the publishing job

The workflow's top-level permissions: grants no id-token. Only the publish job requests id-token: write, ideally behind a protected environment. Jobs that run tests or install dependencies, where untrusted third-party code executes, never have a publish-capable token in memory to steal.123

permissions:
  contents: read           # workflow default: no id-token

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read        # explicit: no OIDC token minted here
    steps:
      - uses: actions/checkout@v7
      - run: npm test
  publish:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write       # scoped to the publish job only
    environment: release
    steps:
      - uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0

Any job, including untrusted test code, can read the publish token out of runner memory.

permissions:
  contents: read
  id-token: write     # a publish token exists for every job and every step

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test   # runs untrusted dep code with the token in memory
  publish:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0

Better Auth, browser-use, FastAPI, and Vite keep OIDC token minting scoped to the jobs that actually publish or release.

  build_publish_image:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
      attestations: write
      id-token: write

    if: github.repository == 'vitejs/vite'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write

permissions: {}
# ...
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

permissions: {}
# ...
    environment: Release
    permissions:
      contents: write
      pull-requests: write
      id-token: write

On Mastra, a StarSling agent moved id-token: write off the workflow default and kept OIDC token minting on the publish jobs only.

• Read the Mastra customer story
  Customer story

  Merged 2026-05-12

  ci(security): scope id-token: write to publish jobs only

  StarSling moved id-token: write out of workflow scope so only publish jobs can mint an OIDC token.

  Read the Mastra customer storyView PR #16509 in mastra-ai/mastra (opens in new tab)

id-token is not the only permission that leaks by sitting at the wrong scope. A workflow that grants write permissions on an event an outsider can trigger (pull_request_target, issue_comment, workflow_run, pull_request_review) hands attacker-controlled activity a write-capable token: enough to forge commits, approve pull requests, or dispatch a release. The elementary-data incident chained exactly this pivot: a default write token plus script injection forged a github-actions[bot] commit, dispatched the release workflow, and published a malicious package to PyPI in ten minutes. The fix is the shape this page already teaches: keep the top-level permissions: read-only and grant contents: write or pull-requests: write only in a job that never runs on an untrusted trigger, typically by splitting the workflow in two: an unprivileged pull_request job that uploads an artifact, and a separate workflow_run job that holds the write token and treats that artifact strictly as data (a comment body, a status value), never as something to execute or publish, because the artifact is still attacker-controlled input. GitHub shipped workflow-trigger policies in June 2026, but they are opt-in and evaluate-mode, so nothing changes on default configuration. A write token on an untrusted trigger is one of the ten attack vectors the ci-secure skill scans workflows for.

When id-token: write sits at the workflow level, the runner mints a publish-capable OIDC token for the entire run, including the test job that executes untrusted dependency code. Any code that runs before the real publish step can read that token out of runner memory and publish a malicious package. This was the third leg of the TanStack 2026 supply-chain compromise: a poisoned cache dumped runner memory and used the workflow-level OIDC token to publish 84 malicious versions. Per-job scoping shrinks the window during which the token exists.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Inspect this repo's .github/workflows for `id-token: write` declared in a top-level `permissions:` block, which mints an OIDC publish token for every job including ones that run untrusted test or dependency code. Move `id-token: write` out of the workflow level and into only the specific publishing job's `permissions:` block, and leave the other jobs with no `id-token` (or an explicit `contents: read`). Do not touch hardened spellings like `id-token: none` or `id-token: read` elsewhere: only the workflow-level `write` is the finding. Show me the diff and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/actions/reference/security/oidc. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement. To find exploitable workflow paths before attackers do, ci-secure checks the ten critical GitHub Actions attack vectors and lets you choose which fixes to apply.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup
• Install the /ci-secure skill to close critical attack vectors in GitHub Actions
• Browse GitHub Actions agent skills