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

De bevindingen hebben al discussies ontketend op de beveiligingsfora van GitHub over strengere standaardpermissies voor AI-gestuurde Actions. Toekomstige platformupdates kunnen het volgende bevatten:

  • Een vlag die AI-tools dwingt om in een gesandboxed omgeving te draaien zonder directe shell-toegang.
  • Ingebouwde detectie van prompt-injection-patronen in de tekst van issues of reacties.
  • Geautomatiseerde waarschuwingen wanneer een workflow publieke triggers combineert met jobs die geheimen bevatten.

Vooralsnog ligt de verantwoordelijkheid bij de beheerders van de repositories. De 22 geïdentificeerde repositories laten zien dat het probleem niet geïsoleerd is; elk project dat hetzelfde workflow-patroon volgt, is kwetsbaar. Een snelle audit van CI-configuraties kan het probleem aan het licht brengen voordat een aanvaller dat doet.

De kern: Eén enkele regel tekst in een openbare GitHub issue kan een AI-agent volledige controle geven over je CI-omgeving en de geheimen die je daar opslaat, stelen. Controleer wie je workflows kan starten, houd geheimen weg bij AI-gestuurde stappen en onderzoek elke vlag die ongecontroleerde permissies verleent. De kosten van een datalek overstijgen de inspanning van een gedisciplineerde controle ruimschoots.