GitLost and Clinejection both got blamed on prompt injection. The real gap was AI agent permissions.

Two supply-chain incidents landed five months apart in 2026, and most of the coverage filed them under the same tag: prompt injection. Clinejection compromised the release pipeline of an AI coding assistant in February. GitLost, disclosed by Noma Security in July, tricked GitHub's own Agentic Workflows into leaking private repository contents through a public issue. Read past the injection payload in each case, though, and the pattern that actually mattered is different: neither incident needed injection alone to succeed. Both needed an agent that already held more reach than the task in front of it required. That's an AI agent permissions problem, and it's the one most teams running agentic CI/CD haven't audited yet.

Prompt injection filtering is still an open research problem. Every major provider's coding agent has been shown susceptible to at least one high-severity injection technique in its default configuration, and the papers proposing defenses are still working through what “catch everything” would even look like. Permissions are a problem you can actually close this week. These two incidents show what closing it looks like, and what leaving it open costs.

Clinejection: a GitHub issue title becomes a supply-chain attack

Cline is an open-source AI coding agent that runs inside VS Code and, until February 2026, triaged its own GitHub issues with an AI workflow: a Claude-based agent read new issues and decided how to label and route them. Between 21 December 2025 and 9 February 2026, that triage workflow carried a prompt injection vulnerability. Security researcher Adnan Khan showed that an issue title alone, no body text needed, could redirect the triage agent's next actions.

The interesting part isn't the injection. It's what the triage workflow could reach once redirected. Cline's GitHub Actions setup shared a cache namespace between the triage workflow and the workflows that published nightly releases to npm, the VS Code Marketplace, and OpenVSX. An attacker who could poison that cache could pivot from an agent that labels issues to workflows that publish production releases, without ever touching a credential directly. On 17 February 2026, someone did: a tampered build of the Cline CLI, version 2.3.0, went out on npm with a postinstall script that silently installed an unauthorized second agent on developer machines. It stayed live for roughly eight hours and reached an estimated 4,000 installs before Cline pulled it and shipped a fix in 2.4.0.

Cline's actual remediation says more than its postmortem does. The team didn't try to make the triage agent immune to injected instructions. It removed the vulnerable triage workflow entirely and moved npm publishing to OIDC-based, short-lived credentials, eliminating the long-lived static tokens the pivot had depended on. The fix targeted what the agent could reach, not what it could be told.

GitLost: one word bypassed the guardrail

GitHub Agentic Workflows, the platform's own feature for running AI agents inside GitHub Actions, entered technical preview in February 2026 and public preview that June. Workflows run with read-only permissions by default; write actions are gated behind a set of preapproved “safe outputs”, like posting a comment, rather than letting the agent execute arbitrary code. It's a sensible default. It wasn't enough.

In July, Noma Security published GitLost: a proof of concept where an unauthenticated attacker opens an issue in the public repository of an organisation that also runs private repositories under the same Agentic Workflows setup. The workflow triggers on issue assignment and is configured to post a comment back using the add-comment safe output. Noma's issue asked, plainly, for the README of the public repo. Then, prefixed with the single word “additionally,” it asked for the README of a named private repo in the same organisation. By Noma's account, that one word was enough to make the model reframe its response instead of refusing it, and the private README came back in a public comment. No credentials, no code execution, no privileged account. Just an issue anyone with a GitHub account could open.

Noma's recommendations are correspondingly narrow and specific: never treat issue content as trusted instruction input, scope agent permissions to the minimum required, restrict what an agent can post publicly, and sanitise or isolate untrusted input before it reaches the model's instruction context.

The common thread: AI agent permissions, not prompt injection

Both incidents get filed as prompt-injection stories because injection is the visible entry point. It's the part with a proof-of-concept payload and a name that sticks. But injection was the delivery mechanism in each case, not the vulnerability that actually determined how bad things got.

