🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4 · Curated by Tom Hundley

64% of Leaked Secrets Still Work Years Later — And Yours Might Be One of Them

If you have ever committed an API key, password, or token to GitHub, assume it may still be valid until you revoke it. GitGuardian's State of Secrets Sprawl 2026 report says 64% of secrets leaked on GitHub in 2022 were still active in 2026. That is the real risk: not just new leaks, but old credentials quietly sitting in commit history, still able to open the door.

For most developers, especially newer AI-assisted builders, the urgent fix is simple: scan your repositories, revoke any exposed secrets, and move credentials out of source code. Deleting a file is not enough. Removing a line in a later commit is not enough. If the secret was committed, treat it as compromised.

This article focuses on the part many security writeups skip: the backlog of old secrets you forgot about.

Why Old Secrets Don't Die

TL;DR: Most API keys do not expire automatically, so a leaked key can remain usable for years unless you revoke or rotate it.

Think of a leaked API key like a lost house key. It does not stop working because time passed. It stops working only when the lock changes.

That is how many credentials behave. When you create a key for Stripe, OpenAI, Supabase, or another service, it often remains valid until you explicitly revoke it. Some platforms now support expiration policies or scoped, short-lived tokens, but indefinite validity is still common enough to be a real problem.

Here is why old leaks remain dangerous:

• Git preserves history. If a secret was committed, it may still exist in prior commits even after you delete the file or edit the line. Anyone with access to the repository history can potentially recover it. This is one reason exposed .git folders on servers are so dangerous.
• Public commits are scanned quickly. Security researchers and vendors have long documented that bots monitor public repositories for exposed credentials, often within minutes.
• Private repositories reduce exposure, but they do not make secrets safe. Internal repos can still leak through overbroad access, compromised accounts, CI logs, backups, forks, or accidental publication.

The result is a long tail of still-working credentials spread across old repositories and forgotten projects.

Why AI-Assisted Coding Can Increase Secret Exposure

TL;DR: AI coding tools can make secret leaks more likely when developers paste real credentials into prompts or accept generated code without checking how secrets are handled.

GitGuardian's 2026 report says AI-related secret incidents increased sharply, including an 81% surge in AI-service-related secrets. The broader lesson is not that AI tools are uniquely reckless. It is that they speed up coding, and speed often reduces review.

If you ask an assistant to "connect to my database" or "set up Stripe payments," the generated code may include placeholders, environment-variable patterns, or, in some cases, real credentials that you pasted into the chat or local context. That is especially risky for newer developers who may not recognize a live key in code.

For example:

const apiKey = process.env.OPENAI_API_KEY;

That pattern is usually fine.

This is not:

const apiKey = "sk-live-or-project-key-here";

The danger is not just the hardcoded string. It is the workflow around it: generate code, test quickly, commit everything, and move on.

I covered how AI coding assistants leak your API keys in more detail elsewhere. The short version is this: AI can accelerate good security habits or bad ones. If you do not review generated code for secrets, it will amplify mistakes.

Scenario	Leak Risk	Why
AI-generated code includes a real key	High	You may commit it without noticing
You store keys in .env but forget to ignore the file	High	The file can be committed with the rest of the project
You use environment variables and keep secret files out of Git	Lower	Secrets stay out of source files and commit history
You also rotate or revoke keys regularly	Lowest	Old leaks become less useful over time

Do This Now: Find and Revoke Old Secrets

TL;DR: Scan repository history, revoke every exposed credential you find, and move active secrets into environment-based storage.

Step 1: Scan Your Repositories

Start with GitHub's secret scanning features if they are available for your account or organization. GitHub offers secret scanning across several plan types, but exact coverage varies by repository type and provider pattern, so check your repository security settings rather than assuming it is enabled everywhere.

For local scanning, Gitleaks and TruffleHog are widely used open-source tools. Both can inspect Git history, not just the current working tree.

If the terminal feels intimidating, use your AI assistant to walk you through it. For example:

Prompt to Try

"I need to scan my project for accidentally committed secrets like API keys, passwords, and tokens. Can you help me install and run Gitleaks on my project folder? Give me the exact commands to run step by step, and explain what the output means. I'm on [Mac/Windows/Linux]."

