In July 2026, researchers at Noma Security showed how to make GitHub’s AI agent publish the contents of a private file into a public comment.
The attack required no code. No credentials. No access of any kind. All it took was opening an issue on a public repository belonging to an organisation that had switched on GitHub’s Agentic Workflows and waiting.
The researchers named it GitLost. GitHub had guardrails in place specifically to prevent this. The thing that defeated them was a single word: Additionally.
That is prompt injection. And the reason it deserves your attention is not that one product had a bug — it is that the flaw is structural, and the standard reassurance about it does not hold up.
Table of contents
- The one-sentence definition
- How GitLost actually worked
- Direct vs indirect prompt injection
- Prompt injection is not jailbreaking
- Why it is compared to SQL injection — and where that breaks down
- Why agents made this dangerous
- What actually reduces the risk
- What to do if you run AI agents
- FAQs
The one-sentence definition
Prompt injection is when text an AI system was supposed to treat as data gets treated as instructions instead.
That is the whole thing. A language model receives everything — its own configuration, your request, the document it was asked to summarise, the web page it fetched — as one continuous stream of text. It has no reliable way to know which parts are orders and which parts are just material.
So if attacker-controlled content contains something that reads like an instruction, the model may follow it. Not because it was tricked into malfunctioning, but because following instructions in text is exactly what it was built to do.
How GitLost actually worked
The setup is worth walking through, because it is ordinary. Nothing exotic was involved.
An organisation had configured a GitHub Agentic Workflow that triggered whenever an issue was assigned. On trigger, the agent read the issue title and body, then posted a reply using the add-comment tool. To be useful, it had been given read access to other repositories in the organisation — both public and private.
Every one of those choices is reasonable in isolation. Together they form the vulnerability.
An attacker opens an issue on the organisation’s public repository. Inside the issue body sit concealed instructions. When the workflow fires, the agent reads the issue — and reads the hidden instructions along with it, as part of the same undifferentiated text.
GitHub had guardrails designed to stop precisely this. According to Noma, the simple use of the keyword “Additionally” triggered unintended behaviour, causing the agent to access the contents of an otherwise restricted file and publish them in a public comment.
The reason that word worked is the most instructive detail in the whole incident. As one commenter put it, the payload itself did not change — only the framing token that reclassified it from new instruction to continuation of the current task in the guardrail’s assessment. That is a decision-boundary problem, not a content problem. You cannot block your way out of it with a keyword list, because the bypass was not a keyword. It was a grammatical relationship.
Direct vs indirect prompt injection
Two variants, and the distinction determines who is at risk.
Direct prompt injection is a user typing manipulative instructions straight into the system they are using. Someone tells a chatbot to ignore its rules. This is what most people picture, and it is the less serious problem, because the person doing it is usually only attacking their own session.
Indirect prompt injection is the dangerous one. The malicious instructions are planted in content the AI will later read — a web page, an email, a document, a support ticket, a GitHub issue. The victim is not the attacker. The attacker never touches the system at all. They simply leave the payload somewhere the agent will eventually go.
GitLost is indirect injection. So is essentially every serious finding in this category. Documented issues have now been reported against Slack AI, Microsoft 365 Copilot, Cursor and GitHub’s MCP integration, among others.
If your organisation lets an AI system read anything that came from outside — and almost every useful deployment does — indirect injection is your threat model.
Prompt injection is not jailbreaking
These get conflated constantly and they are different problems with different victims.
| Jailbreaking | Prompt injection | |
|---|---|---|
| Who does it | The user of the system | A third party |
| Goal | Make the model produce content it is meant to refuse | Make the model take an action on the attacker’s behalf |
| Victim | Usually nobody, or the vendor’s policy | The system’s owner or its users |
| Where the payload lives | In the user’s own message | In content the system reads later |
| What it costs you | Reputational, policy | Data, access, integrity |
Jailbreaking is a content-moderation problem. Prompt injection is a security problem. Vendors often report progress on the first and let readers infer progress on the second.
Why it is compared to SQL injection — and where that breaks down
The analogy is everywhere, and Noma’s own framing uses it. Their researchers put it directly:
“Traditional security models typically assume that trust boundaries are enforced by code. In agentic systems, trust boundaries are partly enforced by the model’s behavior, and models are inherently instruction-following. Prompt injection attacks have become, to agentic AI, what SQL injections were to web applications: a systematic, category-wide vulnerability class that requires the same systematic strategies and defenses.”
That comparison is useful, and it is usually deployed as reassurance — we solved SQL injection, we will solve this. It is worth understanding why that inference is weaker than it sounds.
SQL injection was solved by separating instructions from data. Parameterised queries send the query structure and the user’s values down separate channels. The database never has to guess which is which, because it was told.
There is no equivalent channel separation available here, and the reason is not engineering laziness. As one practitioner summarised it in discussion of the GitLost report:
“SQL injection was caused by treating user input as part of the instruction instead of as the pure data that it was intended as. Separating those two fixed it. Prompt injection is unavoidable because the user input is intended as instruction.”
That is the crux. With a database, user input was never meant to be an instruction — treating it as one was the bug. With a language model, the whole point is that natural language is the instruction interface. You cannot cleanly separate instructions from data in a system whose entire value proposition is understanding instructions expressed as data.
TechyKnow’s assessment: the SQL injection comparison is right about the shape of the problem — category-wide, systematic, requiring layered defence — and misleading about the resolution. Treat prompt injection as a risk to be managed and contained rather than a bug awaiting a patch. Anyone promising it is solved is describing their guardrails, and GitLost is what guardrails look like when they fail.
Why agents made this dangerous
Prompt injection has been understood since large language models became widely available. For a while it was mostly a curiosity, because a model that could only produce text could only produce embarrassing text.
Agents changed the consequence. Once a system can call tools, read repositories, send messages and modify records, a successful injection stops producing a bad sentence and starts producing an action.
Two factors turn a manageable risk into a serious one:
Excessive permissions. As one commenter on the GitLost report noted, the dangerous part is not that the agent is capable — it is that it may be connected to too much context, too many repositories, or overly broad tokens. The GitHub agent could reach private repositories because that made it more useful.
Collapsed trust boundaries. A fractional CTO’s summary of GitLost is the sharpest statement of what actually changed:
“The private repo was never a security boundary. It was an organisational one, and it held only as long as every reader of your code was a human you employed. Agents break that assumption. […] If an agent has access to your private repos, treat everything in them as one well-crafted issue away from public.”
That generalises well beyond code. Any access control that worked because the people holding access were trustworthy now has to work against a reader that follows instructions from strangers.
What actually reduces the risk
No single control is sufficient, and honest guidance says so plainly. What follows genuinely narrows the blast radius.
Never treat external content as instructions. Noma’s primary recommendation. User-controlled content — issue bodies, emails, fetched pages, uploaded documents — should be isolated from the instruction context, or sanitised, before it reaches the model. This is imperfect and still the most important control.
Scope permissions to the task, not the role. An agent that triages issues does not need read access to every private repository in the organisation. Cross-repository access makes an agent a high-value target. Ask what the specific workflow requires, then grant only that.
Limit what the agent can publish. GitLost was damaging because the agent could post publicly. An agent that reads sensitive data and can write to a public surface is a data-exfiltration path by design. Separate those capabilities.
Put a human between the agent and irreversible actions. Sending, publishing, deleting, paying, merging. Approval gates are unglamorous and they work.
Log every tool call. You cannot investigate what you cannot see. Record which tools were called, with what arguments, and what came back.
Assume it will eventually succeed. Design so that a successful injection is survivable. This is the mindset shift that matters most, and it is the same one that took the industry two decades to adopt about phishing.
What to do if you run AI agents
Three questions, answerable this week.
- What can each agent read? Write the list down. Most teams discover the answer is broader than anyone intended, because permissions were set during a prototype.
- What can each agent write, send or publish? Anything on this list that is publicly visible, combined with anything on the first list that is sensitive, is an exfiltration path.
- Where does untrusted content enter? Any input a stranger can influence — issues, tickets, emails, forms, fetched URLs — is where an injection payload will arrive.
If those three lists intersect uncomfortably, you have found your priority.
The broader context is the one TechyKnow has tracked through agentic AI all year: capability has moved faster than the discipline around deploying it. It rhymes with the failure behind 175,000 publicly exposed APIs — infrastructure granted access nobody re-examined once it was working.
The practical next step: find one AI agent in your organisation and check what it can read and where it can post. If it can reach anything confidential and write anywhere public, you have a GitLost-shaped problem, and it does not require an attacker with any skill at all.
FAQs
What is prompt injection in simple terms?
Prompt injection is when text an AI system was supposed to treat as data gets treated as instructions instead. A language model receives its configuration, your request and any content it reads as one continuous stream of text, with no reliable way to distinguish orders from material. Attacker-controlled content that reads like an instruction may therefore be followed.
What is indirect prompt injection?
Indirect prompt injection is when malicious instructions are planted in content the AI will read later — a web page, email, document or code issue — rather than typed at the system directly. The attacker never interacts with the target system, and the victim is whoever runs the agent. This is the variant behind essentially every serious documented case.
Is prompt injection the same as jailbreaking?
No. Jailbreaking is a user pushing a model to produce content it is meant to refuse, which is a content-moderation problem. Prompt injection is a third party making the model act on their behalf against its owner, which is a security problem. Vendors often report progress on jailbreaking and let readers infer progress on injection.
How did the GitLost attack work?
A GitHub Agentic Workflow triggered on issue assignment, read the issue body, and could post comments while holding read access to private repositories. An attacker opened an issue on a public repository containing concealed instructions. Noma Security reported that use of the keyword “Additionally” was enough to defeat the guardrails, causing the agent to read a restricted file and publish its contents publicly.
Can prompt injection be prevented completely?
Not on current evidence. SQL injection was solved by separating instructions from data through parameterised queries. No equivalent separation exists for language models, because natural language instruction is the interface itself. The realistic goal is containment — restricting permissions, isolating untrusted input, gating irreversible actions and logging everything — rather than elimination.
Why is prompt injection compared to SQL injection?
Because both are systematic, category-wide vulnerability classes arising from the same root cause: input crossing a trust boundary it should not cross. The comparison is accurate about the shape of the problem and misleading about the fix, since the mechanism that resolved SQL injection has no direct equivalent here.
Which AI products have been affected?
Documented findings have been reported against Slack AI, Microsoft 365 Copilot, Cursor and GitHub’s MCP integration, alongside the GitLost finding against GitHub Agentic Workflows. This is a property of how language models work rather than a defect in any one product, so treat absence from that list as absence of published research, not evidence of safety.
What is the single most effective defence?
Reducing what the agent can reach. Most damaging cases combine broad read access to sensitive data with the ability to write somewhere the attacker can see. Breaking that combination limits the damage even when an injection succeeds.
