API key leak prevention: how to keep secrets out of your code

An API key is a bearer credential: whoever holds it can act as you. That is what makes a leaked key so dangerous and why API key leak prevention has become a core discipline of modern software security. A single exposed key can grant an attacker access to your production database, your cloud account, your email provider, or your AI billing, no password required.

The problem continues to grow. GitGuardian's State of Secrets Sprawl 2026 report found that more than 28.6 million new hardcoded secrets were pushed to public GitHub in 2025 alone, a 34% increase over the previous year and the largest annual rise the report has recorded. The fastest-growing category was AI-service credentials, up roughly 81% year over year.¹ Keys are being exposed faster than teams can rotate them.

This guide explains why API keys leak, what a leak actually costs, and, most importantly, the layered set of practices that prevent leaks in the first place. It is written to be vendor-neutral; where a specific tool is named, it is offered as an illustration of a category, not a recommendation to the exclusion of others.

What counts as an API key leak?#

An API key leak is any situation where a credential (an API key, access token, OAuth secret, SSH private key, database connection string, or signing key) becomes readable by someone who should not have it. The classic case is a key hardcoded into source code and committed to a repository, but exposure happens in many other places: configuration files, container image layers, CI/CD logs, error messages, client-side JavaScript bundles, chat messages, support tickets, and shared documentation.

Two properties make leaks especially costly. First, exposure is often silent: a key can remain in a public commit for weeks before anyone notices. Second, exposure is frequently permanent: removing a secret from your latest commit does not remove it from Git history, and anyone with a clone of the repository can still retrieve it. Once a credential has been public, the only safe assumption is that it is compromised.

Why API keys leak#

Most leaks are not the result of sophisticated attacks. They are ordinary mistakes made under time pressure, multiplied across large teams and fast-moving codebases. The common causes fall into a handful of patterns.

Hardcoding for convenience. A developer places a key directly into the code "just to test it," intends to remove it later, and forgets. The key is then released with the rest of the code.

Committed configuration files. A .env file or config.json containing live credentials gets committed because it was never added to .gitignore, or because a teammate cloned the project before the ignore rule existed.

Git history. Even disciplined teams that remove a secret in a follow-up commit often leave it intact in history. Every clone carries the full record, so the secret remains retrievable indefinitely unless history is rewritten and the key is rotated.

Leaks outside the repository. GitGuardian's research indicates that roughly 28% of credential incidents originate entirely outside code repositories, in Slack messages, Jira tickets, Confluence pages, Docker Hub images, and pasted snippets on code-formatting sites.¹ Secrets spread far beyond git.

Client-side exposure. Keys embedded in front-end code are shipped to every visitor's browser. A 2025 Truffle Security scan of Common Crawl, a public archive of the web, found nearly 12,000 live credentials hardcoded in public web pages.⁷ Anything that runs on the client cannot be kept secret.

AI-assisted development. This is the fastest-rising vector. AI coding assistants generate working code that frequently includes hardcoded credentials, and they do so quickly. GitGuardian found that AI-assisted commits leak secrets at roughly twice the baseline rate of human-written code.¹ The spread of the Model Context Protocol (MCP) has added a new surface: researchers identified more than 24,000 secrets in MCP configuration files on public GitHub¹, often because official quickstart examples show keys hardcoded directly into config, and developers copy the pattern. Security researchers at Wiz reported that 65% of the companies on the Forbes AI 50 list had leaked verified secrets on GitHub², evidence that even sophisticated organizations are not immune.

What a leak actually costs#

The consequences of a leaked key scale with the key's privileges, and the window of exposure is rarely short.

• Credentials are a leading breach vector. The 2025 Verizon Data Breach Investigations Report cites the use of stolen or compromised credentials as the initial entry point in roughly one in five breaches, placing it among the top two attack vectors alongside vulnerability exploitation.³
• The financial impact is significant. IBM's Cost of a Data Breach Report 2025 put the global average cost of a breach at about $4.44 million.⁴
• Exposure windows are long. Industry analyses repeatedly show that a large share of leaked credentials remain valid long after they were exposed because no one rotates or revokes them. A key that nobody retires stays usable by anyone who has it.
• Attackers act quickly. Sysdig's threat research has documented AI-assisted intrusions escalating from a single leaked credential to full cloud-administrator access in a matter of minutes.⁵ The time between exposure and exploitation is shrinking.

