Hardening AI Coding Agents in GitHub Actions: A Checklist

A checklist for Claude Code and other AI agents in your CI, with the settings to look for and what each result means.

Founder, Newly

October 24, 2026|8 min read

Published October 24, 2026Last updated October 24, 2026

Run an AI coding agent in GitHub Actions only on triggers that need a repository writer, give its GITHUB_TOKEN read access unless one step needs more, restrict outbound network traffic, and keep every secret except the model key out of the job. Pin the action to a commit and have a person review whatever the agent proposes. Checked on October 24, 2026.

What goes wrong when an AI agent runs in your CI?

An agent in a workflow reads text that strangers can write, such as issues, pull request descriptions and comments, and it holds tools and secrets in the same job. Researchers summed it up in April 2026: the agents are given powerful tools and secrets in the same runtime that processes untrusted input. We covered that research in Comment and Control. The table lists the dated cases this page draws on.

Case	Condition	Fix or lesson
GHSL-2025-093	An issue-triage workflow put issue titles and bodies straight into a shell step while holding an Anthropic API key. Reported August 11, 2025.	Fixed December 16, 2025. Never place issue text inside a script; pass it as data.
Microsoft report	Prompt injection could make the agent's file-read tool expose process environment, where the API key sat.	Microsoft reports a fix in Claude Code 2.1.128 on May 5, 2026. Fewer secrets in the job means less to read.
GHSA-8q5r-mmjf-575q	A pull request carrying its own MCP server configuration, picked up when the action checked out the PR branch. Moderate, CVSS 5.3.	Fixed in claude-code-action 1.0.74 (May 20, 2026). Update, and do not run the agent on unreviewed PR branches.

The Cloud Security Alliance note of May 3, 2026 reaches the same recommendations this page follows: pin third-party actions to commits, avoid pull_request_target, declare minimum permissions and treat repository content as untrusted.

Which triggers should an AI agent workflow allow?

Start with who can wake the agent. Anthropic's security notes for claude-code-action say the action runs only for users with write access on issue, pull request and comment events, and blocks bots by default. Two settings loosen that:

allowed_non_write_users lets anyone trigger it. The notes call this a significant security risk, for workflows with extremely limited permissions only.
allowed_bots names bots that skip the permission check. Allow specific bots, never all of them.

Then look at the event itself. GitHub's event reference warns that running untrusted code on pull_request_target may lead to vulnerabilities, and that a workflow_run workflow can reach secrets and write tokens even when the workflow that triggered it could not.

Trigger	What to know	For an agent
pull_request	From a fork, secrets are withheld apart from a read-only GITHUB_TOKEN.	Default choice for reviewing PRs.
pull_request_target	Runs in the base repository's context.GitHub Security Lab ties the danger to checking out and running the PR's code there.	Avoid. If unavoidable, never check out the fork.
issues, issue_comment	Text is written by whoever can open an issue or comment.	Gate on write access; no write scopes in the job.
workflow_run	Can reach secrets and write tokens.	Use for the reviewed step, never to feed untrusted files to an agent.

Checkout change, June 18, 2026

The actions/checkout v7.0.0 release notes list "block checking out fork pr for pull_request_target and workflow_run". That helps if you upgrade. It does not cover other ways of pulling in untrusted files, so keep the rule above.

How small should GITHUB_TOKEN be?

Set a permissions: block in every agent workflow, so the job gets exactly what is listed. GitHub's token documentation tells you to configure the minimum required at workflow or job level, and the hardening guide recommends read-only repository contents by default, raised per job.

For a review-only agent, contents: read plus comment access on pull requests or issues is often enough. Add contents: write only to the job that pushes, and keep that job separate from the one that reads untrusted text. The claude-code-action notes also say to use the job-scoped token and never a personal access token when outside users can trigger it, because a static token could be recovered through prompt injection.

How do you keep secrets away from the agent?

Assume anything the job can read, the agent can be talked into printing. The cases above all ended with a key in a log or a response. So reduce what is there to read:

The job that handles untrusted text gets the model key and nothing else. No deploy key, no cloud key, no package-publish token.
Use OpenID Connect for cloud access, so jobs receive short-lived tokens and no stored cloud secret exists to leak.
Put the model key in an environment with required reviewers, so a job cannot read it before someone approves.
Leave full-output logging off. The action's notes warn it can expose tokens and file contents, and public repositories show those logs to everyone. Debug mode turns it on.
Use a separate model key per repository, with a spending limit at your AI provider, so a leak has a ceiling.

Our page on secrets in LLM logs covers how tokens end up in request bodies, and rotating secrets covers what to do once one has.

The layout to aim for: the job that reads untrusted text cannot write, cannot reach other secrets and cannot send data anywhere unplanned.

How do you limit what the job can send out?

Stolen credentials need a route out. StepSecurity's Harden-Runner monitors outbound calls from a runner and has an audit mode, which logs, and a block mode, which allows only endpoints you list. Run audit first to see what the agent job contacts, then block with that list.

An allowlist has limits. The model provider and GitHub itself must stay reachable, and data can travel through an allowed endpoint, for example in a comment the agent posts. Egress control narrows the routes and does not replace the token and secret limits above.

