26,400 Live Cloud and AI Keys Found in Public Gitee Repos: What Coding-Agent Users Should Check

A scan of 7,256,531 public repositories on Gitee, China's largest Git hosting platform, found 26,400 credentials that still worked when tested, many of them cloud and AI provider keys. The work is by independent researcher Ben Zimmermann, published on October 28 on MongoDB's engineering blog with the Kingfisher team. If you run coding agents, the useful takeaway is not about Gitee: any key that has ever been committed to a public repository, by you or by an agent working for you, should be treated as burned. This post covers the method, the numbers, what is and is not established, and what to check.

The research does not mention AI coding agents. We are not claiming agents caused these leaks; the connection is that agents write and commit files, and AI provider keys were a large share of what was found.

TL;DR

What the researcher did

Zimmermann describes the scan in his write-up. Gitee's official REST API was too limited to list every repository, so he combined several sources: prefix queries against the user-search endpoint, the public Explore feed, follower and stargazer lists, per-user project pages, and an internal search widget that backs Gitee's on-site search. That produced 1,704,759 usernames and 7,256,531 unique repositories. He notes that the widget capped results at 200 per query and that a large fraction of the platform sits outside the social graph, so the repository count is a working set, not a verified census of Gitee.

Each repository was bare-cloned and scanned by two tools at once: TruffleHog with --only-verified, and Kingfisher with --only-valid. Both try a candidate secret against the service that issued it and keep only those that authenticate. A string that merely looks like a key but fails is discarded. The scan ran on Modal's serverless platform for roughly a month and cost $3,097.64, covered by a compute-credit sponsorship.

The numbers

Of the 26,400 unique credentials (deduplicated by raw secret value), TruffleHog found 12,737 and Kingfisher 14,664; only 1,001 were caught by both. The write-up says either scanner alone would have caught about half. The provider breakdown it states:

A long tail of other vendors, including LangSmith, OpenRouter, Stripe, Slack and MySQL, is named without counts. The write-up also reports an active organization-admin credential for a major enterprise AI platform, which it does not name.

By commit year, 12,242 of the credentials date from 2025, nearly half the total, so this is not only old, abandoned code. Most committers used personal email providers, so attribution to companies is a floor: the write-up lists a handful of corporate domains, including Huawei, Microsoft and ByteDance, with counts in the tens.

For scale, the author compares verified-live credentials per 1,000 repositories: Bitbucket 2.39, GitLab 3.11 and Gitee 3.64. He flags that the GitLab and Bitbucket baselines used TruffleHog alone; on the same basis Gitee comes to 1.76 per 1,000. The comparison is therefore not like for like, and the headline "Gitee is worse" is weaker than it looks.

What is claimed, and what is verified

• Verified by the scanners: each of the 26,400 credentials authenticated against its provider at scan time. That is stronger than pattern matching.
• Not published: the dates each key was tested, so how stale the "live" status is cannot be read from the report.
• Not confirmed: revocation. The author emailed the vendors with the highest exposure, giving each a list of its verified-live credentials with source-repository metadata, but did not notify individual developers and says revocation had not been confirmed.
• Not measured: whether anyone used the keys. Nothing in the report says they were abused.
• Not independently reproduced: we did not rerun the scan, and the numbers here are the author's.

The mechanism is ordinary, which is the point. Nobody exploited anything. Keys sat in public history and any party who cloned the repositories could have tested them the same way.

What developers are saying

The Hacker News thread was short. One commenter, dorianmariecom, said the same thing happens on GitHub and GitLab. gosen said they were surprised the gap to GitLab was that small, expecting Gitee to be much worse without any scanning partnerships, and wanted GitHub in the comparison table to see how much push protection changes the rate. nitroedge asked what happens to people who use leaked keys for free AI access; that is a question, not a finding. These are individual commenters' views, not established facts.

Why AI keys in git history are costly

An exposed cloud or AI key is not a data leak you can shrug off. A working inference key lets a stranger spend your money, and the pattern of attackers hunting for such keys is documented elsewhere: see how LLMjacking turned a Gemini API key into a billing hijack and how exposed AI endpoints are scanned and resold. Our guide to how API keys leak through logs and environment variables covers the rotation order that applies here too.

Git history makes it worse. Removing a key in a later commit changes the current file, not the object store. Anyone who clones the repository, including a scanner, gets every earlier version. The write-up's scan counted keys that developers later deleted for exactly this reason.