Beyond direct costs, a leaked key for a metered service (an AI model provider, an email API, a maps service) can be abused to run up enormous bills or to send spam and abuse traffic under your identity.

The layered defense: how to prevent API key leaks#

Effective prevention is not a single control. It is a series of overlapping layers, each of which catches what the previous one missed. The strongest programs proceed in order: reduce the number of secrets that exist, keep the remaining ones out of code, catch any that get through before they are released, and assume some will escape anyway.

Layer 1: Don't create a long-lived secret if you can avoid it#

The most reliable way to prevent a leak is to have nothing to leak. Where your platform supports it, replace static, long-lived API keys with short-lived, automatically expiring credentials:

• Workload identity federation and cloud IAM roles let services authenticate using short-lived tokens issued at runtime, eliminating the need to store a static key at all. AWS STS, Google Cloud service-account credentials, and Azure Managed Identities all follow this model.
• OAuth 2.0 / OAuth 2.1 with scoped, delegated access is the preferred pattern for SaaS integrations.
• Dynamic secrets, generated on demand and invalidated when the workload ends, give an effective lifetime close to zero.

The OWASP Non-Human Identities Top 10⁸ lists secret leakage as a primary risk and recommends ephemeral credentials as the primary defense. You cannot leak a secret that does not exist.

Layer 2: Keep secrets out of source code#

When you do need a static credential, it should never appear in source files, configuration committed to version control, or CI manifests.

• Use a secrets manager. HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, and Azure Key Vault store credentials separately from code and supply them at runtime. Your code references a key by name; the value never touches a source file. Vaults also provide audit logging, automated rotation, and instant revocation.
• Use environment variables as a baseline. If a managed vault is not available, environment variables are far better than hardcoding, provided the files that hold them (.env, local.settings.json) are reliably git-ignored.
• Never commit credential files. Establish .gitignore rules at project creation, not after the first leak.

Layer 3: Enforce least privilege and scope every key#

Assume any key may eventually leak, and limit the damage in advance. Follow the principle of least privilege: a key should carry only the permissions it strictly needs. Issue a separate key per application and per environment (development, staging, production), and prefer per-service or per-agent identities over shared credentials. Shared keys remove attribution and make incident response far harder. Restricting scope limits the damage from any single exposure.

Layer 4: Rotate and retire keys on a schedule#

Long-lived credentials that nobody retires are responsible for many of the most damaging breaches. Define a maximum lifetime for every secret type, rotate high-privilege keys most aggressively, and automate the process so it actually happens. Test your rotation procedure in staging before you need it under incident pressure, and document a clear revocation path for every credential type so a compromised key can be invalidated immediately.

Layer 5: Treat AI coding assistants, and their plugins, as untrusted with secrets#

AI coding assistants are now a core part of the toolchain, and they introduce two risks beyond the hardcoded credentials they sometimes generate. Both are best handled as deliberate policy rather than left to individual habit.

Never hand a raw secret to an AI tool. Pasting a live API key into an assistant's chat window, settings panel, or prompt sends that credential off your machine, often into a third party's logs or processing pipeline. Route the assistant's model access through an environment variable or a server-side proxy instead, so the key value never appears in a prompt or a plugin's configuration. The risk is not hypothetical. In June 2026, security firm Aikido documented a coordinated campaign of at least 15 JetBrains Marketplace plugins, collectively installed close to 70,000 times, that posed as AI coding assistants and silently exfiltrated the provider API key each user pasted into the plugin's settings, sending it to an attacker-controlled server.⁶ The plugins worked exactly as advertised, which is precisely why the theft went unnoticed; some versions even resold the stolen keys back to other paying users.

Vet plugins and extensions like any dependency. An IDE plugin runs unsandboxed inside the editor, with access to your source code, cloud credentials, and signing keys. Marketplace review is not a guarantee: malicious logic can hide inside an otherwise functional plugin. Install AI tooling only from vendors you have reason to trust, prefer official or widely audited extensions, and apply the same scrutiny you would give a library you add to production.

