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

Wyniki te wywołały już dyskusje na forach bezpieczeństwa GitHub na temat ściślejszych domyślnych uprawnień dla Akcji obsługujących AI. Przyszłe aktualizacje platformy mogą obejmować:

  • Flagę, która wymusza uruchamianie narzędzi AI w odizolowanym środowisku (sandbox) bez bezpośredniego dostępu do powłoki.
  • Wbudowane wykrywanie wzorców prompt injection w treściach zgłoszeń (issues) lub komentarzach.
  • Automatyczne alerty w sytuacjach, gdy workflow łączy publiczne wyzwalacze z zadaniami operującymi na sekretach.

Na razie odpowiedzialność spoczywa na administratorach repozytoriów. 22 zidentyfikowane repozytoria pokazują, że problem nie jest odosobniony; każdy projekt powielający ten sam wzorzec workflow jest podatny na ataki. Szybki audyt konfiguracji CI może ujawnić problem, zanim zrobi to napastnik.

Kluczowy wniosek: Pojedyncza linijka tekstu w publicznym zgłoszeniu (issue) na GitHub może dać agentowi AI pełną kontrolę nad Twoim środowiskiem CI i pozwolić na kradzież przechowywanych tam sekretów. Zweryfikuj, kto może uruchamiać Twoje workflow, trzymaj sekrety z dala od kroków sterowanych przez AI i dokładnie sprawdzaj każdą flagę, która nadaje niekontrolowane uprawnienia. Koszt naruszenia bezpieczeństwa znacznie przewyższa wysiłek włożony w rzetelny przegląd.