AI Agent Security and the Lethal Trifecta. GitLost Is the Proof.

Here is the whole exploit in one sentence. A stranger opens a normal-looking public GitHub Issue, phrased like a routine request, with a few plain-English instructions buried in the body. GitHub's Agentic Workflow picks it up, its AI agent reads the issue, follows the buried instructions, opens a private repository, and posts the contents back as a public comment. No code. No account. No prior access to the target.

Noma Security disclosed this in July 2026 and called it GitLost. The security press picked it up within a day. And the most common reaction, the one worth arguing with, is that this is a GitHub bug: scope the agent's permissions like a CI job and it is patched. That reaction is exactly why this keeps happening.

What is the GitLost vulnerability?

GitLost is an indirect prompt-injection flaw in GitHub's Agentic Workflows, disclosed by Noma Security. An unauthenticated attacker opens a public issue with hidden instructions in the body. The workflow's agent, running with read access across the org's repositories, processes that issue, follows the instructions, reads a private repo, and publishes the contents as a public comment.

Indirect prompt injection means the attacker never talks to the model directly. They plant instructions in content the agent will later read, an issue, a comment, a linked web page, and wait for the agent to treat that content as a command. The reason this works is not a missing permission check. It is that the agent cannot reliably tell an instruction from data, because in a language model both arrive as text on the same channel.

That is the move the CI mental model misses. In a normal GitHub Action, the inputs are code and configuration you control. In an agentic workflow, the input is natural language from anyone who can open an issue. User-controlled content quietly became instruction input, and almost nobody redrew the trust boundary to match.

What is the lethal trifecta in AI agents?

The lethal trifecta, a term coined by Simon Willison, is the combination of three capabilities that makes any AI agent structurally exploitable: access to private data, exposure to untrusted content, and the ability to communicate externally. Give one agent all three and prompt injection can turn its own data access into an exfiltration channel. GitLost is that theorem with GitHub's name on it.

The mapping is one-to-one, which is what makes it undeniable rather than clever.

Reading across the three legs of GitLost: the agent can read private repositories (private data), it ingests an attacker-authored public issue (untrusted content), and it can post a public comment (external communication). All three legs, one agent, in the default configuration. The exploit is not a surprise. It is what the framework predicts. And because the trifecta is a property of the shape of the system, not the quality of the model, a smarter model does not close it. A smarter model just follows the buried instructions more competently.

This is not the first time we have watched this exact shape play out. When ChatGPT for Sheets ran an action its own approval setting was supposed to gate, the lesson was the same one wearing different clothes: once an agent can act on untrusted input and reach outside, the control you thought you had is a suggestion.

Why isn't least-privilege enough to secure agentic workflows?

Least-privilege is necessary but not sufficient. The GitLost agent was not wildly over-permissioned in the CI sense. It held exactly the access its job seemed to need: read the org's repos, comment on issues. That scoping is reasonable, and it still leaves two legs of the trifecta standing the moment the agent touches a public issue.

This is the crux, and it is easy to get wrong in either direction. Do not dismiss least-privilege, it genuinely shrinks the blast radius, and you should still scope tightly. But do not mistake it for a fix. Tightening a scope reduces how much an exploit can reach. It does not remove the structural condition that makes the exploit possible in the first place. An agent scoped to "only read our repositories and only comment on issues" is a lethal trifecta by construction, because reading private repositories is one leg and commenting publicly is another, and the untrusted issue supplies the third for free.

The trust boundary in an agentic workflow is not "who is allowed to run the workflow." It is "whose words the agent will treat as instructions." After GitLost, the honest answer is: anyone who can open an issue.

How do you secure an AI agent against prompt injection?

You remove a leg of the trifecta, because you cannot prompt the risk away. Treat all user-controlled content as data and never as instructions. Keep untrusted input out of the same context as the agent's instructions, through taint-tracking or policy-gating. And break the read-private-plus-write-public combination so that no single agent can both hold a secret and publish it.

Those are the shapes of Noma's mitigations, generalized past the specific incident. Notice that none of them is "write a better system prompt telling the agent to ignore malicious instructions." Prompt injection has repeatedly defeated that approach, because the same channel carries both the honest instruction and the attacker's, and the model has no reliable way to rank them. The fix lives in the architecture, in what the agent is able to do, not in what you politely ask it not to do.

This is the looks-done versus actually-done gap that we usually talk about for features, moved to the plumbing. An agentic workflow that demos flawlessly is telling you about the happy path. The trifecta lives on the adversarial path, and it stays invisible until someone opens the right issue. That is the same reason a vibe-coded app can pass every click-through and still be wide open in production: the demo never included an attacker.

And this is where the collaboration framing earns its keep, because it has teeth here. An agent is a collaborator you grant capabilities to. Granting it private read plus public write is granting it the ability to be turned against you by a stranger. The agent's action surface is an engineering decision you own, whether or not you treat it as one. You design that surface deliberately, or an attacker designs it for you through the next issue body.

One honest counter-weight, because the story is not "AI is dangerous, GitHub is careless." Responsible disclosure worked: Noma reported GitLost privately before publishing. Agentic workflows are genuinely useful, and GitHub shipped the feature that made the trifecta concrete, which is not the same as shipping negligence. The teams that get the value without the exfiltration are the ones treating agent permissions as an architecture problem, not a checkbox.

GitLost will be patched. The lethal trifecta will not, because it is not a bug, it is the shape of the thing. Every agent you give private access, untrusted input, and a way to talk to the outside world is one clever issue away from its own version of GitLost. Design the trifecta out, or keep meeting it by its next name.