Stop leaks at the commit with push protection and pre-commit scanning, limit the damage with a per-key spend limit, keep keys out of notebooks and logs, and make rotation routine. You will not stop every leak, so cap the cost of the one that gets through.
Layer 1: block secrets at the push
GitHub documents push protection as a secret scanning feature that blocks hardcoded credentials before they reach a repository, so it prevents leaks rather than alerting afterward. It applies to command line pushes, commits in the web interface, file uploads and API requests. When it detects a possible secret it stops the push and explains why. Repository-level protection needs GitHub Secret Protection and is off by default, so check whether it is on. The user-level setting, on by default, covers pushes to public repositories only.
Bypass is possible by default for anyone with write access, with a reason, and each bypass creates an alert, an audit entry and an email. Choosing the reason "I'll fix it later" creates an open alert. Review those alerts, and consider limiting who may bypass.
Other source hosts have similar features. Check yours.
Layer 2: scan what push protection misses
Add a scanner to your pipeline and to developers' machines before commit. Cover the places keys hide:
- Old commits and other branches
- Notebooks with saved outputs
- Config and environment files committed by mistake
- Container image layers
- CI logs that echo environment variables
- Documentation and issue text pasted with a working example
Safeguard's secret and dependency scanning covers repositories and images, and you can try a free scan at https://gold.safeguard.sh/scan.
Layer 3: keep keys out of code paths that spread
Load keys from the environment or a secrets manager at runtime. Do not print them in debug output. Make sure error handlers do not dump request headers, which include the key. See what never to log. AI-assisted coding adds a risk of sample keys and hardcoded values in generated code, covered in the hardcoded secrets checklist.
Layer 4: cap the cost
Assume a key will leak one day. Set a spend limit on each key or workspace well below what you could not afford, and an alert at a lower threshold. Provider documentation describes spend limits you can set below the tier cap and per-workspace limits. When a user-set limit is reached, one provider returns a 400 error, so your monitoring should watch for it. See setting LLM API spend limits.
Use separate keys per environment and feature so one leak has a small blast radius. See separating keys.
Make rotation routine
A rotation you practice is fast. Rotate on a schedule, and when staff leave. Keep a runbook: revoke, issue, deploy, check usage for the exposed period. The steps are in how to rotate leaked API keys.
What to do on an alert
Treat any alert as a real leak until proven otherwise. A key found in a public place may be abused within minutes. Revoke first, investigate after.
Quick check
Is deleting the commit enough?
No. Forks, clones and caches may hold it. Revoke the key regardless.
Sources
Last reviewed: 19 October 2026.
