Article: Noma Labs showed that a single public GitHub issue can steal code from private repositories using an AI-driven automation. Their proof-of-concept lets an attacker turn an organization’s own workflow bots against it, leaking proprietary files without breaking GitHub’s authentication.

The attack in plain sight

The chain of events is simple enough to reproduce:

  • An attacker creates an issue in a public repository that anyone can view.
  • An AI agent, hooked into the continuous-integration pipeline, reads the issue’s title and body.
  • The same agent already has read permissions for other private repositories in the organization.
  • Hidden instructions in the public issue tell the agent which private files to fetch.
  • The agent posts the retrieved files back to the public issue as a comment, exposing them to the world.

Everything happens in a single run of the automation. No credential theft, no API-key leak, no GitHub vulnerability. The attacker simply exploits the trust the organization placed in its own bot.

Why this matters now

AI-powered agents now glue together modern development pipelines. They open pull-requests, run tests, deploy builds, and triage bugs—all triggered by lightweight signals such as issue comments. When those agents hold broad repository access, the line between trusted data and untrusted user input blurs.

If an agent can read private code and write publicly in the same execution, the organization’s access-control model collapses.

The real flaw: permissions, not the model

The demonstration does not implicate the underlying AI model. The model merely follows the instructions it receives. The vulnerability resides in the permission set granted to the automation:

  • Read access to private repositories across the organization.
  • Write access to public issue threads.
  • Trigger on public text that anyone can craft.

Fixes that cost nothing, but work

Applying the principle of least privilege slashes the attack path:

  • Scope the bot to the repository where it is needed. If it only needs to act on a specific repo, deny it any other read rights.
  • Separate read and write tokens. Use one credential for fetching code and another, tightly controlled credential for posting comments.
  • Human approval before any public posting. A lightweight review step—such as a required approval label—adds a checkpoint without halting the pipeline.
  • Blast-radius reduction. Design workflows so that a failure or misuse affects at most one repository, not the entire organization.

Counter-point: operational overhead

What to watch next

Takeaway: If an AI automation can both see private code and speak publicly, the system is mis-designed. Tighten permissions, insert human checks, and keep the blast radius small—otherwise a single public issue can become a data-leak vector.