In Clinejection, the vulnerability that mattered was a long-lived static token reachable from a workflow that had no business reaching it. A triage agent that mislabels an issue is a minor annoyance. A triage agent that can pivot, through a shared cache, into a workflow holding npm publish credentials is a supply-chain incident waiting for a prompt. In GitLost, the vulnerability that mattered was a single agent identity with standing read access to both public and private repositories in an organisation, paired with a write tool that had no concept of a trust boundary between them. Neither team needed to fully defeat prompt injection to prevent the outcome that happened. They needed the agent's blast radius to be smaller than everything the underlying token or identity could technically reach.

This isn't an argument that input filtering and output screening are worthless. Pre-LLM screening and post-execution guardrails both belong in a serious agentic pipeline, and the research on tool-dependency graphs and causal diagnostics for catching injected instructions is real, active work. It's an argument that they're the second layer, not the first. The first layer is making sure that when a check fails (an agent misreads a title, misjudges a comment, gets talked into “additionally”) there's nothing valuable on the other side of that failure.

The permission-boundary checklist that would have contained both

None of the following is novel security advice. It's the same least-privilege principle that's been applied to service accounts and CI credentials for a decade, pointed at a newer kind of principal. What's changed is that AI agents make it easy to forget the principle applies, because the agent's ask, “let me read this repo so I can triage the issue,” sounds so much narrower than the access it's actually granted.

1. Remove long-lived static secrets from any workflow an agent can reach, directly or by pivot. Cline's fix, OIDC-based short-lived credentials for npm publishing, is the general pattern: a compromised agent session shouldn't be able to mint a token that outlives the session.
2. Scope agent identities per repository, not per organisation. GitLost's cross-repo leak was only possible because a single agent identity could read both the public and private repo. A triage agent for repo A should hold a token for repo A.
3. Treat ‘safe output’ or tool allowlists as necessary, not sufficient. Restricting an agent to add-comment stops it from deleting a branch. It doesn't stop it from commenting private data into a public thread. Gate the content, not just the action.
4. Separate the workflow that ingests untrusted content (issues, PR descriptions, code comments) from the workflow that holds anything valuable. Clinejection's pivot existed because a triage workflow and a publish workflow shared a cache namespace. They didn't need to.
5. Log agent tool calls against the content that triggered them, so a pattern like ‘additionally, also post the contents of X’ is auditable after the fact, even on the runs where it wasn't caught before execution.

# Before: one workflow identity, broad reach
permissions:
  contents: write
  packages: write
  actions: write
  issues: write

# After: split by workflow, scoped to what each step needs

# triage.yml -- reads issues, cannot touch releases
permissions:
  contents: read
  issues: write

# publish.yml -- separate workflow, OIDC short-lived credential,
# no shared cache with triage.yml
permissions:
  contents: read
  id-token: write   # OIDC -- no static npm token stored

What to audit in your own agentic pipeline this week

Most teams running an AI coding agent, whether that's a self-hosted setup like Cline's old triage workflow, GitHub's own Agentic Workflows, or a Copilot-adjacent tool, can answer “does this agent read untrusted content?” faster than they can answer “what could this agent's credentials reach if it did the wrong thing right now?” The second question is the one worth spending an afternoon on.

Three places to start: list every workflow where an AI agent reads issue bodies, titles, PR descriptions, or code comments, since all four are writable by anyone with basic repository access. For each one, check whether its credential or cache namespace is shared with anything that can publish, deploy, or touch a secret. And check whether ‘safe output’ or tool-allowlisting is being treated as the whole control, rather than as one layer sitting in front of a permission boundary that would hold even if the first layer failed.

Prompt injection research will keep improving, and it should. But the two incidents that actually cost engineering teams time and credentials this year weren't stopped by better filtering. They were contained, after the fact, by permission boundaries someone had already drawn narrowly enough to matter. That's the boundary worth drawing before the next issue titled “Additionally,” gets opened.