What should you pin and review?

GitHub's hardening guide says to pin actions to a full commit SHA, because forging a matching one is computationally infeasible. A tag can be moved, as the Trivy case showed in when the scanner is the attack. Pin the agent action too, and re-read its release notes when you update, since fixes such as 1.0.74 arrive that way. The pinning checklist and red.run.cloud's pin GitHub Actions to SHAs guide go further.

Restrict the agent's tools with the action's allowed-tools setting, and review its output like a contributor's. The OWASP CI/CD list names poisoned pipeline execution, insufficient pipeline access controls and weak credential hygiene as the risks this page addresses.

If your app lives in a repository

Newly builds a real React Native and Expo app, and you can download the code or connect your own repository. If you add an AI agent to that repository's workflows, the choices above are yours, and the 15-minute app check covers the app itself.

Where do you stand?

Everything starts as unknown. Move an item to confirmed only when you hold the evidence listed under it. Reading a workflow file shows intent; a run log shows what happened.

Your agent workflow review

Detected: You found the problem.
Unknown: Not checked yet, or the check could not tell.
Confirmed by owner evidence: You checked and kept the proof.

1. No agent workflow runs on pull_request_target, issue_comment or issues without a write-access check, and none checks out a fork's code.
Evidence: the on: block of each workflow that calls the agent, plus the checkout step's ref.
2. Every agent workflow sets an explicit permissions: block, read-only by default, with write scopes only on the job that needs them.
Evidence: the permissions: lines in each workflow file and the repository's default workflow permission setting.
3. The job that reads untrusted text holds only the model key, kept in an environment or a scoped secret, and no deploy keys, cloud keys or personal tokens.
Evidence: the list of secrets and environment variables each agent job can read.
4. Outbound traffic from the agent job is logged, and blocked except for the endpoints it needs.
Evidence: the egress policy in the workflow and a run log showing the allowed endpoints.
5. The agent action and every other third-party action is pinned to a full commit SHA, and the action version is past the May 2026 fix.
Evidence: the uses: lines and the version the SHA corresponds to.
6. If an agent workflow ever ran against untrusted input with secrets, those secrets were rotated and the run logs were checked.
Evidence: the rotation date for each secret and a note on the logs reviewed.

0 detected6 unknown0 confirmed by owner evidence

Your answers stay in this browser tab. Nothing is saved or sent.

More hub pages are at newly.app/security.

Frequently asked questions

Is it a bad idea to run Claude Code in GitHub Actions at all?

No. The risk comes from the combination: untrusted text, a powerful token and secrets in one job. Anthropic's own security notes for the action describe write-access gating, a short-lived token and tool restrictions. Use them, and add the limits on this page.

Does a private repository remove the risk?

It narrows who can open an issue or pull request, which helps. Anyone with write access, any bot you allow and any dependency that ends up in the job still count as input. Apply the same token, secret and egress limits to private repositories.

Why not just tell the agent in its prompt to ignore bad instructions?

Prompt wording lowers the odds and removes none of the risk. The 2026 research on agents in CI found that guardrail prompts did not close the problem. Limits the agent cannot talk its way past, such as a read-only token and no secrets in the job, are the dependable part.

What if the agent needs to push code?

Split the work. Let the agent job produce a patch or a draft pull request with a narrow token, then let a separate step or a human with write access apply it. An environment with required reviewers can gate the step that holds the write token.

I use Newly. Does any of this apply to my app?

Only if your project lives in a GitHub repository with workflows. Newly builds a real React Native and Expo app and lets you download the code or connect your own repository. Once the code is in a repository you control, the workflows there are yours to check.

Can a scan tell me if my workflows are hardened?

No. The red.run.cloud scans work from outside against a live site, and workflow files are not visible there. This page is a review you do on the repository itself. A scan can still show what your deployed site exposes if a secret did leak.

Sources

All sources were checked on October 24, 2026.

GHSL-2025-093: code injection in an AI issue-triage workflow, GitHub Security Lab
Malicious MCP server configuration in PRs (GHSA-8q5r-mmjf-575q), anthropics/claude-code-action advisories
Security guidance for claude-code-action, Anthropic, GitHub
Securing CI/CD in an agentic world: the Claude Code GitHub Action case, Microsoft Security Blog, June 5, 2026
Research note: AI agents in GitHub Actions, May 3, 2026, Cloud Security Alliance Labs
Comment and Control: prompt injection and credential theft, Aonan Guan
Claude Code, Gemini CLI, GitHub Copilot agents vulnerable to prompt injection via comments, SecurityWeek
Security hardening for GitHub Actions, GitHub Docs
Events that trigger workflows, GitHub Docs
Automatic token authentication (GITHUB_TOKEN), GitHub Docs
Preventing pwn requests, GitHub Security Lab
actions/checkout v7.0.0 release notes, June 18, GitHub
Managing environments for deployment, GitHub Docs
OpenID Connect in GitHub Actions, GitHub Docs
Harden-Runner: egress audit and block modes, StepSecurity
OWASP Top 10 CI/CD Security Risks, OWASP Foundation