Agentic Actions AuditorBLOCK
Trail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows
Overview
Trail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows
f2255be13794OBSERVED · 2026-10-22Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned | |
| gemini-cli | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: agentic-actions-auditor
description: "Audits GitHub Actions workflows for security vulnerabilities in AI agent integrations including Claude Code Action, Gemini CLI, OpenAI Codex, and GitHub AI Inference. Detects attack vectors where attacker-controlled input reaches AI agents running in CI/CD pipelines, including env var intermediary patterns, direct expression injection, dangerous sandbox configurations, and wildcard user allowlists. Use when reviewing workflow files that invoke AI coding agents, auditing CI/CD pipeline security for prompt injection risks, or evaluating agentic action configurations."
allowed-tools: Read Grep Glob Bash
---
# Agentic Actions Auditor
Static security analysis guidance for GitHub Actions workflows that invoke AI coding agents. This skill teaches you how to discover workflow files locally or from remote GitHub repositories, identify AI action steps, follow cross-file references to composite actions and reusable workflows that may contain hidden AI agents, capture security-relevant configuration, and detect attack vectors where attacker-controlled input reaches an AI agent running in a CI/CD pipeline.
## When to Use
- Auditing a repository's GitHub Actions workflows for AI agent security
- Reviewing CI/CD configurations that invoke Claude Code Action, Gemini CLI, or OpenAI Codex
- Checking whether attacker-controlled input can reach AI agent prompts
- Evaluating agentic action configurations (sandbox settings, tool permissions, user allowlists)
- Assessing trigger events that expose workflows to external input (`pull_request_target`, `issue_comment`, etc.)
- Investigating data flow from GitHub event context through `env:` blocks to AI prompt fields
## When NOT to Use
- Analyzing workflows that do NOT use any AI agent actions (use general Actions security tools instead)
- Reviewing standalone composite actions or reusable workflows outside of a caller workflow context (use this skill when analyzing a workflow that references them via `uses:`)
- Performing runtime prompt injection testing (this is static analysis guidance, not exploitation)
- Auditing non-GitHub CI/CD systems (Jenkins, GitLab CI, CircleCI)
- Auto-fixing or modifying workflow files (this skill reports findings, does not modify files)
## Rationalizations to Reject
When auditing agentic actions, reject these common rationalizations. Each represents a reasoning shortcut that leads to missed findings.
**1. "It only runs on PRs from maintainers"**
Wrong because it ignores `pull_request_target`, `issue_comment`, and other trigger events that expose actions to external input. Attackers do not need write access to trigger these workflows. A `pull_request_target` event runs in the context of the base branch, not the PR branch, meaning any external contributor can trigger it by opening a PR.
**2. "We use allowed_tools to restrict what it can do"**
Wrong because tool restrictions can still be weaponized. Even restricted tools like `echo` can be abused for data exfiltration via subshell expansion (`echo $(env)`). A tool allowlist reduces attack surface but does not eliminate it. Limited tools != safe tools.
**3. "There's no ${{ }} in the prompt, so it's safe"**
Wrong because this is the classic env var intermediary miss. Data flows through `env:` blocks to the prompt field with zero visible expressions in the prompt itself. The YAML looks clean but the AI agent still receives attacker-controlled input. This is the most commonly missed vector because reviewers only look for direct expression injection.
**4. "The sandbox prevents any real damage"**
Wrong because sandbox misconfigurations (`danger-full-access`, `Bash(*)`, `--yolo`) disable protections entirely. Even properly configured sandboxes leak secrets if the AI agent can read environment variables or mounted files. The sandbox boundary is only as strong as its configuration.
## Audit Methodology
Follow these steps in order. Each step builds on the previous one.
### Step 0: Determine Analysis Mode
If the user provides a GitHub repository URL or `owner/repo` identifier, use remote analysis mode. Otherwise, use local analysis mode (proceed to Step 1).
#### URL Parsing
Extract `owner/repo` and optional `ref` from the user's input:
| Input Format | Extract |
|-------------|---------|
| `owner/repo` | owner, repo; ref = default branch |
| `owner/repo@ref` | owner, repo, ref (branch, tag, or SHA) |
| `https://github.com/owner/repo` | owner, repo; ref = default branch |
| `https://github.com/owner/repo/tree/main/...` | owner, repo; strip extra path segments |
| `github.com/owner/repo/pull/123` | Suggest: "Did you mean to analyze owner/repo?" |
Strip trailing slashes, `.git` suffix, and `www.` prefix. Handle both `http://` and `https://`.
#### Fetch Workflow Files
Use a two-step approach with `gh api`:
1. **List workflow directory:**
```
gh api repos/{owner}/{repo}/contents/.github/workflows --paginate --jq '.[].name'
```
If a ref is specified, append `?ref={ref}` to the URL.
2. **Filter for YAML files:** Keep only filenames ending in `.yml` or `.yaml`.
3. **Fetch each file's content:**
```
gh api repos/{owner}/{repo}/contents/.github/workflows/{filename} --jq '.content | @base64d'
```
If a ref is specified, append `?ref={ref}` to this URL too. The ref must be included on EVERY API call, not just the directory listing.
4. Report: "Found N workflow files in owner/repo: file1.yml, file2.yml, ..."
5. Proceed to Step 2 with the fetched YAML content.
#### Error Handling
Do NOT pre-check `gh auth status` before API calls. Attempt the API call and handle failures:
- **401/auth error:** Report: "GitHub authentication required. Run `gh auth login` to authenticate."
- **404 error:** Report: "Repository not found or private. Check the name and your token permissions."
- **No `.github/workflows/` directory or no YAML files:** Use the same clean report format as local analysis: "Analyzed 0 workflows, 0 AI actionTrust audit
BLOCKgrade D · trust 69/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | WARN |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | FAIL |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (9)
Wrong because sandbox misconfigurations (`danger-full-access`, `Bash(*)`, `--yolo`) disable protections entirely. Even properly configured sandboxes leak secrets if the AI agent can read environment v
plugins/modern-python/hooks/shims/pip3
plugins/modern-python/hooks/shims/python3
Even if the AI action itself is sandboxed and restricted, the CONSUMING step may run with full permissions. The `eval` command executes arbitrary shell code within the output string. An attacker who a
Without dangerous configs, a successful prompt injection may still be contained by tool restrictions and sandbox boundaries. With dangerous configs, the AI agent has full access to shell, filesystem,
**General pattern:** Any `with:` field containing a user or bot allowlist with value `"*"` or that resolves to unrestricted access.
Without dangerous configs, a successful prompt injection may still be contained by tool restrictions and sandbox boundaries. With dangerous configs, the AI agent has full access to shell, filesystem,
- Access environment variables including `GITHUB_TOKEN` and repository secrets
Tool restrictions give a false sense of security. "Only allow echo" sounds safe -- echo just prints text. But `echo $(env)` dumps all environment variables including `GITHUB_TOKEN`, API keys, and depl
Gates applied: no_behavioural_pass.
f2255be13794full audit observations/trust-audit/skill/trailofbits__agentic-actions-auditor.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-22 | f2255be13794 | BLOCK | D | 69 | first audit |
Questions
What does the agentic-actions-auditor — trailofbits/skills skill do?
Trail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows
Is agentic-actions-auditor — trailofbits/skills safe to install?
No — not without reading the findings first. The audit graded it D (69/100) and found 1 critical or high issue in the source. Each one is listed on this page with the file and line it is on.
What can agentic-actions-auditor — trailofbits/skills access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does agentic-actions-auditor — trailofbits/skills work with?
Its documentation mentions claude-code, codex and gemini-cli. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (f2255be13794), read on 2026-10-22. The repository is watched, and a new audit runs when it changes — this is the first audit.
Add this badge to your README
Shows this page's audit result and links back to it. It updates when the audit does.
[](https://modelsatlas.com/skills/trailofbits/agentic-actions-auditor/)
Not your listing, or something out of date? Claim or update your listing.