AI-enabled GitHub Actions can be hijacked with a single comment, leaking API keys, cloud tokens and other secrets. A security researcher uncovered 22 open-source repositories where a public trigger, an AI tool run with a “skip prompts” flag, and exposed secrets create a straight-forward exfiltration path.

How the flaw works

Projects now embed AI agents—Claude Code, the GitHub Copilot CLI, and similar tools—directly in CI pipelines. A workflow step runs a shell command and often adds a flag that tells the tool to ignore interactive permission requests. When the workflow starts on any public input—an issue, a comment, or a pull-request title—the attacker only needs to post a line of text that the AI will treat as a command.

The AI, already given unrestricted shell access by the “skip prompts” flag, reads any environment variable or file the workflow exposes. If the job also loads secrets—API keys, cloud service tokens, or full service-account credentials—the AI pipes those values to an attacker-controlled server. No code change, no new dependency, just a harmless-looking comment.

Real-world examples

The researcher confirmed three vulnerable repositories that have already been patched:

  • pymc-labs/pymc-marketing – a public issue could be used to reach an Anthropic API key through prompt injection.
  • MadAppGang/dingo – the workflow gave Claude Code full Bash access and exposed two secrets in the same job.
  • MadAppGang/claudish – reused the same vulnerable template as the dingo project.

One finding involved a live cloud-service account key, which the researcher reported directly to the security team of a major AI provider. Twelve additional reports are pending with maintainers; their names are being withheld until fixes go live.

What’s at stake

When an attacker extracts a secret, the damage can be immediate and costly. A cloud-service account key grants unrestricted access to compute resources, storage buckets and other paid services. An API key for a large-language-model provider can run unlimited queries, potentially racking up thousands of dollars in charges. Because the exploit runs inside the CI environment, the breach can spread downstream: any artifact built on the compromised runner may carry malicious code, turning a single repository into a supply-chain vector.

For teams that rely on AI-assisted CI, the trade-off is stark. The convenience of auto-generated code, linting or documentation must be weighed against the risk that a public comment becomes a covert backdoor.

Why the vulnerability is easy to miss

The researcher initially filed six reports that were later retracted. The retractions stemmed from assumptions about GitHub Actions’ permission checks, not from a line-by-line review of the Action’s source code. Documentation and intuition can be misleading; the only reliable way to confirm the security posture of an AI-enabled step is to inspect the code that runs the tool and the workflow YAML that wires it together.

Mitigation checklist

If you run an AI CLI or similar tool inside a GitHub Actions workflow, answer these two questions before merging:

  1. Who can trigger the workflow? Limit triggers to trusted events (e.g., pushes to protected branches) or require explicit approval for runs started by external contributors. Avoid on: issue_comment or on: issues without additional gating.

  2. What secrets are loaded in the same job? Never expose API keys, cloud tokens, or service-account credentials in a job that also runs an AI agent with unrestricted shell access. Separate secret-heavy steps into isolated jobs or runners that do not invoke AI tools.

Additional hardening steps:

  • Remove the flag that skips permission prompts, forcing the AI tool to request explicit confirmation before executing shell commands.
  • Add a step that sanitizes or redacts any environment variable the AI tool could read.
  • Use self-hosted runners with network egress controls to block exfiltration to arbitrary endpoints.

Counter-point: the utility of AI in CI

Proponents argue that productivity gains outweigh the risk. Automated code suggestions cut review time, and AI-driven testing surfaces bugs earlier. Yet the same convenience expands the attack surface. The key is not to abandon AI but to treat any tool with shell-level privileges as a potential vector.

What to watch next

Penemuan ini telah pun mencetuskan perbincangan di forum keselamatan GitHub mengenai keizinan lalai yang lebih ketat untuk Actions yang dikuasakan AI. Kemas kini platform pada masa hadapan mungkin merangkumi:

  • Penanda yang memaksa alatan AI untuk berjalan dalam persekitaran sandbox tanpa akses shell secara langsung.
  • Pengesanan terbina dalam bagi corak suntikan-prompt dalam badan isu atau komen.
  • Amaran automatik apabila sesuatu aliran kerja mencampurkan pencetus awam dengan tugasan yang mengandungi rahsia.

Buat masa ini, tanggungjawab tersebut terletak pada penyelenggara repositori. 22 repositori yang dikenal pasti menunjukkan bahawa isu ini bukan terpencil; mana-mana projek yang mencerminkan corak aliran kerja yang sama adalah terdedah kepada risiko. Audit pantas terhadap konfigurasi CI boleh mendedahkan masalah tersebut sebelum penyerang melakukannya.

Intipatinya: Satu baris teks dalam isu GitHub awam boleh memberikan ejen AI kawalan penuh ke atas persekitaran CI anda dan mencuri rahsia yang anda simpan di sana. Sahkan siapa yang boleh melancarkan aliran kerja anda, jauhkan rahsia daripada langkah-langkah yang dipacu AI, dan teliti setiap penanda yang memberikan keizinan tanpa semakan. Kos pencerobohan jauh melebihi usaha untuk melakukan semakan yang berdisiplin.