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

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.