HN Debrief

GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos

  • AI
  • Security
  • Developer Tools
  • Open Source

The post describes a prompt injection against GitHub Agentic Workflows. Noma set up a workflow that read public issue text, had permission to read other repos in the organization including private ones, and could post a public reply. With that configuration, they got the agent to pull code from a private repo and publish it into a public comment. People largely agreed the exploit itself is unsurprising. If you let an LLM ingest untrusted public input, touch sensitive data, and write to a public channel, you have built an exfiltration path. What people zeroed in on was where the failure actually sits. Many rejected the article’s comparison to SQL injection as too optimistic. SQL injection became broadly manageable once code and data were cleanly separated with parameter binding. Prompt injection is harder because natural language is the instruction medium. There is no equivalent prepared statement for a general-purpose agent today.

Treat any AI agent as an untrusted operator with whatever permissions and output channels you gave it. If you are deploying agents against code, tighten scopes to the active repo or user, block risky public write paths, and assume prompt-level guardrails will fail.

Discussion mood

Mostly negative and impatient. People were not shocked that the leak worked. They were annoyed that broad agent permissions, public triggers, and prompt-based guardrails made it into a product flow that handles private code.

Key insights

  1. 01

    Decompose tasks before exposing shared context

    Breaking work into smaller deterministic stages is the closest thing to damage control when an agent must read untrusted material. One example was summarizing each source separately into constrained fields before doing any cross-document comparison. Another was an SQL setup with a low-privilege pool limited to views with sensitive columns removed, plus a separate high-privilege path that only runs predefined parameterized queries. The point is not that prompt injection disappears. It is that you stop one poisoned input from contaminating a broader reasoning step with access to everything.

    Split agent workflows into narrow stages with filtered intermediate outputs. If a step needs broad context, make the previous step collapse raw input into a safer representation first.

      Attribution:
    • moron4hire #1
    • lmz #1
    • vidarh #1
    • exabrial #1
  2. 02

    Prompt-injection defenses can reduce risk, not eliminate it

    Explicitly marking untrusted input, capping length, prefiltering prompts, and auditing outputs can make attacks harder. One commenter said boundary markers helped in practice. Another pointed to Anthropic's J-space example where a model appeared to recognize fabricated search results as an injection attempt. That is useful as friction, but nobody treated it as a hard boundary. The gap from 'often resists' to 'cannot be tricked' is exactly where security incidents live.

    Use model-side detection and filtering as one layer only. Keep those controls, but design the system so a bypass becomes an error or denial, not a leak.

      Attribution:
    • wongarsu #1
    • user43928 #1
  3. 03

    GitHub’s control surface is still awkward

    A few commenters said the secure design is obvious in theory but clumsy in GitHub today. Fine-grained tokens do not cover the full API, which pushes teams back toward broader personal or app tokens. GitHub does have a cross-repository restriction setting for agentic workflows, and native tokens can sometimes avoid the issue, but the existence of workarounds did not reassure people. The practical complaint was that safe scoping is not the path of least resistance.

    Audit your GitHub agent setup for hidden fallbacks to broad tokens and cross-repo reads. If secure scoping takes custom glue or proxies, treat that as a product risk, not an implementation detail.

      Attribution:
    • hardsnow #1
    • philipp-gayret #1
    • jofzar #1
  4. 04

    Public write access is the final leak point

    Reading private data was only half the chain. The leak became real because the same workflow could publish a public comment. That shifted attention from 'can the agent see private repos' to 'what outbound channels can it write to after seeing them'. In other words, exfiltration control matters as much as read scope. A repo-limited reader is safer. A broadly scoped agent that can post to public surfaces is a disclosure machine waiting for the right input.

    Model every public comment, email, webhook, and ticket update as an exfiltration channel. Require extra review or policy checks before an agent can send externally visible output that might include sensitive context.

      Attribution:
    • gawkdev #1
    • pqdbr #1

Against the grain

  1. 01

    This looks more like a bad demo than a GitHub bug

    Several people thought the headline oversold what happened. Their view was that the researchers deliberately created the dangerous combination by granting cross-repo private access and letting public issue content drive the agent. In that framing, GitHub did not bypass its own permissions. The workflow owner handed the agent the keys and then proved it used them. That does not make the result harmless, but it changes who should own the fix.

    When evaluating agent security claims, separate platform bypasses from unsafe compositions enabled by the platform. The mitigation and vendor accountability are different in each case.

      Attribution:
    • jakewins #1 #2
    • dzikimarian #1
    • pojzon #1
  2. 02

    Treat prompt injection like social engineering

    A minority view said prompt injection is not a unique fatal flaw. It is closer to a human operator being manipulated. On that view, the answer is the same old playbook: least privilege, approvals for sensitive actions, and split control so no one actor can do catastrophic things alone. This does not solve every leak path, but it rejects the idea that agents are categorically unusable.

    If you need agents in production, borrow controls from human operations instead of waiting for a perfect model fix. Add approvals, separation of duties, and narrow credentials around the model.

      Attribution:
    • nradov #1 #2
  3. 03

    The useful end state may be narrower agents

    Some commenters did not buy the premise that agents must stay fully open-ended. They argued the winning use case may be natural-language navigation over tightly bounded capabilities. Others went further and said a successful agent prototype should eventually be converted into deterministic code. That is a very different product vision from the current 'give it broad tools and hope the guardrails hold' approach.

    Reserve general agents for low-stakes tasks. For repeatable internal workflows, treat the LLM as an interface layer or prototyping tool, then harden the path into conventional software.

      Attribution:
    • lubujackson #1
    • wwind123 #1
    • _blk #1

In plain english

J-space ↩
An Anthropic interpretability concept mentioned in the comments, used to inspect internal model representations related to deceptive or injected content.
LLM ↩
Large Language Model, a machine learning model trained on huge amounts of text to generate and analyze language.
parameter binding ↩
A database technique that sends query structure and user-supplied values separately so input cannot change the meaning of the query.
SQL injection ↩
A security flaw where untrusted input is treated as part of a database command, letting an attacker alter what the database executes.

Reference links

Background on prompt injection

  • The Lethal Trifecta
    Used to explain why combining untrusted input, private data, and tool access creates dangerous agent systems.

GitHub workflow and access-control references

Model safety and interpretability

Policy and training-data usage

Alternative code hosting tools

  • Forgejo
    Mentioned as a self-hosted Git platform alternative for people avoiding GitHub’s AI features.
  • Codey
    Brought up as a managed option in Europe, though described as expensive and lacking runners out of the box.

Analogies and side references