What this means if you run AI coding agents

A coding agent that edits files, runs commands and commits has the same opportunity to leak a key as a hurried developer. Typical routes, none of which this research measured, are an .env file staged by git add -A, a key pasted into a config or test fixture to make something run, and a .env.example filled with real values. Reasonable checks:

1. Scan your history, not just your working tree. Run a verifying, history-aware scanner such as Kingfisher or TruffleHog over every repository you have pushed to, public or not, and every branch. Read each tool's own documentation for the exact command; do not rely on the one-line examples in this post.
2. Revoke at the provider. Replacing the key in your code is not enough. Revoke the old key in the provider console, issue a new one, and check the provider's usage logs for activity you do not recognize. For ordering, rotate whatever can spend money or reach customer data first.
3. Do not rely on rewriting history alone. Force-pushing a cleaned history does not recall copies already cloned or cached. Revocation is the fix; history rewriting is hygiene.
4. Keep keys out of the agent's reach. Prefer scoped, short-lived credentials and a secret manager over long-lived keys in project files. A key the agent never sees cannot be committed by it.
5. Turn on push protection and pre-commit scanning. The HN discussion raised the open question of how much host-side push protection changes the leak rate; the Gitee report cannot answer it, but blocking a verified key at push time is cheaper than rotating it afterwards.
6. Review what the agent is about to commit. Look at git diff --staged before an agent-authored commit is pushed, especially on a new repository.

What Beam can and cannot do here

Beam is not a git-history scanner, and we would not present it as one. What it does, per its documentation: it watches the actions Claude Code, Codex and similar agents take, and the collector redacts known credential formats, assignments, authorization headers, URL query strings and private keys before persistence. It has a secrets rule category, and a credential read followed by network activity in the same session can produce a composite finding. Where a Claude Code or Codex PreToolUse hook is installed and the workspace policy is set to enforce, Beam can deny a flagged tool call. See how to stop Claude Code from running dangerous commands and vibe-coding safely with Beam.

The limits matter. Redaction is pattern-based and not a complete classification of confidential data. Deny is hook-based, not a kernel sandbox, and fails open if no cached policy is available. Beam does not verify whether a key is live, does not audit repositories you already pushed, and does not replace Kingfisher, TruffleHog or your host's push protection. Use them together.

Related reading

• Railway breach: environment variables, AI keys and what to rotate
• Infostealer targeting Claude Code, Codex and Cursor credentials
• Wiz: LLMjacking and a GCP billing account hijack
• Primary sources: the MongoDB write-up, the Kingfisher repository and the TruffleHog repository.

Frequently asked questions

What did the Gitee credential scan find?

Researcher Ben Zimmermann scanned 7,256,531 public Gitee repositories with TruffleHog and Kingfisher and found 26,400 unique credentials that still authenticated against the issuing service when tested. The largest groups were 9,473 Alibaba Cloud AccessKey pairs, 3,805 YouTube API keys and 3,170 DeepSeek keys.

Does this mean those keys are still valid today?

Not necessarily. Each key worked when the scanners tested it, but the test dates were not published and, at publication, the researcher had not confirmed that any had been revoked. Treat the figure as live at scan time, not live now.

Does deleting a key from the latest commit fix the leak?

No. Both scanners read full commit history, so a key removed from a later version of a file was still found and counted. A credential that was ever committed to a public repository should be revoked at the provider and replaced.

Is this a coding-agent problem?

The research does not mention coding agents and does not say agents caused these leaks. It matters to agent users because an agent that writes, stages and commits files can put a key into history just as a person can, and AI provider keys were a large share of the findings.

How do I check my own repositories for committed keys?

Run a history-aware secret scanner that verifies findings, such as Kingfisher or TruffleHog, over every branch of every repository you push to, then revoke anything that verifies. Add pre-commit scanning and your host push protection so new keys are caught before they reach a remote.

Can Beam stop an agent from committing a key?

Not specifically. Beam redacts recognized secrets before storing events and its rules can flag credential reads followed by network activity, and hook-based deny applies to Claude Code and Codex. It does not scan your git history and is not a replacement for a secret scanner.

Figures come from the researcher's October 28, 2026 publication and may change if the author updates it or vendors report revocations. Beam is a local prototype; features described are accurate as of the publication date.