How to protect API keys in your app, and what to do when one leaks

Knowing how to protect API keys has become essential now that apps are built faster than ever, often with AI app builders and backend services like Supabase. On 5 October 2026, GitHub added secret scanning detectors for keys from Lovable, Supabase and Pydantic. It is a useful safety net, but the strongest protection is keeping secrets out of your code in the first place.

This guide explains why hardcoded keys are dangerous, what GitHub now detects, what to do the moment a key leaks, and a checklist we use to keep secrets out of a codebase.

Why hardcoded API keys are a risk

According to GitHub’s documentation, when credentials like API keys and passwords are committed to repositories as hardcoded secrets, they become targets for unauthorized access. Anyone who gets the key can act as your app: read data, send messages, or run up a bill on a paid service.

GitHub also describes “secret sprawl”, the uncontrolled spread of credentials across repositories. The more places a key lives, the harder it is to know who can use it and the slower it is to replace.

What GitHub secret scanning now detects

The 5 October update adds these secret types to GitHub’s automatic detection:

• Lovable Labs: lovable_api_key. Lovable also joined the secret scanning partner program.
• Pydantic Services: logfire_token and pydantic_ai_gateway_api_key.
• Supabase: supabase_oauth_access_token and supabase_scoped_personal_access_token.

Partner secrets found in public repositories are reported automatically to the company that issued them, so they can revoke or rotate the credential before it is abused. Other secrets generate alerts when found in public or private repositories. Secret scanning runs for free on public repositories, and is available for organization-owned private repositories with GitHub Secret Protection.

What to do when an API key leaks

1. 1Rotate the key immediately. GitHub’s guidance is to rotate the affected credential right away to prevent unauthorized access.
2. 2Check where it was used. Review the provider’s logs for activity you do not recognize. This step is our recommendation, not part of GitHub’s guidance.
3. 3Remove it from the code. Move the new key to an environment variable or a secret manager. Rewriting Git history is optional: GitHub notes it is time-intensive and often unnecessary once the key has been revoked.
4. 4Block the next one. Turn on push protection so the same mistake is caught before it reaches the repository.

Push protection: stop secrets before they are pushed

Secret scanning finds leaks after the fact. Push protection works earlier: it blocks a push that contains a secret and explains why, so the developer can remove it and try again. It is disabled by default and can be enabled by a repository administrator, organization owner, security manager or enterprise owner.

Contributors can bypass a block by giving a reason, such as a test value or a false positive. When they do, GitHub creates an alert and notifies the people watching the repository, so bypasses stay visible.

API key security checklist

Based on our project experience, these are the habits that prevent most leaks:

1. 1No keys in source code. Use environment variables or a secret manager, including in mobile and frontend projects.
2. 2Separate keys per environment. Development, staging and production should never share a key.
3. 3Secret scanning turned on for every repository.
4. 4Push protection turned on so mistakes are blocked before they leave a laptop.
5. 5Least privilege for each key. Give a key only the access it needs, and prefer scoped tokens where the provider offers them.
6. 6A plan to rotate keys. Know who can replace each key and how long it takes.

If your app talks to AI services, the same rules apply to those keys. Our article on automating legacy software with AI also covers keeping a human approving sensitive actions.

What it means for your business

AI app builders have made it possible to launch a working product in days. That speed is valuable, but it also means more prototypes reach real users with keys sitting in the code. Detection tools help, yet they react after the fact. We suggest treating secret handling as part of moving any prototype to production, alongside testing and backups.

If you started with a quick prototype, our MVP development guide explains what to harden before you scale.

How Estontinc helps

Estontinc is a software house in Malang with 100+ projects and 50+ clients over more than six years. Through our web development service we audit and harden web apps, including ones that began as AI-built prototypes. Our cloud and DevOps team sets up secret managers, secret scanning and push protection in your pipeline.

We work under NDA and offer maintenance with monitoring and backups, so security stays in place after launch. Tell us about your app through the contact page and we will reply within 24 hours.