GitLost is easy to overstate and dangerous to understate. It does not mean every private repository on GitHub can be stolen through a public issue. It does show a very real failure pattern for AI agents: private data, untrusted input and a public output channel in the same workflow.

AI agent trust boundary between public issues and private repositories

Noma Labs published the GitLost research on July 6. The target was GitHub Agentic Workflows, a preview feature that lets teams describe repository automation in Markdown and run an AI agent inside GitHub Actions. The agent can read issues and pull requests, call tools and respond through approved outputs. GitHub's own documentation presents the system as security first: read-only tokens by default, sandboxing, safe outputs and a threat detection scan before changes reach GitHub.

Those controls matter. They also did not remove the basic risk. In Noma's proof of concept, a public issue in an organization's public repository steered an agent into reading content from a private repository and posting the result as a public issue comment. According to Noma and The Hacker News, the attacker did not need stolen credentials or access to the private repository. The risky condition was architectural: the agent could read public input, it had broad read access to private repositories, and it could publish a reply where outsiders could see it.

That is the story worth caring about. Not panic. Not "GitHub is broken." A narrower and more useful lesson: if an AI agent is allowed to listen to strangers, read private material and talk back to a public channel, the prompt becomes a control surface.

What happened in GitLost

GitHub Agentic Workflows began as a technical preview in February and is now described in the project documentation as public preview. The idea is attractive. Instead of writing complex YAML for every repository task, a team writes a natural-language Markdown workflow. The gh-aw CLI compiles it into GitHub Actions. The agent can triage issues, analyze pull requests, inspect CI failures, update documentation or prepare maintenance work.

In normal use, that is a productivity feature. In security terms, it is a service account with a language interface.

Noma's vulnerable workflow was triggered when an issue was assigned. It read the issue title and body, then used an add-comment style output to answer. It also had read access to other repositories in the same organization, including private ones. The proof of concept issue looked like a routine business request, not an obvious exploit. Once the workflow ran, the agent retrieved README content from both a public repository and a private repository, then placed that content in a public comment.

The exact wording of the test prompt is not useful to publish as a recipe. One detail is still important: Noma and The Hacker News reported that a small phrasing change helped the output pass a guardrail that should have stopped it. Treat that as a warning about filters, not as a magic word. If the only boundary is a model deciding whether a request sounds suspicious, the boundary will fail eventually.

The impact is conditional, not universal

The calm version of this story matters because the conditions matter.

GitLost is not a claim that any random GitHub issue can reach any private repository. A vulnerable setup needs several pieces at once: an agentic workflow enabled by the organization, public or attacker-controlled input reaching the agent, a token or tool path that can read private repositories, and an output path that can publish the result to a public issue or comment.

That limitation should not make teams dismiss it. Many real business workflows are moving toward exactly this shape. An agent reads external tickets, pull requests, support messages, Sentry events, Slack threads or issue comments. It gathers internal context. It posts an answer. The convenience comes from connecting those zones. The risk comes from connecting them without a hard boundary.

Read-only access is often misunderstood here. A read-only token cannot push code, but it can still read sensitive material. If the same agent can send output to an attacker-visible channel, read-only becomes enough for exfiltration. That is why scope matters more than the label on the permission.

The lethal trifecta applies cleanly

Simon Willison's "lethal trifecta" is a useful way to think about this class of incidents: private data, untrusted content and external communication. Mix all three inside one agent, and prompt injection turns from an embarrassing chatbot trick into a data leak path.

GitLost fits the model almost too neatly. The private data is repository content. The untrusted content is the public issue. The external communication is the public comment. Remove any one of the three and the outcome changes. A public issue that cannot reach private data is much less dangerous. Private data without a public output channel is harder to leak. A public comment bot that never reads private repositories has less to lose.

The lesson is not that agents should never read tickets or repositories. The lesson is that trust zones need to match. Public input should not authorize private-data access. Private-data analysis should not automatically write to public output. If a workflow crosses that line, the crossing should be explicit, reviewed and logged.

