OpenAI API Keys in the Open: Why You Should Not Use Them

Searches like "openai api key github" and "free openai api keys" look for keys that someone once published by accident. The temptation is clear: no need to pay. But OpenAI API keys found in public have three problems: they belong to someone else, they almost never work any more, and fiddling with them is dangerous for you. Below we explain where such keys come from, why you must not use them, and above all how not to become the person whose key ends up in such a collection.

Where keys in the open come from

A key becomes public against the owner's will. Typical leak paths:

• A .env file or config with the key was committed and pushed to a public repository.
• The key is written straight into frontend or mobile app code, visible to anyone who opens the page or unpacks the app.
• The key was left in a log, screenshot, video, Jupyter notebook or forum post.
• The key was in the text of a question asked on a public help site.

Deleting a file from the repository does not erase the secret: it remains in commit history, and it is as easy to find there as in the current version. The owner often does not even notice the leak until the bill arrives.

What happens to such a key

Platforms and model providers scan public repositories for secrets, and found keys are, as a rule, revoked automatically or after the owner is notified. So a published key usually lives a short time. Those that still work most often belong to people who simply have not noticed the leak, and they too will be revoked once the owner sees the email or the bill. Sites and repositories with collections of "free keys" mostly gather values that are already invalid, and whatever is valid can stop at any moment.

Why you must not use someone else's key

1. It is someone else's money and account. Each of your requests is charged to the balance of a person who has not allowed you anything. Using access without the owner's consent violates the service terms and in many countries can be classified as unauthorized access to another party's data or resources.
2. Your requests will be seen by someone you do not trust. The texts and files you send pass through the owner's account and may be visible to the owner (in logs, for example) and to their provider. Uploading work documents or personal data there means handing them to a stranger.
3. Instability. The key can be revoked at any second, and your project breaks mid-work.
4. Traps around the idea itself. "Free key generator" sites, archives of "working keys" and paid "key databases" often serve as bait for data theft, non-refundable subscriptions or installing malware. Do not download or run anything like that.

If you accidentally find someone's key, the right move is not to test it with a request but to tell the owner, for example through an Issue in the repository, and close the page.

How not to become the owner of such a key

The good news: you can insure against a leak in advance, and it takes little time. Practical steps:

Keep the key out of code

• The key lives in an environment variable or a secrets manager, not in the source.
• .env is added to .gitignore before the first commit. Commit only an .env.example template without real values.
• Do not put the key in frontend or mobile app code: anything sent to a client can be read. Call the API from your server instead.
• Do not publish screenshots or screen recordings where the key or a console showing it is visible.

Catch the mistake before the commit

Add a secrets check before commits: any secret scanner will do, for example gitleaks. It runs locally and in CI and stops a commit containing a string that looks like a key. Setup takes a few minutes; see the tool's own documentation for details.

Limit the damage of a leak

This is the protection that works when everything else has failed. In Zukko you can create several keys, and each has:

• a name, so you know whose it is;
• daily and monthly dollar limits;
• a list of allowed models (allowed_models).

Create a separate key per project and give it a realistic limit and only the models it needs. Then even a leaked key cannot spend more than the limit amount and cannot call expensive models. When the limit is exhausted, the API answers 429 with the code key_daily_limit_reached or key_monthly_limit_reached. More: key limits and cache↗ and the article why a separate key per project→.

The full key is shown once at creation, so save it to a secrets manager right away.

Rotation and monitoring

• Rotate keys on a schedule and immediately after a person who had access leaves.
• Once a week look at the spending history in the "Usage" section of the dashboard: an unexpected spike is the first sign of a leak.
• Do not send keys in messengers or by email in plain text.

If the key has already leaked

Do not delay. Create a new key, update it in your services' settings, delete the old one and check the spending history for the last few days. The step-by-step order is in the article A leaked API key: what to do→.

An honest alternative to a "free" key

If you need model access for study or a small project, a paid pay-per-token API costs far less than it seems. At Zukko the balance is in dollars, top-ups start from $1, and there is no subscription. Prices as of October 18, 2026, $ per 1M tokens. Take an illustrative request of 2000 input and 500 output tokens:

• deepseek-v4.1-flash (0.013 / 0.038): 2000 × 0.013 / 1M + 500 × 0.038 / 1M = 0.000026 + 0.000019 = $0.000045. For $1 that is about 22,000 such requests.
• gpt-6.1-sol (0.27 / 1.32): 2000 × 0.27 / 1M + 500 × 1.32 / 1M = 0.00054 + 0.00066 = $0.0012. For $1 that is about 830 requests.

This is an example calculation; the real cost depends on the length of your requests. Current prices: GET https://api.zukko.pro/v1/models or the "Models" page in the dashboard. Payment: SBP, cryptocurrency or MasterCard cards; access from Russia is through the gateway. What can actually be had without payment we covered honestly in the article Free neural network API→.

FAQ

Is it legal to use a key found on the internet?

As a rule, no. It is access to someone else's account without the owner's permission, and it violates the service terms. Do not use such keys. A lawyer can give the exact legal assessment for your country.

Why do found keys not work?

Platforms scan public repositories and revoke found keys, and owners delete them themselves when they notice the leak.

Can I just delete the key from the repository?

No, it must be revoked. Deleting the file does not remove the secret from commit history, so the key counts as compromised. Create a new one and delete the old one.

Is a key limit enough for protection?

A limit caps the damage but does not replace the other measures. Use everything together: keep the key out of code, a secrets scanner, a separate key per project, limits and rotation.

To create a key with a limit and a model list, open the keys section of the Zukko dashboard.