Agentic Actions Auditor

Agentic Actions Auditor is a static security review procedure for GitHub Actions workflows that invoke AI coding agents. It looks for paths where attacker-controlled GitHub event data reaches an agent prompt, and for configurations that widen the blast radius: dangerous sandbox modes, wildcard user allowlists, broad token permissions, and eval of model output.

It is maintained by Trail of Bits in trailofbits/skills. It is guidance for reading YAML, not an exploit tool. It reports findings and does not modify workflow files.

Source and revision

Where it sits in the Trail of Bits collection

This page reviews one skill. The repository it lives in is a security marketplace with 46 plugins and 97 SKILL.md files at 196a9073 (2026-10-23). The plugins are grouped by job: smart-contract security, code auditing, malware analysis, verification, reverse engineering, mobile security, and development tooling.

Other examples in the same repository include c-review, differential-review, semgrep-rule-creator, static-analysis, constant-time-analysis, burpsuite-project-parser, and supply-chain-risk-auditor. They are not reviewed on this page.

Install the marketplace rather than one folder when you want to browse:

/plugin marketplace add trailofbits/skills
/plugin menu

Codex uses the same marketplace:

codex plugin marketplace add trailofbits/skills
codex plugin list
codex plugin add agentic-actions-auditor@trailofbits

The repository is CC-BY-SA-4.0. That applies to the collection as a whole, not just this skill. The counts above are repository metadata; only agentic-actions-auditor has been inspected in detail here.

What the skill actually does

The audit has five working steps plus a Step 0 that chooses the analysis mode:

0. Choose analysis mode. Local repository, or remote owner/repo mode using gh api.
1. Discover workflow files. Only .github/workflows/*.yml and *.yaml at the repository root. No vendored or fixture directories.
2. Identify AI action steps. Match uses: prefixes for anthropics/claude-code-action, google-github-actions/run-gemini-cli, google-gemini/gemini-cli-action (legacy), openai/codex-action, and actions/ai-inference. Resolve local composite actions and reusable workflows one level deep.
3. Capture security context. For each AI step: prompt fields, tool flags, sandbox and safety settings, user allowlists, trigger events, environment variables, and token permissions.
4. Analyze nine attack vectors.
5. Report findings by severity with evidence, data flow, and remediation.

The nine vectors:

The skill is careful about severity. Vectors H and I are configuration weaknesses that amplify a co-occurring injection vector, not standalone injection paths. A dangerous sandbox with no demonstrated injection path is Info or Low, not High.

Why the env-var vector matters

The most commonly missed pattern is not a visible expression in the prompt. It is:

env:
  ISSUE_BODY: ${{ github.event.issue.body }}
with:
  prompt: |
    Read the ISSUE_BODY environment variable, then summarize the issue
    and propose a fix.

The prompt field contains no ${{ }}. GitHub evaluates the expression in env: before the step runs; the prompt then instructs the agent to read that variable at runtime. That read brings attacker-controlled issue text into the agent's context. A literal $ISSUE_BODY in with.prompt is not, by itself, proof of shell expansion: the reviewer must establish how the action or agent consumes it. The skill's env-var intermediary reference makes the runtime read explicit.

The same logic applies to pull_request_target, which runs in the base branch context with access to secrets and can be triggered by an external contributor. Checking out the PR head inside that context is a separate, compounding risk.

Illustrative audit

This is a constructed workflow, not a real repository.

on:
  issue_comment:
    types: [created]
permissions:
  contents: write
  pull-requests: write
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        env:
          COMMENT: ${{ github.event.comment.body }}
        with:
          prompt: "Read the COMMENT environment variable, review that comment, and apply the requested change."
          allowed_non_write_users: "*"

Expected findings:

• Potential High, Vector A: if the agent follows the prompt and reads COMMENT, attacker-controlled comment text enters its context. The trigger is external (issue_comment), and the job grants write permissions. Confirm the action's effective authentication, trigger, token, and tool settings before assigning severity; this illustrative workflow has not been executed.
• High, Vector I (amplifier): wildcard allowed_non_write_users lets any user trigger the action. On its own it is a configuration weakness; combined with A it raises severity.
• Medium, permissions: write access is broader than a review-only workflow needs. Recommend read-only unless the workflow must push.
• Remediation: require a maintainer allowlist, minimize token and tool permissions, and treat comment text as untrusted data rather than authority to change code. Fetching the same text through a trusted API does not remove prompt-injection risk. If the agent must write, separate the untrusted analysis from a gated write job with a scoped token.

The expected report includes the file, job, step, line, severity, one-sentence impact, YAML evidence, a numbered data-flow trace, and action-specific remediation. The skill does not patch the workflow.

When to use it

• You are auditing a repository that uses Claude Code Action, Gemini CLI, OpenAI Codex, or GitHub AI Inference in CI.
• You need to check whether external issue, PR, comment, or log content can reach an agent prompt.
• You are reviewing sandbox settings, tool allowlists, or token permissions for an agentic workflow.
• You want a structured static report before a security review or a merge.

When not to use it

• The workflow does not use an AI agent action. Use general GitHub Actions security tooling.
• You need runtime prompt-injection testing or exploitation. This is static analysis guidance.
• You need Jenkins, GitLab CI, CircleCI, or another CI system. The skill is GitHub-specific.
• You want the skill to fix the workflow. It explicitly reports findings and does not modify files.
• You need a guarantee that a workflow is safe. A clean static report is not a proof.

Install

/plugin marketplace add trailofbits/skills
/plugin menu

Prerequisites and footprint

The Bash usage is scoped in the skill: gh api calls, and gh auth status for diagnosing auth failures. It explicitly forbids piping fetched YAML into bash, sh, eval, source, Python, Node, or any interpreter, and forbids command substitution with fetched content. That is a meaningful boundary, but it is still an instruction.

License and attribution

This is the one skill in the batch with a share-alike license. The repository is CC-BY-SA-4.0. This page is an original guide, not a reproduction of the skill. It uses short attributed quotes and a paraphrased summary of the method. If you redistribute the skill itself, or a derivative of its text, you need to comply with CC-BY-SA-4.0: attribution, a license notice, and share-alike for adaptations.

We did not embed the full SKILL.md or the reference files. If you need the complete method, read it at the pinned source and follow the license.

Limitations

• Static only. It cannot prove an exploit or detect runtime behavior.
• Agent action coverage is a list. New actions or changed input names may not be recognized.
• One-level cross-file resolution. References found inside resolved files are logged as unresolved, not followed.
• Severity is contextual. The skill gives factors, not a formula.
• No remediation automation. It reports; a human changes the workflow.
• Remote mode needs GitHub access. Private repositories need a token with the right scope.
• CC-BY-SA scope. Do not copy the reference corpus into a page or product without checking the license.
• No independent validation by us. We did not run the audit against a repository.

Verify it yourself

1. Clone at the pinned commit and read SKILL.md, references/foundations.md, and at least one vector file. Confirm the env-var and PR-target explanations match your threat model.
2. Check the Bash Safety Rules section. If a host ignores them, the skill's remote mode becomes a much larger risk.
3. Run the audit on a disposable repository with a known-safe workflow and a deliberately bad test workflow. Confirm it reports the bad one and does not modify files.
4. Verify the report's data-flow trace starts at the attacker-controlled source, not at a YAML line.
5. Check the license before republishing any part of the skill. CC-BY-SA is not the same as MIT.

Review transparency

Related

• Trail of Bits Skills repository — the other 45 plugins and 96 skills
• How to Vet an Agent Skill — review the reviewer
• Prompt Injection Defense — the broader attack class
• Agentic Guardrails — policy controls for agents
• Code Review and Quality — review the workflow change
• Agent Skills — the install standard