OSINT Exposure Risks for Published API Credentials

A key sitting in a git commit is a bug. A key sitting in a git commit that anyone can find in five minutes with a browser and a search bar is a live incident, whether or not anyone knows it yet. That gap, between "leaked" and "discoverable," is the whole story here, and it is the piece of the puzzle most security conversations skip past on the way to talking about firewalls.

API credentials deserve their own category of worry. Unlike a password tied to a login page with rate limits and maybe two-factor prompts, an API key usually just works. It authenticates the request, carries its permissions baked in, and hands over access to production data or some downstream service with zero follow-up questions. No second check. And most of these keys do not end up public because someone did something reckless. They end up public because a developer was testing something locally, spinning up a prototype, or copying a code example straight from documentation, real key and all.

How Large the Exposed Credential Surface Is Now

The numbers for 2025 are not subtle. GitGuardian's State of Secrets Sprawl 2026 report counted 28,649,024 new secrets exposed in public GitHub commits across the year, a 34% jump from the year before, representing the largest annual increase in the report's tracking history. GitHub ran its own sweep across the whole platform, not just public commits, and turned up more than 39 million leaked secrets in 2024 alone. Different measuring stick, same direction of travel.

The AI angle is where it gets interesting. Secrets tied to AI services hit 1,275,105 in 2025, up 81% year over year, and eight of the ten fastest-growing categories of leaked credentials were tied to that same kind of technology. One layer deeper and the pattern sharpens further: the plumbing around AI models, including orchestration tools, retrieval systems, and vector databases, leaked secrets five times faster than the model providers themselves. The tooling layer, not the flashy model layer, is where the exposure is actually accelerating.

AI Coding Tools Are Making Leaks Worse

Commits assisted by Claude Code showed a 3.2% secret-leak rate, more than double the 1.5% baseline across all public GitHub commits. The mechanism is not mysterious once you think about how these tools get used day to day. AI-generated code looks finished before it actually is. A developer scaffolds an integration, wires up a test call, sees it work, and commits it, with credential hygiene being the task that was supposed to happen later.

MCP configuration files are a clean example of this playing out at scale. GitGuardian found 24,008 unique secrets sitting in MCP-related config files on public GitHub, and 2,117 of them are still valid right now. Trace the root cause and the answer is almost darkly funny: the official MCP quickstart documentation shows API keys hardcoded directly into example config files. Developers follow the doc, swap the placeholder for their real key to get it running, and then commit the file exactly as shown. That is following instructions, not carelessness.

What Attackers Actually Do to Find Keys

OSINT, open-source intelligence, means collecting and analyzing information anyone can already see. Attackers and defenders draw from the identical well: same search engines, same public repos, same tools.

GitHub dorking is the entry-level version of this and it takes almost no skill. Search GitHub for "password," "token," "api_key," or "secret" and you will get hits. "AKIA" extension:pem finds AWS keys sitting inside PEM files, "AWS_ACCESS_KEY_ID" filename:credentials does what it says, and "BEGIN OPENSSH PRIVATE KEY" filename:id_rsa finds private remote-login keys committed in plain sight. None of this requires special access. Any GitHub account, free tier included, can run these searches over coffee.

Beyond manual searching, there is a whole automated layer. TruffleHog scans git repositories, including their full commit history, hunting for high-entropy strings and known secret patterns, and paired with dumped .git data it can dig up credentials buried in commits from years ago that nobody remembers making. GitLeaks does similar pattern-matching work. Shodan and Censys round things out by scanning the entire internet for exposed services and default configs, which is how an attacker figures out what a stolen key actually unlocks once they have it.

AI infrastructure gets its own dedicated toolkits now. Researchers using these methods have documented over 187,000 exposed Ollama servers and more than 370,000 indexed Grok conversations sitting in the open. Leaked API keys have been catalogued across OpenAI, Anthropic, Google Gemini, HuggingFace, Groq, Replicate, Cohere, Mistral, DeepSeek, and ElevenLabs. That is not a niche hobby anymore; it is a catalogue.

Stolen Credentials Get Abused in Minutes

Speed should keep people up at night. Exposed AWS credentials get probed by attackers in under 17 minutes on average, and sometimes in as little as 9. That is not a typo, and it is not a window measured in days or even hours. It is measured in the time it takes to finish a cup of coffee.