Restrict what the assistant is allowed to read. An agent that can read your entire working tree can also read your .env file, your cloud credential files, and your private keys, and then echo their contents into a chat reply, a commit message, or a file it writes elsewhere. Apply a least-context principle: exclude secret-bearing files from the assistant's reach using its ignore configuration (for example, agent-level ignore files), keep credentials out of the project directory where possible, and never point an assistant at sensitive locations such as ~/.aws or ~/.ssh. The less sensitive material an assistant can see, the less it can leak.

Because assistants will still occasionally emit a hardcoded key despite these controls, scanning their output before it reaches disk, covered next, remains the final safeguard.

Layer 6: Catch leaks before they ship#

Prevention controls reduce risk; they do not eliminate human error. The next layer is detection at the point of authorship, catching a secret on the developer's machine, before it ever reaches a remote repository.

The most effective scanning happens as early as possible in the workflow:

• In the editor and the AI assistant. Scanning code as it is written, including code generated by an AI assistant before it is saved to disk, closes the fastest-growing leak vector. Tools that integrate through an editor language server or an MCP server can surface a finding the moment a key appears.
• At commit time. A pre-commit hook inspects staged changes and aborts the commit if it finds a secret, stopping the leak before it enters Git history.
• In Git history itself. Because removing a secret from the latest commit does not erase it, a thorough scanner checks every commit on every branch using the same rules it applies to working files.

This local-first model is the design philosophy behind Trestle, a secret scanner that runs entirely on the developer's machine and plugs into editors, AI assistants, and the pre-commit hook, built for the reality that today's code is increasingly written with AI assistance and scraped from public commits within minutes of being pushed.⁹ It is one example of a broader category; the principle that matters is scan as early and as locally as possible.

Layer 7: Add a safety net in CI/CD#

Whatever runs locally can be bypassed, skipped, or run on a misconfigured machine. Run the same secret scanner again as a gate in the continuous-integration pipeline, where it cannot be skipped: it catches anything the local layer missed and can block a build or merge when a secret is detected. Most scanners that run locally also run in CI, applying the same rules in both places; Trestle, for example, provides a CI action alongside its editor and pre-commit integrations. Platform features such as push protection, which rejects pushes containing recognized provider patterns, add another safeguard, though they only catch credentials that match known formats and will miss custom or internal token types.

Layer 8: Monitor and detect in production#

Prevention is paired with detection. Monitor API key usage for anomalies: unexpected request volumes, unfamiliar source IPs, access at unusual times, or use of permissions a key has never exercised. Forward logs to a SIEM so unusual patterns trigger alerts. Anomalous usage is often the first sign that a key has leaked despite every upstream control.

How secret detection actually works#

Understanding the techniques behind secret scanning helps teams choose tools wisely and interpret findings correctly. Modern scanners combine several methods.

Pattern matching (regex). Many credentials have recognizable formats: an AWS access key begins with AKIA, a Stripe live key with sk_live_. Pattern matching reliably catches these known formats across enormous codebases.

Entropy analysis. Custom or internal tokens that match no known pattern can still be flagged by measuring randomness: high-entropy strings look statistically like generated secrets, even when the format is unfamiliar.

Context awareness. The most accurate scanners reduce false positives by examining what surrounds a candidate string: the variable name it is assigned to, whether it appears in a test fixture, whether a nearby comment marks it as an example. Some go further and parse the code with language-aware parsers rather than relying on regular expressions alone, so they can distinguish an environment variable from a build argument, an HTTP header from a source constant, and apply the right rule to each. This is the distinction between treating code as plain text and understanding its structure.

Live validation. A detected secret can be checked against its issuing provider to confirm whether it is still active. This separates a genuinely exploitable, valid credential from one that was already rotated, so teams can triage what matters first. Because validation requires network calls, privacy-conscious tools keep it separate from the offline core scanner.

A capable scanner also produces output in formats your pipeline can consume (JSON, SARIF, JUnit, CSV) and provides remediation guidance with each finding rather than leaving the developer to determine the fix.

What to do when a key leaks#

Even with strong prevention, leaks happen. A disciplined response limits the damage:

1. Treat it as compromised. If a secret was ever exposed, even briefly, even in a private repo, assume an attacker has it.
2. Rotate and revoke immediately. Issue a new credential and invalidate the old one. Rotation is the only action that genuinely closes the exposure; deleting the file does not.
3. Purge it from history if needed. For exposures in version control, rewriting history removes the artifact, but rotation comes first because the old key may already be copied.
4. Investigate usage. Check provider logs for unauthorized access during the exposure window.
5. Fix the root cause. Move the credential into a vault or environment variable, add the relevant .gitignore rule, and add a scanning gate so the same class of mistake is caught next time.

