GitHub Actions secrets: prevent leaks and overexposure

Production credentials live in an environment whose protection rules are configured in repository settings, or are minted just in time with OIDC. A secret is mapped through env only on the step that needs it, never serialized from the whole secrets context, passed on a command line, cached, or included in a broad artifact upload. Reusable workflows receive an explicit secret allowlist instead of secrets: inherit.123

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    # Configure required reviewers or another deployment protection rule under
    # Settings > Environments > production. This key alone does not create a gate.
    environment: production
    steps:
      - uses: actions/checkout@v7
      - name: Deploy
        run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Dependency scripts and unrelated steps can read the credential, while logs, process arguments, or a whole-workspace artifact can expose it beyond the intended deploy command.

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
      ALL_SECRETS: ${{ toJSON(secrets) }}
    steps:
      - uses: actions/checkout@v7
      - run: npm install
      - run: ./scripts/deploy.sh --token "$DEPLOY_TOKEN"
      - uses: actions/upload-artifact@v4
        with:
          name: workspace
          path: .

GitHub redacts registered secret values in many logs, but transformed values and sensitive data that was never registered may not be masked. Prevent exposure at the source: never dump toJSON(secrets), keep secret-bearing files outside cached or uploaded paths, and use ::add-mask:: only as an additional log safeguard. The ci-secure skill checks the concrete leak paths it can prove.

When the provider supports it, exchange GitHub's OIDC token for a short-lived credential instead of storing a long-lived cloud key. Restrict the provider trust policy by repository, branch, and protected environment, and scope id-token: write to the deploy job only.

A secret is protected only until code in the job can read it. Third-party actions, dependency install scripts, shell tracing, broad artifacts, and shared caches all expand that reader set. Scoping and environment gates reduce who can trigger access; OIDC shortens how long a stolen credential remains useful.

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

Audit .github/workflows for GitHub Actions secret exposure. Flag whole-context dumps, workflow- or job-wide secret environment variables, secrets passed in command arguments, `secrets: inherit`, credential files inside cache or artifact paths, and whole-workspace uploads. Move each secret to the consuming step's env, enumerate reusable-workflow secrets, narrow artifact and cache paths, protect production credentials with an environment, and prefer a short-lived OIDC credential when the provider supports it. Do not assume log masking prevents exposure. Preserve deploy behavior, show 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/how-tos/write-workflows/choose-what-workflows-do/use-secrets, https://docs.github.com/en/actions/reference/security/secure-use, 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.

• 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