The sequence tends to run the same way. A scanner spots the credential in a public commit or config file. Something, human or automated, tests the key against the actual API to see if it is live. If it works, the next step is mapping out what it can touch: what permissions it carries, what data it reaches, and whether it opens a path sideways into other systems. If that key happens to control an automation platform that aggregates credentials across AWS, Azure, GitHub, Slack, and internal databases, a single find stops being a single find. It becomes a master key.

That is the scenario that turns a bad afternoon into a bad quarter. Lateral movement through a credential aggregator can force an organization into rotating hundreds of API keys and OAuth tokens across dozens of connected services, all at once, under pressure.

The supply-chain version of this is worse. In the LiteLLM and TeamPCP incident, attackers first compromised the CI/CD pipeline of Trivy, a widely used open-source vulnerability scanner. That access let them steal LiteLLM's publishing credentials. By August 2026, a 153 GB dataset of stolen credentials tied to more than 2,000 organizations had surfaced. One pipeline, thousands of victims downstream.

Even Top Companies Fail at This

Money and security maturity do not seem to fix this on their own. Wiz's research looked at the Forbes AI 50, arguably the best-funded, most security-conscious companies in tech, and found that 65% of them had confirmed secret leaks on GitHub. The median time to fix one was 94 days.

A few incidents make the abstract numbers land. A developer at the Department of Government Efficiency published a private API key for xAI's language models on GitHub, embedded inside a script called agent.py, and it granted access to more than 50 xAI large language models. Nobody inside caught it; GitGuardian did. The US Treasury breach traced back to one leaked API key for BeyondTrust's Remote Support SaaS platform, a single credential behind a genuinely significant government breach. Two GitHub Actions maintained by Checkmarx were also compromised when threat actors injected credential-stealing malware into them, harvesting cloud, GitHub, and CI/CD secrets from every workflow that touched them.

Finding Keys Is Easier Than Revoking Them

64% of secrets discovered back in 2022 were still active and exploitable four years later, in January 2026. That is not a detection problem. Detection is clearly working, as GitGuardian and others keep finding these things. It is a remediation problem, plain and simple.

The organizational data backs this up. Many organizations take weeks or longer to revoke an exposed API key, and few have a formal process for revocation. GitGuardian's breakdown of policy violations shows why: long-lived secrets, keys that never expire, are a leading category. Internally leaked secrets and duplicated secrets account for significant shares of the remainder. None of that is exotic. It is ordinary key longevity, left unmanaged, for years.

Revocation stalls out for a few consistent reasons. Ownership is usually murky, since nobody is quite sure who issued the key, who is actively using it, or what breaks downstream if it gets rotated. There is real fear of breaking production, because keys accumulate undocumented dependencies across services over time. Most organizations never wrote a revocation runbook, so every incident gets improvised from scratch under pressure. And even after the live key gets killed, it is still sitting in git history, fully scannable, forever, unless someone actively scrubs it out.

Run the Attacker's Searches Before They Do

The starting insight is almost embarrassingly simple: attackers see what is public before defenders ever do. So the first move is running the same searches against your own organization that an attacker would run, before they get the chance to.

A proper credential-focused OSINT sweep needs real scope. That means every public repository on GitHub, GitLab, and Bitbucket, including forks and repos that got archived and forgotten. It means Docker Hub images, CI/CD pipeline logs, public documentation and quickstart guides, and any collaboration tool exports that might have leaked outside the company by accident. On the tooling side, TruffleHog and GitLeaks handle repository history, Shodan and Censys map exposed services tied to those credentials, and dark web monitoring services like SpyCloud or Hudson Rock catch credentials already being traded. Hudson Rock alone has analyzed data pulled from more than 30 million infostealer-infected machines.

This cannot be a once-a-year audit. Public exposure shifts constantly with new employee accounts, new leaks, and new services deployed on a Tuesday afternoon. A scan from six months ago is basically ancient history by the time anyone reads the report.

Certificate transparency logs are one underused signal. These are public, real-time records of every TLS certificate issued anywhere, and they end up accidentally revealing internal hostnames tied to the services a given API key controls. Defenders can read these same logs to map their own blast radius before anyone else does it for them.

When a scan turns up a pile of exposed credentials, fixing them in the wrong order leaves the highest-risk credentials exposed longer. Executive and high-privilege credentials get fixed first, then production service keys, then internal tooling keys. Not alphabetically, and not in whatever order the scanner happened to spit them out. Priority by damage potential, every time.