How to use Claude to check Actions attack entry points
Claude reviewed Actions workflows and live repository settings, found the reported attack entry point absent, and made one CI token permission explicit.
note.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Audit my GitHub Actions workflows and actual repository settings through gh. Trace outsider issue, comment, and fork-PR entry points into credentialed agents; inspect token permissions and production gates. Distinguish absent attack paths from real findings. Propose only safe permission clarifications and leave cost-bearing approval changes for my decision.
Reach people exploring AI agents
See placements →What happened
The review found no entry point for the reported issue-triggered attack in this setup and made one CI token permission explicit.
Reported by ろー (@sylvacejp) — noteHow the agent did it
- The audit read every deployed workflow and checked actual repository settings with GitHub CLI.
- It traced whether outside issues, comments, or pull requests could start credentialed agent work.
- The author made one read-only permission declaration explicit and retained manual deployment control.
Where a person stepped in
The author chose the audit scope, applied the limited safe change, and left the paid approval-feature decision for later human consideration.
After reading about attacks on coding agents in GitHub Actions, ろー asked for an audit of the repositories and workflows used for production deployment. The review checked both workflow files and actual GitHub settings through the command-line interface.
The questions were specific: token permissions, production approval, automatic agent execution from outside pull requests, and untrusted issue or comment text entering commands. The result was largely reassuring for this particular setup. Production workflows lived in private repositories, and there were no issue or comment triggers providing the reported attack’s entry point.
The audit also clarified a human boundary already present in the workflow. Deployment required a person to start a manual action. Formal environment approval had been deferred because of the account plan, so this existing manual trigger was documented as an intentional control rather than an accidental benefit.
One small CI workflow omitted an explicit permission declaration. Its current default was read-only, but the author added an explicit line to avoid relying on a future repository default. The account describes attack-surface verification and one preventive configuration repair. It does not claim a discovered RCE, an incident response, or universal protection for agent workflows.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: note · ろー (@sylvacejp)
Frequently asked questions
Did the audit find an exploited RCE?
No. The reported trigger path was absent from these repositories.
Why inspect GitHub settings too?
Workflow intentions needed checking against actual token and environment configuration.
What was changed immediately?
An omitted read-only token permission was declared explicitly.
More details
About this account
The audit read every deployed workflow and checked actual repository settings with GitHub CLI. It traced whether outside issues, comments, or pull requests could start credentialed agent work.
Firsthand Japanese account; author says the audit was commissioned while using Claude Code. No reproduced exploit or production incident is claimed. Manual dispatch is a human control, not a claim of equivalence to every environment approval policy. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: ろー (@sylvacejp) — note
Source published 6 Sept 2026
Source checked 14 Oct 2026
Tools and topics
Claude Code · GitHub Actions · GitHub CLI
CI security · permissions · attack surface
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.