Tooling can shorten every step of this process. The most useful scanners pair each finding with concrete remediation: how to extract the secret from source, what to place in a local .env, and the platform-specific rotation steps for the deployment targets in the repository.

Building a prevention program that lasts#

No single control prevents API key leaks. The teams that succeed combine them: they minimize the number of static secrets, store the rest in managed vaults, scope and rotate aggressively, keep secrets out of the prompts and context they give AI assistants, scan locally before code leaves the machine, gate again in CI, and monitor production for abuse. They also treat it as a culture problem as much as a technical one: secure defaults in project templates, brief developer training, vetting of editor plugins, and scanning that runs quietly in the workflow rather than blocking it.

The economics favor prevention overwhelmingly. Catching a secret in a pre-commit hook costs a developer seconds. Rotating a credential after it has been scraped from a public commit, abused, and turned into a breach can cost millions. As AI accelerates how fast code is written, and how fast it leaks, the case for catching secrets at the moment of authorship has only grown stronger.

Frequently asked questions#

What is the difference between an API key leak and a data breach?#

An API key leak is the exposure of a credential. A data breach is the unauthorized access to data that often follows. A leaked key is a common cause of a breach, but a leak that is caught and rotated quickly need not become one.

Does deleting a secret from my code fix the leak?#

No. Deleting it from the current version does not remove it from Git history, and it does nothing about copies attackers may already hold. You must rotate and revoke the credential, then optionally purge it from history.

Are environment variables enough to prevent leaks?#

They are a meaningful improvement over hardcoding, but not a complete solution. Environment variables can still leak through logs, error messages, build artifacts, or a committed .env file. A managed secrets vault, combined with scanning, is stronger.

Why do AI coding assistants increase the risk?#

There are two effects. First, assistants generate working code quickly, and that code often includes hardcoded credentials, so secrets are introduced faster than manual review can catch them. Second, you can leak a secret to the assistant directly, by pasting a key into it or letting it read a credential file. Scanning AI output before it is written to disk addresses the first; the practices in this guide address the second.

Is it safe to paste my API key into an AI coding assistant?#

Treat it as unsafe by default. Pasting a live key into a chat, prompt, or plugin settings panel sends the credential off your machine. A 2026 Aikido investigation found a group of JetBrains Marketplace plugins, installed tens of thousands of times, that posed as AI assistants and exfiltrated exactly these pasted keys. Instead, supply the assistant's model access through an environment variable or a server-side proxy, vet any plugin before installing it, and rotate immediately if you suspect a key reached a tool you did not intend.

Should I let an AI assistant read my whole project?#

No, apply a least-context principle. An assistant that can read your working tree can read .env files, cloud credentials, and private keys, then reproduce them in a reply, a commit, or a generated file. Exclude secret-bearing files using the tool's ignore configuration, keep credentials out of the project directory where possible, and never point an assistant at locations like ~/.aws or ~/.ssh.

How often should API keys be rotated?#

Rotation frequency should match privilege and risk. High-privilege keys warrant aggressive, automated rotation; lower-risk keys can rotate less often. The ideal is to avoid long-lived static keys entirely in favor of short-lived, dynamically issued credentials.

Where should secret scanning run?#

At multiple points: in the editor or AI assistant as code is written, as a pre-commit hook before code enters history, and again in the CI/CD pipeline as a final safeguard. Scanning Git history catches secrets that were committed before scanning was in place.

Sources#

1. GitGuardian, State of Secrets Sprawl 2026
2. Wiz, State of Code Security 2025; Wiz threat research on the Forbes AI 50
3. Verizon, Data Breach Investigations Report 2025
4. IBM, Cost of a Data Breach Report 2025
5. Sysdig Threat Research Team, AI-assisted cloud intrusion analysis, 2026
6. Aikido Security, "Multiple JetBrains IDE plugins caught stealing AI keys," June 2026
7. Truffle Security, Common Crawl secret analysis, 2025
8. OWASP, Secrets Management Cheat Sheet and Non-Human Identities Top 10 (2025)
9. Comparitech, GitHub credential honeypot experiment, 2022