Why the HN argument is useful

The Hacker News story and the Hacker News discussion pulled the same thread from different directions. Some commenters treated GitLost as an obvious misconfiguration: why did anyone give a public-issue workflow broad access to private repositories? Others treated it as an agent security failure: the model cannot reliably separate owner instructions from attacker-written text. A third group saw the familiar pattern of developer platforms racing to ship AI integrations before administrators have mature controls.

All three views have a point.

It is a configuration problem because token scope and trigger design made the leak possible. It is an agent problem because the agent accepted untrusted text as actionable instruction. It is a product problem because safe defaults, warnings and permission UX determine how often teams build that shape by accident.

Security teams should resist the urge to pick only one explanation. When a failure needs several weak decisions, the fix also needs several controls.

What to check before enabling agents

Start with three questions. What can the agent read? Who can write into the agent's context? Where can the agent send results?

If the answers are "private repositories," "anyone who can open an issue," and "a public comment," stop. That is not a harmless automation. It is an exfiltration path waiting for a prompt injection.

Scope agent tokens to the smallest useful set. A workflow that triages one public repository rarely needs organization-wide private repository read access. If cross-repository context is needed, use a separate workflow, a separate identity and a review step before any result leaves the private boundary.

Separate public-facing and private-facing agents. The agent that responds to public issues should not be the same actor that can read sensitive internal repositories. The agent that performs private analysis should not publish directly to public channels. It can prepare a proposed response for a human reviewer or for a safer downstream job.

Treat output as a security decision. Safe outputs and threat scans are useful backstops, but they should not be the only gate. A workflow that can mention private content in a public comment needs a strong policy about what may leave the boundary, plus logs that show the input source, data sources consulted, proposed output and final action.

Practical controls for teams

Use per-repository or per-purpose tokens instead of broad organization-level tokens. Prefer short-lived credentials. Rotate them. Keep personal access tokens out of agent workflows when a narrower installation token or service identity can do the job.

Restrict triggers. Public issues and comments should not automatically wake an agent with private access. Require labels, membership checks, trusted authors, maintainer approval or an internal handoff before the agent can touch private material.

Make private data private all the way through the workflow. A report generated from private repositories should land in a private issue, internal channel or pull request visible only to the right group. If someone wants to publish a summary, that should be a separate reviewed action.

Log tool calls and data boundaries. "The AI posted it" is not an incident report. Teams need to know which issue triggered the run, which repositories were read, which token was used, what output was proposed and who approved it.

Test the failure mode. Before enabling an agent broadly, run a tabletop or red-team exercise with a fake public issue and a dummy private repository. The goal is not to collect a clever prompt. The goal is to prove that the public issue cannot cause private data to appear in public output.

What vendors should improve

Vendors should not push all of this onto customers. Agent platforms need visible trust labels. Content from public issues, external pull requests, logs, web pages and MCP tools should carry its origin through the system. Policies should be able to say: this content may inform analysis, but it may not authorize a private read or a public write.

Permissions need to be understandable. "Read-only" is not enough if the agent can read private data and speak publicly. "Autonomous" is not enough if administrators cannot see which tools, repositories, outputs and network paths the agent can use.

Preview features need preview-grade warnings. GitHub's documentation already talks about prompt injection, malicious repository content and compromised tools. That is good. The next step is making risky cross-boundary combinations hard to create by accident.

The useful takeaway

GitLost should not make teams abandon AI automation. It should make them stop treating agents like chat windows.

An AI agent inside a developer workflow is a credentialed actor. It reads, reasons and acts with whatever permissions the organization gave it. The model's intent does not matter as much as the boundary around it.

For Cybersecurity Without Panic, the rule is simple: do not connect public input, private data and public output in one unattended agent. If you need to cross that boundary, make the crossing explicit, narrow, reviewed and logged. That is less exciting than a headline about a one-word bypass. It is also the control that will still matter after this specific story fades.