GitHub Actions Permissions: Security Checklist for AI-Generated Workflows

AI coding agents are good at generating GitHub Actions workflows quickly, but they often choose broad permissions, unsafe triggers, and convenience-first shell commands. A workflow file is production infrastructure: it can publish packages, deploy servers, read secrets, and write to your repository. Review it like code with elevated privileges.

The fastest safe default

Start every workflow with the smallest permission set possible:

permissions:
  contents: read

Then add only the exact permission required by the job. A workflow that comments on pull requests may need `pull-requests: write`, but a test workflow usually does not.

Checklist for AI-generated workflow changes

1. Check triggers. Be careful with `pull_request_target`, broad `workflow_dispatch` inputs, and workflows that run on every branch.
2. Check permissions. Avoid `contents: write`, `actions: write`, `packages: write`, or `id-token: write` unless you can explain why they are required.
3. Check secret usage. Secrets should not be available to untrusted pull requests.
4. Pin third-party actions. Prefer commit SHAs for sensitive workflows, or at least trusted major versions.
5. Review shell injection risk. Never pass untrusted PR titles, branch names, issue text, or inputs directly into shell commands.
6. Separate test and deploy jobs. Test jobs should not have deploy credentials.

Common risky pattern: pull_request_target

`pull_request_target` runs in the context of the base repository, which can expose powerful tokens. It is useful for metadata automation, but dangerous if it checks out and executes untrusted pull request code.

Common risky pattern: broad token permissions

If an AI agent adds `permissions: write-all` to fix a permission error, stop and inspect the actual need. Replace it with a narrow permission block. If the job only reads source and runs tests, use `contents: read`.

OIDC and cloud deploys

`id-token: write` enables OpenID Connect federation to cloud providers. This is safer than long-lived cloud keys when configured correctly, but it is still powerful. Confirm the cloud role trust policy restricts repository, branch, environment, and workflow as tightly as possible.

Recommended small-team baseline

name: CI
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Related CodeRiskTools resources

• AI Code Security hub
• Free 5-point AI code review checklist
• CodeRiskTools product library — optional paid kits if you want templates and local checklists.
• Compare SAST tools
• Expert AI Code Security Audit — professional deep review for teams.

Note: This article is educational and designed for local/security-conscious workflows. Do not paste private source code or secrets into third-party tools.

GitHub Actions permission review before merge

Workflow files deserve a different review mindset than normal application code. A single YAML change can give automation the ability to write to the repository, publish packages, request cloud credentials, or read secrets. AI-generated workflow edits should therefore be reviewed as privileged infrastructure changes.

Check the workflow trigger first

The trigger controls who can cause the workflow to run. `pull_request` is usually safer for testing untrusted pull requests. `pull_request_target` can be useful for labels and comments, but it is risky when combined with checkout and execution of pull request code. `workflow_dispatch` is convenient, but typed inputs should be validated if they influence shell commands or deployment targets.

Check the token permissions second

Many workflow problems are solved incorrectly by adding broad write access. If an AI assistant suggests `write-all`, ask what exact API operation needs write access. A test job normally needs only `contents: read`. A release job may need `contents: write`, but that permission should be isolated from untrusted code paths.

Check whether secrets are reachable

Secrets should not be exposed to code that comes from forks, pull requests, generated scripts, or uncontrolled inputs. Review every step that prints environment variables, runs shell commands, installs dependencies, or uploads artifacts. Be especially careful with debug logging and failure dumps.

Safe patterns for AI-generated CI workflows

• Use `permissions: contents: read` as the default.
• Split test, release, and deploy workflows.
• Pin sensitive third-party actions or use trusted publishers.
• Use environments and approvals for production deploys.
• Avoid executing untrusted pull request text in shell.
• Keep cloud/OIDC roles tightly bound to repository, branch, and environment.

GitHub Actions security FAQ

Is `pull_request_target` always unsafe?

No, but it is easy to misuse. It becomes dangerous when it checks out and runs untrusted pull request code with privileged repository context.

Should every workflow define permissions?

Yes. Explicit permissions make review easier and reduce accidental broad token access. Start with read-only and add narrow writes only when required.

Can AI safely write GitHub Actions workflows?

AI can draft workflows, but humans should review triggers, permissions, secrets, third-party actions, and shell commands before merge.

Before approving an AI-generated workflow

Review the workflow as if it were a production deployment script. Ask what the workflow can read, what it can write, who can trigger it, and what code it executes. If the answer is unclear, narrow the workflow before merge rather than after an incident.

A safe review also checks whether the workflow changed the release boundary. For example, a test workflow that begins publishing packages, uploading artifacts with secrets, or requesting OIDC cloud credentials is no longer just a test workflow. Separate those responsibilities into smaller jobs or separate workflows.

Approval checklist

• Trigger is appropriate for trusted or untrusted code.
• Permissions are explicitly defined and narrow.
• Secrets are not exposed to pull request code.
• Third-party actions are trusted and pinned appropriately.
• Deployment steps require environment protection where needed.