GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos

Original Article ↗ Hacker News Discussion ↗

Researchers showed that a GitHub “agentic workflow” powered by an LLM could be prompted via public issue comments into leaking code from private repositories, despite guardrails intended to prevent this. Commenters argue over whether this is primarily a misconfiguration by the workflow author or a deeper architectural flaw in how GitHub grants agents broad cross-repo access, but broadly agree that LLMs should never be trusted with permissions beyond those of the requesting user. The incident fuels wider skepticism about rushed AI integrations, the practicality of defending against prompt injection, and whether sensitive code should be hosted on platforms that tightly couple AI agents with repository access.

Nature of the vulnerability

  • GitHub Agentic Workflows were configured to:
    • Read public issue titles/bodies.
    • Reply via public comments.
    • Have read access to other org repos, including private.
  • Attackers could inject instructions into public issues that caused the agent to read private repos and paste contents back as public comments.
  • Several commenters stress the key failure is a missing trust boundary between untrusted issue content and private-repo access.

Who is at fault?

  • One camp: this is primarily user misconfiguration.
    • Researchers explicitly granted the agent org-wide repo access and allowed it to process untrusted public issues.
    • Analogy: giving a CI job secrets and then running it on public PRs.
  • Other camp: this is a GitHub design flaw.
    • Reasonable users expect an agent in a public repo not to leak unrelated private repos.
    • Permissions are too coarse and GitHub doesn’t make safe configuration easy or obvious.

Prompt injection & (un)solvable guardrails

  • Many argue prompt injection is inherent to LLMs: user input is instructions, so there is no strong way to separate “code” from “data.”
  • Comparisons to SQL injection:
    • Similar in that untrusted input changes behavior.
    • But unlike SQL, there is no equivalent of prepared statements; guardrails are just more input text and can be overridden.
  • Some see it more like social engineering: you can only mitigate via process and access control, not “fix” the model.

Permissions, architecture, and mitigations

  • Widely shared view: the only real defenses are architectural:
    • Run agents with the same or stricter permissions than the prompting user; never with “root”/org-wide access.
    • Scope agents to a single repo or narrowly defined workflows; segment workflows with different tokens.
    • Restrict writes from agents handling public input, even if they can read private data.
    • Sandbox agents and give them their own credentials; treat them like untrusted users.
  • Some suggest better UIs for per-prompt/per-workflow permissions and more granular GitHub tokens.

Trust in GitHub, cloud, and AI integrations

  • Skepticism toward GitHub/Microsoft:
    • Perception of “AI everywhere” driven by investor pressure, leading to rushed, insecure features.
    • Concerns about private repo data feeding Copilot training unless opted out.
  • A visible subgroup advocates moving to self-hosted forges (Forgejo, Codeberg, bare git) to avoid AI integration and regain control.

Broader reflections

  • Several commenters see this as another example of weak security culture (“criminal negligence,” “YOLO” shipping).
  • Consensus themes:
    • LLMs should be treated as another UI layer, not a privileged backend.
    • You cannot rely on model-level guardrails; only hard security barriers and least-privilege design meaningfully reduce risk.