For years I have been having the same argument with development teams. I point out that API keys and credentials are sitting in the repository; the team points out the repository is private. Access is controlled, only vetted people can see it, and keeping keys in the codebase makes onboarding easier. The risk is theoretical, the convenience is real. I have lost that argument more often than I have won it. This week the theoretical showed up with a name. Researchers at Noma Labs demonstrated a flaw they call GitLost, targeting GitHub's Agentic Workflows — the setup where an AI agent (Claude or Copilot) acts on issues and PRs autonomously. The attack: open an issue in a company's public repo, write instructions to the agent in plain English. Their proof of concept posed as a request from a VP of sales and buried a question about a private repo's README in the ask. The agent read the private repo and posted its contents into the public thread. No stolen credentials. No compromised laptop. The agent already had access — the attacker just asked to borrow it. GitHub's guardrails were bypassed by adding a single word: "Additionally". At the time of writing there is no patch, and there may never be one, because prompt injection is not a bug in one product. It is a category of flaw, the SQL injection of this era. My take: the private repo was never a security boundary. It was an organisational one, and it held only as long as every reader of your code was a human you employed. Agents break that assumption. Anything an agent can read — issues, comments, dependency READMEs — can carry instructions, and the agent cannot reliably tell yours from an attacker's. If an agent has access to your private repos, treat everything in them as one well-crafted issue away from public. What to do about it is not exotic, and the excuses have now run out: Get secrets out of the codebase and into a proper secrets manager, injected at deploy time. If a key has ever been committed, it lives in git history — rotate it now, not during incident response. Scope agent tokens the way you would scope a junior hire, not with org-wide read access because it was easier. And take an inventory: in most organisations I work with, nobody can list what agents exist and what they can reach. The teams who told me "it's private, we're fine" were not reckless — they were trading on an assumption that held for fifteen years. That assumption is gone, and the tools we are all racing to adopt are the reason. Article: https://lnkd.in/dfFhzN5U Reach out if you want a full security audit of your teams! #cybersecurity #devsecops #ai #github
Julie Chasen
3w
That’s why I keep secrets locally only - in a .env file.
Thanks so much for sharing Sasi Levi's research from Noma Security's Noma Labs! https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/
Vijendra Malhotra The "organisational boundary" framing is exactly right — and it points at why the recommended fixes are necessary but not sufficient. Secrets managers and token scoping reduce blast radius. They don't fix the ingestion problem: the agent still can't tell the difference between an instruction from the operator and an instruction embedded in a public issue comment. The architectural fix is context provenance. If operator instructions come from a signed, declared manifest — verified before loading, bound to a specific serving endpoint — then arbitrary issue content is simply never loaded as authoritative context. Not because it's blocked at access control, but because it was never in scope to begin with. GitLost is prompt injection. But the root cause is that most agents have no way to ask: "was I supposed to know this?"