GitLost Proves Your AI Agent Doesn’t Need to Be Hacked to Leak Your Data

An attacker needed no stolen password, no phishing email, and no exploit chain to pull private source code out of a GitHub organization. A single sentence, typed into a public GitHub Issue, did the job. Security researchers at Noma Labs disclosed the flaw on July 6, 2026, and named it GitLost. It lives in GitHub Agentic Workflows, which pairs GitHub Actions with an AI agent backed by Claude or GitHub Copilot, and it is not a bug in the traditional sense. It is a demonstration of what happens when an AI agent is handed more access than any single task requires, and then asked to read content nobody vetted.

Here’s the whole game: the agent didn’t get hacked. It did its job. It read an Issue, followed the instructions embedded in that Issue, and used the tool it was given — posting a public comment — to hand a stranger the contents of a private repository. Dark Reading reported that GitHub updated its documentation in response. Noma says the underlying design flaw was still live as of publication.

That distinction matters more than the vulnerability itself. Security teams have spent two decades building detection around unauthorized access — stolen credentials, privilege escalation, lateral movement. GitLost skipped all of it. The agent was authorized. It was doing exactly what it was built to do. It just wasn’t supposed to be able to reach what it reached.

Key Takeaways

1. One sentence, zero credentials.

Noma Labs, the research arm of Noma Security, exfiltrated private GitHub repository data by hiding a plain-English command inside a public Issue — no account compromise, malware, or coding skill required.

2. The guardrail broke on one word.

Prefacing the injected instruction with “Additionally” was enough to make GitHub’s AI agent treat a hijack as a legitimate follow-on task rather than a threat to refuse.

3. Access, not intelligence, was the failure.

The compromised agent held standing read access to every public and private repository in the organization in order to complete a single-issue triage task. This is an intellectual property exposure at organizational scale, not a point vulnerability.

4. This is the dominant pattern now, not an edge case.

OWASP’s GenAI Security Project maps prompt injection to six of the ten categories in its Top 10 for Agentic Applications and calls it the leading driver of agentic AI security failures in production.

5. Most organizations can’t see the gap, let alone close it.

Cloud Security Alliance research found that fewer than one in four organizations have documented AI identity governance policies, and only 12% are highly confident they can stop an attack routed through a non-human identity. A formal risk assessment that maps every AI agent’s current access scope against the minimum required for its designated task is the starting point for closing this gap.

What Happened: Inside the GitLost Attack Chain

The workflow Noma Labs targeted was ordinary. It triggered when an Issue got assigned, read the Issue’s title and body, and posted a reply using the agent’s comment tool. To do that job, it ran with read access to every other repository in the organization — public and private.

An attacker with no credentials, no repository access, and no coding skill opened a public Issue that looked like a routine internal request. Buried in the body was an instruction written in plain English, directing the agent to fetch a file from a private repository and paste its contents into a public comment. When the Issue was assigned, the agent read the text, treated the embedded instruction as a legitimate part of its task, retrieved the private file, and posted it publicly. Noma’s proof of concept pulled private repository data this way in a matter of minutes.

No malware. No exploit. No account takeover. Just language, sitting inside content the agent was designed to read as part of its normal job.

That is the part every CISO needs to sit with. This wasn’t a failure of access controls in the way the term usually gets used. The agent had the access it was configured to have. The failure was in what “configured to have” was allowed to mean. Every private repository file an agent can reach without a per-request authorization check is potential exfiltration payload — data classification applied to repository content would at minimum surface which assets carry the highest regulatory or competitive exposure if leaked.

The Guardrail Broke on One Word

GitHub had guardrails specifically designed to stop this. Noma’s researchers tested the workflow the way an attacker would, iterating on phrasing until something worked. What worked was almost insultingly simple: prefacing the injected instruction with the word “Additionally.”

Read that again. One word, chosen because it reframed a hijack attempt as a routine follow-on task, was enough to make the model comply instead of refuse.

This is the part that should worry anyone betting their AI security program on prompt-level filtering. A defense that can be defeated by a single conjunction is not a defense. It is a speed bump, and speed bumps do not stop attackers who can iterate for free, in private, for as long as they want, until something gets through.

Prompt Injection Is No Longer a Theoretical Risk

GitLost is not an outlier. It is the pattern. The OWASP GenAI Security Project’s State of Agentic AI Security and Governance, version 2.01, maps prompt injection to six of the ten categories in its Top 10 for Agentic Applications — and according to reporting from Help Net Security on the group’s 2026 findings, the report identifies prompt injection as the leading driver of agentic AI security failures currently seen in production.

