Agents need blast doors

A GitHub issue is supposed to be low-risk product input. GitLost shows why that assumption breaks when an AI agent can read the issue, touch private repositories, and write back to a public thread.

Noma Security described GitLost as an indirect prompt-injection attack against GitHub Agentic Workflows: an attacker can open an issue in a public repository, place malicious instructions inside that issue, and trigger an agentic workflow that may read private repository data and post it back publicly. 1 SC Media and The Hacker News both reported the same core attack path: public issue input, agent workflow execution, and private-repository leakage through the agent's output channel. 2 3

The PM read is simple: the risky pattern is public input + private permissions + public output. If an agent sits across all three, the product team needs to treat prompt injection as an access-control problem, not as a wording problem.

GitLost matters because the attacker does not need repo access. The issue itself is the delivery channel. Noma Security said the attack could be triggered from a public repository issue, and the proof of concept leaked README.md content from sasinomalabs/poc, sasinomalabs/remote-ping, and sasinomalabs/testlocal. 1

The bypass detail is also product-relevant. Noma Security researchers found that putting "Additionally" before the injected instruction could evade GitHub's built-in guardrails. 1 That does not prove every filter is useless. It does show that a filter sitting in front of an agent with broad permissions is a weak launch gate.

The Hacker News discussion turned on whether GitLost should be treated as a GitHub product vulnerability or as a user-configuration error. 4 For a PM shipping agents, that debate is less useful than the boundary test: can untrusted input cause a trusted agent to reveal private data or write to a public surface?

A normal web product can treat a public issue as untrusted input and keep it away from private data. An agent product often collapses that separation. The agent reads the public issue as task context, uses private credentials to complete the task, and writes the result somewhere the user can see.

That is why the SQL-injection analogy is useful. The failure begins when untrusted input is allowed to change how a trusted system behaves. CrowdStrike said its prompt-injection taxonomy now covers more than 200 techniques, which points to a broad attack class rather than one brittle string pattern. 5

The same pressure is showing up around coding agents and web agents. An arXiv paper on AI coding-agent execution security organized 39 papers into 17 categories of execution-security mechanisms. 6 SC World reported a Zscaler finding where hidden HTML prompt injection induced 4 of 26 tested LLMs to execute cryptocurrency-payment behavior. 7 The European Systemic Risk Board warned that frontier AI models could strain cyber resilience in the financial system, especially as AI changes both attacker and defender capabilities. 8

Those sources are not all describing the same exploit. They are pointing at the same product requirement: an agent should not get to treat every piece of text it reads as equally authoritative.

The first product decision is blast radius. A GitHub agent should start with repository-level permissions, not organization-level permissions, unless the product has a concrete workflow that needs wider scope. GitLost's danger comes from the bridge between a public trigger and private repository access, so reducing the private side of that bridge is the fastest risk reduction.

The second decision is context separation. Product requirements should distinguish system instructions, developer instructions, retrieved content, user-authored public content, and tool outputs. The UI does not need to expose that whole taxonomy, but the agent runtime does. If public issue text enters the same context lane as system instructions, the product is asking the model to solve an access-control problem with language behavior.

The third decision is output control. An agent that can read private data should not be able to write to a public issue, PR comment, email, Slack channel, or ticket without a review gate. The lightweight version is a human approval step for public writes. The stronger version is an output classifier that blocks secrets, private file contents, credentials, and cross-repo excerpts before the draft reaches a public surface.

For a PM, the launch checklist should look like this:

The validation metric should not be "did the agent finish the task?" A safer launch gate measures whether the agent finished the task without crossing trust boundaries. Track private-resource reads, blocked public writes, approval overrides, prompt-injection test failures, and post-review edits. Without those metrics, the product review cannot see the failure mode GitLost exposed.

The practical shift is that agent security becomes part of the feature spec. A PM writing requirements for an agentic workflow now needs permission scope, trust boundaries, review gates, audit logs, and red-team cases in the same doc as user value and task completion.