GitLost tests the weak edge between GitHub agents and private repos

Noma Security’s GitLost write-up targets a practical failure mode in GitHub’s agentic workflows: an AI agent reads a public GitHub Issue as task context, then uses its available tools and repository access in ways the issue author should never be able to trigger. In the reported scenario, a crafted issue in a public repository belonging to an organization could influence an agent that also had access to private repositories.

The important detail is not that a model can be persuaded by text. That is already well understood. The sharper issue is the combination of untrusted text, tool use, and broad repository permissions. Once those pieces sit in the same execution path, prompt injection starts to resemble an old CI mistake: running untrusted input in a job that can see sensitive code or secrets.

HN discussion quickly moved from the demo to responsibility boundaries. Some readers framed it as a platform problem because an agent with private-repo reach should not be steerable from a public issue. Others argued that any automation with sensitive access will leak if it is configured to obey public content. Both readings point to the same engineering requirement: agent permissions need to be scoped by input source, not just by the human who installed the workflow.

For teams adopting repository agents, GitLost is a useful checklist item. Treat issues, comments, markdown files, logs, and tickets as attacker-controlled data unless proven otherwise. Keep private repository access out of public-triggered flows, require approval before cross-repository reads, and log tool calls in a way reviewers can audit. The agent should help with work, but it should not become a soft bypass around the organization’s existing access model.