Flowcheck MCP server

flowcheck

The default GitHub token can write to your repo. Most workflows never check.

Every GitHub Actions workflow runs with a GITHUBTOKEN. Repos created with legacy settings give that token write access to nearly everything, and a workflow with no permissions: block inherits whatever the repo default is. Add the trigger shapes that check out pull request code inside a privileged context, secrets passed wholesale to reusable workflows, and caches written by PR runs and read back by release runs, and the workflow file itself becomes the attack surface. The 2025 tj-actions compromise showed how fast a trusted action can turn; "pwn request" write-ups have shown the same for pullrequest_target checkouts of PR heads for years.

flowcheck audits every workflow in a repo for least-privilege problems, shows the evidence per file, job, and line, and emits a hardened permissions block per job, inferred from what the job's steps actually do, that you can paste in.

Why this exists

GitHub Actions are the second largest confirmed open source supply-chain attack surface of the last year, behind only npm. The failures are rarely exotic: a missing permissions block, one write-all, a checkout of ${{ github.event.pullrequest.head.sha }} under pullrequest_target, a self-hosted runner answering PR triggers. All of them are visible in the YAML, statically, before anything runs. flowcheck reads the YAML with a real parser (anchors, merge keys, and block scalars included), never executes anything in the scanned repo, and is callable by agents through MCP so the audit can run inside contribution and release workflows, not just by hand.

Sibling tools ask different questions: actionpin asks whether action refs are pinned to SHAs. flowcheck asks whether permissions and triggers are least-privilege. They share no code.

What it checks

Verdict rules:

Shortened. The full README is on GitHub.