Step 2: Revoke Exposed Credentials

For every real secret you find:

1. Go to the service dashboard.
2. Find the API key, token, or credential management page.
3. Revoke, disable, or delete the exposed credential.
4. Generate a replacement if you still need access.
5. Update your application to use the new value from a secure location.

If a secret was exposed publicly, do not assume it is safe because you saw no obvious abuse. Treat it as compromised.

Step 3: Move Secrets Out of Source Code

A .env file is one common way to keep secrets out of application code during local development. For example:

STRIPE_KEY=YOUR_NEW_KEY_HERE
OPENAI_KEY=YOUR_NEW_KEY_HERE
DATABASE_URL=YOUR_DATABASE_CONNECTION_STRING

Then make sure Git ignores that file:

.env

That said, .env files are a development convenience, not a complete secrets-management strategy. In production, use your hosting platform's environment-variable system or a dedicated secrets manager.

If you want help cleaning up an existing project, try this prompt:

"Help me move all hardcoded API keys and secrets in my project into environment variables. Then make sure .env is in my .gitignore file so it does not get committed to Git. Show me how to update my code to read from environment variables instead of hardcoded strings."

What Good Secret Hygiene Looks Like

TL;DR: Prevention is a workflow, not a single tool: keep secrets out of code, scan continuously, and prefer short-lived or scoped credentials where possible.

Once you clean up old leaks, put guardrails in place so you do not repeat the problem.

A practical baseline looks like this:

• Keep secrets out of source files and commit history.
• Add .env and similar secret files to .gitignore.
• Use pre-commit or CI scanning with tools like Gitleaks or platform-native secret scanning.
• Prefer scoped credentials with the minimum permissions required.
• Use short-lived tokens or expiration policies when the provider supports them.
• Revoke and replace credentials after any suspected exposure.
• Review AI-generated code before committing it.

If you are building quickly with AI tools, this matters even more. Fast iteration is useful, but security failures also scale with speed. That is why issues like GitHub runner compromise and accidental repository exposure tend to connect back to the same root cause: secrets handled casually.

Frequently Asked Questions

Q: How do I know whether an API key has already been stolen?

You usually cannot know for certain. Check provider logs for unusual requests, new IP addresses, unexpected charges, or actions your team did not perform. But if a real credential was exposed in a public repository, the safest assumption is that it was collected quickly by automated scanners.

Q: I deleted the file with the key. Isn't that enough?

No. Deleting a file in a later commit does not remove it from Git history. You can rewrite history with tools such as git filter-repo or BFG Repo-Cleaner, but even then you should still revoke the leaked credential because you cannot guarantee nobody copied it earlier.

Q: Are private GitHub repositories safe for storing secrets?

Safer than public repositories, yes. Safe enough for long-term secret storage, no. Private repos still expose secrets to anyone with repository access, and secrets can also leak through logs, forks, backups, screenshots, or compromised accounts.

Q: Do services like OpenAI or Stripe automatically expire old API keys?

Not always. Some providers support expiration, restricted scopes, or project-based keys, but many credentials remain valid until you revoke them. Check each provider's current key-management options rather than assuming expiration is automatic.

Q: What is the difference between a secret and an environment variable?

A secret is the sensitive value itself: an API key, password, token, or connection string. An environment variable is one way to supply that value to an application without hardcoding it in source code. The variable is the container; the secret is the thing being protected.

Key Takeaways

• GitGuardian reports that 64% of secrets leaked on GitHub in 2022 were still active in 2026.
• Deleting a file does not remove secrets from Git history.
• AI-assisted coding can increase leak risk when generated code is not reviewed carefully.
• .env files help in development, but production secrets belong in platform-managed environment settings or a secrets manager.
• The most important response to an exposed secret is revocation, not just deletion.

Conclusion

Old secrets are dangerous because they are easy to forget and often still valid. If you have ever committed a credential, the safest move is to assume it may still work until proven otherwise.

Today, pick one repository and scan it. If you find a live secret, revoke it immediately, replace it, and move it out of source control. If you want help building safer workflows around AI-assisted development, Elegant Software Solutions can help you put the right guardrails in place before a small mistake becomes a breach.