GitLost Changed the Agent Attack Surface

One day after looking at another agent supply-chain risk, GitLost landed on my desk. That timing is almost too clean.

The Noma Labs write-up describes a prompt injection issue in GitHub Agentic Workflows. The short version is uncomfortable: an unauthenticated attacker could open a crafted issue in a public repository, have an agent read it, and cause data from private repositories in the same organization to be posted back into the public issue.

That is not just another prompt injection demo. It changes how we should think about the software supply chain around agents.

The input was never just input

Traditional application security taught us to treat user input as hostile. That lesson never went away. Agentic workflows make it harder because the dangerous input no longer looks like a form field or an API parameter.

It can be a GitHub issue. It can be a pull request comment. It can be a README file. It can be a support ticket, a changelog, a dependency description, or a generated report.

For humans, those are documents. For an agent, they may become instructions. That is the shift.

In GitLost, the interesting part is not that a model followed malicious text. We already know models are instruction-following systems. The interesting part is the position of the agent. It sat between public content and private repository context, with enough permission to bridge that boundary.

That bridge is the new attack surface.

Public trigger, private context, public output

The pattern is simple enough to remember: public trigger, private context, public output.

A public issue is cheap to create. The agent reads it because that is part of the workflow. The agent has repository access because it needs to do useful work. The agent then writes a response back to a public place because automation is supposed to close the loop.

Each step sounds reasonable in isolation. Together, they create an exfiltration path.

• The public issue becomes an instruction source.
• The private repository becomes readable context.
• The public comment becomes the leak channel.

This is why I do not like treating agent safety as a thin layer of refusal text. Refusals help, but they are not a permission model. A model that says no most of the time is still not the same thing as a system that cannot perform the action.

The right question is not only whether the agent should refuse. The better question is whether the agent should have been placed in that trust position at all.

Supply chain now includes workflow context

When we talk about supply-chain security, we usually mean packages, build scripts, maintainers, registries, signatures, and release artifacts. Those still matter. But agentic development adds another layer: workflow context.

The agent consumes the surrounding project environment. It reads issues, comments, files, labels, generated logs, tool output, and sometimes memory from previous runs. Any of that can influence the next action.

That means an attacker no longer needs to compromise a package to shape a build or a review process. Sometimes it may be enough to place text where the agent will read it.

This is why I think agentic supply-chain scanning has to move beyond dependency graphs. It needs to model how information flows through the agent: where instructions come from, which tools can be called, what private data is reachable, and where output can be written.

A workflow that reads public input and can access private repositories should not be treated as a normal automation job. It should be treated as a privileged boundary crossing.

Read access is not harmless

Security teams often view read access as lower risk than write access. In many classic systems, that is fair. With agents, read access can become action capability when the agent can also write somewhere else.

A human with read-only access to a private repository can still leak it, but that requires intent. An agent can leak it because it is following what it interprets as instructions. The risk is not only the permission. It is the combination of permission, instruction ambiguity, and output channel.

That matters for any organization experimenting with agentic workflows. The least-privilege discussion must include input and output boundaries, not just API scopes.

If an agent reads public content, it should not automatically have access to private organization-wide context. If it has private context, it should not be able to post unreviewed output into public spaces. If it crosses either boundary, that transition needs an explicit control.

What I would check now

If I were reviewing an agentic workflow after reading GitLost, I would start with a few boring questions. Boring questions are often the useful ones.

• Which events can trigger the agent?
• Can unauthenticated or low-trust users influence those events?
• Which text fields are passed into the model as context?
• Which repositories, files, secrets, tickets, or documents can the agent read?
• Where can the agent write without human review?
• Can public input and private context appear in the same model run?
• Is unknown or ambiguous behavior treated as HOLD, or does the workflow continue by default?

That last point matters. Unknown should not silently become allow. In agent workflows, uncertainty is not a minor state. It is a policy decision. If the system cannot prove that a piece of content is safe instruction material, it should not be allowed to steer privileged action.

This is also where tooling needs to improve. We need checks that identify workflows where untrusted content can reach agent instructions, where agents have broad cross-repository access, and where the same run can publish output to a lower-trust location.

The practical takeaway

GitLost is useful because it is easy to explain. Nobody needs a complicated exploit chain to understand the risk. A public issue influenced an agent. The agent had private context. The agent wrote to a public place.

That is the kind of pattern security programs can act on quickly.

My immediate takeaway is simple: agentic workflows need trust boundaries that are as explicit as network zones or production permissions. Public text must be labeled as untrusted. Private context must be isolated. Public write-back must be reviewed or tightly constrained. Cross-repository access should be rare, narrow, and justified.

The uncomfortable part is that this will make some agent workflows less magical. That is fine. Security work often starts when the magic gets replaced by boring controls.

Agents can still be useful. But we should stop pretending that a helpful automation with broad context is just a nicer CI job. It is a new execution surface, and GitLost is a very clear reminder of that.