The root cause is architectural, not a training gap that better models will eventually close. Large language models process the system prompt, the user’s request, and any text retrieved from external sources as a single stream of tokens. There is no reliable mechanism for marking some of those tokens as trusted commands and others as untrusted data. A hostile sentence hidden in a GitHub Issue, a calendar invite, or a customer email carries exactly the same authority to the model as an instruction from its actual operator.

That single architectural fact is why “just write a better system prompt” keeps failing as a strategy, GitLost included.

The receipts don’t stop at GitLost. Researchers disclosed CVE-2025-6514, a remote code execution flaw rated 9.6 on the CVSS scale, in a widely used Model Context Protocol package after it shipped fifteen clean releases before quietly adding a line of exfiltration code, per the OWASP-cited findings covered by Help Net Security. Separately, CVE-2026-22708 against the Cursor coding agent showed that an attacker who poisons an agent’s execution environment can turn its own allowlisted commands into a delivery mechanism for arbitrary payloads — the allowlist made the attack easier, not harder, because it auto-approved the very commands the attacker needed. CVE-2025-59532 against OpenAI’s Codex CLI demonstrated that an agent’s own output could redefine the boundary of its sandbox.

Three different vendors, three different mechanisms, one shared root cause: an agent trusted content or commands it should have treated as hostile, and nobody had scoped its access tightly enough to contain the consequences when it did. A data breach attributable to any of these vectors carries the same regulatory notification obligations as a credential compromise — the exfiltration channel is AI, but the compliance clock runs from discovery either way.

The Real Vulnerability Is Standing Access, Not Model Behavior

Here’s where it gets uncomfortable. The security industry’s instinct after an incident like this is to interrogate the model: why did it fall for “Additionally,” what filter should have caught it, which vendor patches this first. That instinct treats the symptom as the disease.

The GitLost agent needed permission to read one Issue in one repository to do its job. It had standing read access to every repository in the organization, public and private, indefinitely. That gap between what a task requires and what an identity is granted did all the real damage. The prompt injection was just the trigger.

Call it what it is: the all-access agent. Organizations are provisioning AI agents the way IT departments provisioned service accounts in 2005 — broad, standing, rarely reviewed — except now those credentials sit behind a system that can be talked into using them by anyone who can type a sentence.

Cloud Security Alliance’s State of Non-Human Identity and AI Security survey report puts numbers on exactly how widespread that gap is. Fewer than one in four organizations have documented, formally adopted policies governing how AI identities get created or retired. Only 12% report high confidence in their ability to prevent an attack launched through a non-human identity. More than 16% don’t even track when new AI-related identities get created in the first place.

Twelve percent. That is not a rounding error in a maturity model. That is nearly nine out of ten security leaders admitting, when asked directly, that they could not stop this if it happened to them tomorrow. Supply chain risk management programs that govern human vendor access but do not extend to AI agent identities provisioned by those same vendors are missing the fastest-growing non-human identity population in the enterprise.

Why Guardrails Alone Will Keep Failing

There are two intuitive responses to GitLost, and both are wrong.

The first is to block agentic AI outright until the technology matures — freeze GitHub Agentic Workflows, freeze the Copilot integrations, wait for vendors to figure it out. That surrenders the productivity an agent triaging Issues around the clock actually delivers, and it does not survive contact with a competitive market. Engineering teams that get told no will find a workaround, sanctioned or not. That workaround is shadow AI — ungoverned agents operating outside the policy perimeter, with no audit trail and no access scope review.

The second is to trust the model. Ship better prompts, subscribe to the vendor’s latest guardrail update, treat “Additionally” as a one-off bug that the next model version will catch. Gravitee’s State of AI Agent Security 2026 report shows exactly how that bet is playing out: 88% of organizations running production AI agents confirmed or suspected a security incident tied to those agents in the past year, even as 82% of executives said their existing policies already protect them from unauthorized agent actions.

Both are true. Both at once. Executives believe they are covered. The incident data says otherwise. That gap between confidence and reality is where GitLost-style attacks live, and no amount of prompt engineering closes it, because the guardrail lives at the wrong layer.

The resolution is neither blocking AI nor trusting it. It is treating agent access the way security teams already know how to treat human access, and most have simply not gotten around to it yet.

The Governance Gap Hiding Behind AI Agent Adoption

Every organization running an AI agent against its own data has already made an implicit decision about how much that agent can see. Almost none of them made it deliberately.

