GitHub's Agentic Workflows let teams write automation in Markdown, compile it to Actions YAML, and hand execution to an AI agent backed by Claude or GitHub Copilot. The agent reads issues, calls tools, and responds — often across multiple repositories in an organization.
On July 6, 2026, Noma Security published GitLost: an unauthenticated attacker could post a crafted issue on a public org repo and get the agent to exfiltrate README content from a private repo into a public comment. No credentials. No coding. Just plain English hidden inside plausible corporate text.
The Hacker News thread hit 174 points in hours. The argument split cleanly: misconfiguration (you gave the agent too much access) vs systemic agent risk (prompt injection is the new SQLi). Both are true — and that is why GitLost matters for anyone running Claude Code agents, MCP tools, or GitHub's new workflow surface.
TL;DR: What People Are Asking
| Question | Answer |
|---|---|
| What leaked? | README.md from private repo testlocal (+ public repos) posted as issue comment |
| Attacker needs? | Nothing — open issue on public org repo, wait for workflow |
| Trigger? | issues.assigned (other issue events also worked in testing) |
| Bypass trick? | "Additionally" prefix reframed output past guardrails |
| PoC org? | sasinomalabs — issue #153, workflow run |
| Fixed? | Disclosed to GitHub — no public patch date in Noma's post |
| Core lesson? | Context window = attack surface; permissions must live outside the model |
What Are GitHub Agentic Workflows?
GitHub Agentic Workflows are a layer on top of GitHub Actions:
| Piece | Role |
|---|---|
| Markdown workflow | Human-readable automation spec (.md) |
| Compiler | Turns Markdown → Actions .yml |
| AI agent | Claude or Copilot — reads issues, picks tools |
| Permissions | Configurable — can include other org repos |
The product promise: "Write workflows in plain English; the agent handles the rest."
The security question Noma asked on day one: What happens when the agent reads something it should not trust?
Answer: Indirect prompt injection — untrusted issue text becomes instructions; the agent follows them with whatever tools and repo access the workflow grants.
The GitLost Attack Flow
Noma's vulnerable test workflow was configured to:
- Trigger on
issues.assigned(and similar issue events) - Read issue title and body
- Respond via
add-commenttool - Run with read access to other org repositories — public and private
Step 1: Craft the issue
The issue looked like a normal sales follow-up — VP Sales asking to attach customer meeting notes. Hidden inside: instructions to fetch README files from named repos.
Step 2: Wait for automation
When GitHub automation assigned the issue, the workflow fired.
Step 3: Exfiltration via public comment
The agent:
- Fetched
README.mdfromsasinomalabs/poc(public) - Fetched
README.mdfromsasinomalabs/testlocal(private) - Posted both in a public comment on the issue
Anyone on the internet could read the comment.
The "Additionally" exploit
GitHub had guardrails meant to refuse obvious exfiltration. Noma found that starting a malicious clause with "Additionally" caused the model to reframe rather than refuse — a brittle prompt-layer defense failing under adversarial phrasing.
This is closer to jailbreak-style manipulation than to traditional access-control bugs — the permissions enabled the leak; the phrasing trick activated them.
Proof of Concept (Public)
Noma published reproducible artifacts:
- Workflow run: github.com/sasinomalabs/poc/actions/runs/23909666039
- Issue: github.com/sasinomalabs/poc/issues/153
Leaked data confirmed: README from public poc, public remote-ping (no README), and private testlocal.
Why GitLost Matters: The Lethal Trifecta
Simon Willison's lethal trifecta for agents (cited repeatedly on HN):
- Access to private data
- Exposure to untrusted input (public issues, PRs, comments)
- Ability to exfiltrate (post publicly, send email, call webhooks)
GitLost hits all three in one workflow. Remove any leg and the attack fails — but GitHub's defaults and UX make it easy to assemble all three without realizing it.
Noma's framing:
"Prompt injection attacks have become, to agentic AI, what SQL injections were to web applications."
HN pushed back hard on the SQLi analogy — prepared statements fix SQLi completely; LLMs are instruction-following by design, so separating data from instructions is fundamentally harder. The comparison still helps non-technical buyers understand category-wide risk, not a single patchable bug.
HN Debate: Misconfiguration vs Platform Responsibility
| Camp | Argument |
|---|---|
| Misconfiguration | Researchers granted cross-repo private read + public comment on issue triggers — like CI with secrets on fork PRs. Your fault. |
| Platform gap | Users assume repo-scoped agents. GitHub should default to current-repo-only, warn on org-wide private access, or block public-trigger + private-read combos. |
| Guardrails theater | "Additionally" bypass proves prompt-only defenses fail; need hard permission boundaries per workflow. |
| Not fixable in-model | You cannot patch an LLM to never follow untrusted text; must remove capability (no private access, no public posting) or isolate input. |
Practical synthesis for builders:
- Permissions are the real fix — not better refusal prompts
- Per-workflow scoping — separate agents for public vs sensitive repos
- Allow-list triggers — do not run privileged agents on
issues.openedfrom strangers - Output gates — human approval before any comment containing fetched file content
Same playbook as Claude Code permission modes: security lives in what tools can run, not in please behave system prompts.
Noma's Recommendations (Mapped to Your Stack)
From the GitLost disclosure:
- Never treat user content as trusted instructions — issues, PRs, wiki pages, issue templates
- Minimum permissions — cross-repo access is a high-value target
- Restrict public agent output — especially replies driven by issue content
- Sanitize / isolate user input before it enters model context
For MCP-heavy setups, mirror our MCP security checklist:
- Validate tool outputs before they re-enter context as instructions
- Audience-scoped tokens per server
- Audit log every tool call with correlation IDs
For pre-release agent testing, OpenAI Deployment Simulation replays production-like inputs — the same class of "what if issue text is malicious?" probing enterprises should run internally.
GitLost vs Other Noma Research
Noma Labs has a series of agentic vulnerability disclosures — GitLost joins named findings like GrafanaGhost, DockerDash, Context Crush, GeminiJack. Pattern: trusted automation + untrusted content + overbroad tools = exfiltration.
If you evaluated GitHub Agentic Workflows for your org after the launch marketing, GitLost is the red-team result you should have run internally first.
What GitHub Users Should Do Now
If you use Agentic Workflows today:
- Inventory workflows with AI agents — list triggers and permission scopes
- Kill cross-repo private read on any workflow triggered by public issue/PR events
- Separate agents — public-support bot (no secrets) vs internal automation (no public triggers)
- Review comment/post tools — can the agent write externally visible content autonomously?
- Watch GitHub security advisories — disclosure acknowledged; verify remediation on your org
If you do not use Agentic Workflows yet:
- Treat GitLost as the canonical "do not ship this pattern" example
- Any future agent that reads GitHub issues and touches private repos needs hard scoping, not prompt guardrails
Honest Limits of This Post
- Noma's post does not publish a CVE, patch date, or GitHub official advisory link
- PoC used a research org (
sasinomalabs) — real-world exploitability depends on how many orgs enabled the dangerous permission combo - "Additionally" may be patched or model-version-specific — attackers iterate phrasing continuously
- This is not a git protocol flaw — the name GitLost refers to GitHub's agent, not git itself (HN: should have been "HubLost")
The Bottom Line
GitLost proves that GitHub Agentic Workflows can turn a public issue into a private repo leak when agents combine cross-org read access with autonomous public commenting — and that prompt guardrails alone will not save you.
The fix is architectural: least privilege, input isolation, output control — the same primitives we apply to SQL, CI secrets, and MCP deployments, now mandatory for any agent reading user-generated platform content.
If your organization's AI strategy includes "let the agent handle GitHub," GitLost is the case study to put in front of security review before you enable it on production orgs.
Update — July 15, 2026: Claude Memory Heist — Ayush Paul exfiltrated claude.ai memory (name, employer, hometown) via web_fetch alphabetical URL paths and a fake Cloudflare Turnstile; user only asked about coffee.
Related on explainx.ai
- Claude Memory Heist: web_fetch PII Exfiltration — claude.ai memory + browsing (July 2026)
- MCP Security Guide 2026 — prompt injection, confused deputy, least privilege
- What Is an AI Jailbreak? — guardrail bypass mechanics
- Claude Code Permission Modes Explained — tool approval vs bypass
- What Is a System Prompt? — trust boundaries in agent design
- OpenAI Deployment Simulation — pre-release behavior prediction
- Claude Code Security Guidance Plugin — agentic security patterns
- Agent Skills Security Threat Model — supply chain for SKILL.md
- Nvidia SkillSpector Agent Scanner — automated skill auditing
- System Prompt Leaks on GitHub — why instructions escape
- Terminator 2 and AI Safety Culture — governance narrative context
Sources: Noma Security — GitLost (July 6, 2026); Simon Willison lethal trifecta (June 2025).
Disclosure status and GitHub remediation reflect Noma's publication as of July 8, 2026. Verify current GitHub Agentic Workflows security guidance before production use.