Written by Ruben Selby, founder and penetration tester at Wolfcore. Last reviewed 13 November 2026.

In one sentence: API key exposure is what happens when an API key, a password that lets software use a paid service, leaks, and anyone holding it can spend your money and read your data until you cancel it at the provider.

What it is

Applications use API keys, database passwords and tokens to talk to other services such as AI providers, payment systems and cloud storage. These are called secrets. They often sit in “environment variables”, settings attached to the running application, or in code, config files and build pipelines.

OWASP’s Secrets Management Cheat Sheet notes that many organisations have secrets hardcoded in source code in plaintext, and littered through configuration files. It also says that environment variables are generally accessible to all processes and may end up in logs or system dumps, so they are not recommended unless other methods are not possible.

How it works

How a key gets stolen, and what the thief does:

1. Where the key lives. In a hosting platform’s settings, a repository, a build log, a laptop file or a shared chat.
2. How it is reached. The place it lives is breached, a developer account is phished, or a file is published by mistake.
3. What the thief does. Searches for names that look like keys, copies them, and uses them straight away. A stolen AI key is billed to its owner.
4. Why it lasts. A key stays live until it is revoked where it was issued. Changing it elsewhere does not help.

Real examples

Railway, a platform that runs customers’ apps and stores their secrets as environment variables, published an incident report about an October 2026 breach. The Hacker News reports that AI provider keys that customers stored on Railway were stolen and used to commit an estimated $740,000 in unauthorised spending. Railway says the attacker decrypted variables in at most 1.85 percent of workspaces, about 100,000, an upper limit because its logs show which environments were exposed but not which variables. It also says its forensics did not show customer databases being accessed and there was no indication that customer code was downloaded, and that it will cover charges where AI providers will not refund.

The report does not say how the $740,000 was estimated or what period it covers. Railway advises customers to revoke and replace sensitive variables, and notes that keys should be revoked with the provider that issued them, since reporting charges does not revoke a key. Its advice also includes removing public network access to databases and checking audit logs in GitHub and registries.

The lesson is general. The business using the platform did nothing unusual. Its key was in the normal place. The breach was upstream.

Who it affects and how badly

Any firm with software that calls an outside service: SaaS start-ups, agencies, retailers with online shops, recruitment firms with job-board integrations, and anyone whose staff build apps with AI tools. Regions do not matter, because the keys work from anywhere.

• Sole trader to 10 staff: a leaked AI or cloud key can mean a surprise bill and a service suspended.
• 10 to 50 and 50 to 250: a key with broad access can expose customer data and cause downtime while keys are replaced everywhere.
• Regulated and 250 plus: a key that opens personal data brings reporting duties and questions about access controls.

The UK angle

The ICO’s data security guide says UK GDPR requires security that is appropriate to the risk, and that you must have a process for regularly testing, assessing and evaluating the effectiveness of your measures, naming vulnerability scanning and penetration testing as techniques. It also says the ICO considers the measures you had in place when deciding on a fine. If a leaked key exposes personal data, the 72-hour reporting rule applies (see personal-data-breach-ico-72-hour-rule).

What we check on a test

Method only, no findings claimed:

• Whether keys appear in places a tester can legitimately see: public pages, JavaScript files, mobile apps, error messages and public repositories in scope.
• How the application is configured to receive secrets, and whether secrets are echoed to logs or build output.
• Whether keys are broader than needed, such as an admin key where a read-only key would do.
• Whether a revoked or old key still works.
• Whether a key could be used from anywhere or is limited by address or scope.

A worked example (an illustration, not a real case)

A six-person design agency stores an AI provider key in its hosting platform’s settings. The platform reports a breach. The agency has no list of where the key is used, so it takes days to find every site and plug-in that uses it. Meanwhile it checks the AI provider’s usage page and sees traffic it did not generate. What it costs: staff time, a bill it must dispute, and some clients’ sites running without the feature. What to do: keep a one-page list of every key, who owns it and where it is used, so replacing it takes an hour, not days.

How to detect it

1. Check the provider’s usage and billing pages for spikes or calls you did not make. Many providers show usage by key.
2. Set spending limits and alerts at the provider, where it offers them.
3. Review audit logs on your hosting platform, GitHub and container registries for unfamiliar access.
4. Search your own repositories and files for key patterns with a free secret scanner (OWASP names the open source Yelp Detect Secrets project) before an attacker does.
5. Check whether your staff email addresses appear in known breaches, as stolen logins are a common route to keys.

How to fix or prevent it

1. Revoke and replace any key you think was exposed, at the provider that issued it, then update every place it is used.
2. Keep an inventory of keys with owner, purpose and where used. OWASP lists this metadata as part of secrets management.
3. Give each key the least access it needs, and use separate keys for each application and environment.
4. Store secrets in a secrets manager, not in code, repositories or build output.
5. Prefer short-lived, dynamic credentials where your platform supports them. OWASP says dynamic secrets should be used where possible.
6. Set spending caps and usage alerts.
7. Remove public network access to databases, as Railway advises.
8. Test the process. Rotate a low-risk key on purpose so the first time is not an emergency.

Frequently asked questions

Does deleting a key from my app stop thieves? No. It stays live until revoked at the provider that issued it.

Are environment variables safe? OWASP says they are not recommended unless other methods are not possible.

Who pays if a key is abused? That depends on the provider. Railway says it will cover charges where providers will not refund.

Related terms

Category hub: Credentials, identity and exposure. Related entries: secret-rotation, least-privilege, supply-chain-attack, data-exfiltration, personal-data-breach-ico-72-hour-rule, indicators-of-compromise.

How Wolfcore helps

Breachy checks whether your staff email addresses and passwords are already in known breaches and gives you the exact steps to close each exposure. See Breachy.