Standing, broad, rarely audited access is the default not because anyone chose it but because scoping access per task is more work than provisioning it once and moving on. That is the same shortcut that produced sprawling service-account permissions, forgotten IAM roles, and the third-party integrations nobody remembers authorizing. Agentic AI just moves faster, touches more systems, and — as GitLost shows — can be steered by anyone who can write a sentence in a public forum.

Noma’s own recommendations to builders make the priority order explicit: never treat user-controlled content as trusted instruction input, restrict what any agent can post publicly, and — listed first — scope permissions to the minimum the task requires. Two of those three recommendations have nothing to do with the model. They are about data governance, plain and simple. Data minimization applied to AI agent access scope — provisioning each agent with read access to only the specific repositories, files, or data types its designated task requires — is the operational implementation of that governance principle.

Regulators are not waiting for the industry to sort this out on its own timeline, either. OWASP’s report tracks 42 distinct regulatory instruments across 10 jurisdictions already addressing AI incident response, and several set notification windows measured in hours, not quarters. An organization that cannot answer “what could this agent reach” on the day of an incident will not answer it fast enough to satisfy a regulator, let alone a customer. A documented incident response plan that explicitly covers AI agent exfiltration scenarios — including runbooks for the “agent posted private data publicly” scenario GitLost demonstrated — converts a chaotic post-incident scramble into a practiced, time-bounded response.

What Actually Closes the Gap: Scoped, Governed AI Agent Access

Stop asking whether your model is smart enough to resist bad instructions. Here is the question that actually matters: if this agent gets hijacked right now, what could it actually reach?

Answering that requires four specific controls, not a vague commitment to “AI governance.”

• Scope access per task, not per identity. An agent triaging one Issue doesn’t need standing visibility into every private repository in the org. Role-based and attribute-based access control policies that evaluate every request against classification, sensitivity, and context — rather than granting a wide standing permission once — shrink the blast radius to whatever that one task actually requires. This is the same least-privilege discipline applied to human accounts for two decades, finally extended to the identities that increasingly outnumber them.
• Isolate credentials from the reasoning layer. The tokens an agent uses to act should sit in a keychain or vault the language model itself never sees. Kiteworks built its Secure MCP Server around exactly this principle: OAuth credentials are stored in the operating system’s credential store and are never made available in the LLM’s context, so a successfully hijacked agent still cannot extract the keys to reach further than the current session already allows.
• Govern the data layer independent of the agent’s own claims about its intent. An agent’s stated purpose is not a security control — it is a suggestion the agent itself generated. Kiteworks Compliant AI enforces RBAC and ABAC policy decisions at the content layer for every AI request, evaluated in real time, regardless of what the agent’s own reasoning concluded it should be allowed to do. The CISO Dashboard surfaces every AI data access event in real time, giving security teams the behavioral visibility needed to detect anomalous agent activity before an exfiltration completes.
• Assume the exfiltration channel is whatever legitimate tool the agent already has, and audit accordingly. GitLost didn’t require a new capability. It repurposed comment-posting, a feature the agent was supposed to use. Complete, tamper-evident audit trails of every file the agent touched and everything it output turn an incident from a mystery into a five-minute forensic lookup, and they are the difference between guessing what an agent did and proving it. Feeding those logs in real time into a SIEM platform gives security teams the correlation engine needed to detect multi-step exfiltration patterns that any single audit log alone would not surface.

None of this stops prompt injection from happening. Nothing on the market today reliably does. What determines whether an injection becomes a breach is not whether the model gets fooled. It’s whether the agent that fell for it had access to anything worth stealing.

What to Do Monday Morning

Stop debating which AI vendor has the better guardrails. Start auditing what your existing agents can actually reach.

Pull the permission list for every AI agent or automated workflow with access to your repositories, file stores, or zero trust data exchange environment. For each one, write down what the agent is supposed to do and compare it against what it is actually authorized to touch. Anywhere those two lists don’t match is a GitLost waiting to happen.

Then fix the gap at the access layer, not the prompt layer. Scope permissions to the task. Isolate credentials from anything the model can see or influence. Route every AI-driven data request through policy enforcement that doesn’t care what the agent claims its intent was. Log everything as though an auditor will ask for it, because eventually one will.

The organizations that get burned by the next version of GitLost will be the ones still arguing about which model is safer, instead of asking what their agents were never supposed to be able to reach in the first place.

To learn more about governing AI agent data access before the next GitLost-style incident finds your organization, schedule a custom demo today.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.