The useful result
Keep every secret out of prompts and commits, and know exactly what to do after a leak.
- Keep every secret out of prompts and commits, and know exactly what to do after a leak.
Code assistants love to say “put your API key here”, and beginners paste the real one into the file, the chat and the repository. Once a secret is in a public repository or a shared chat, assume someone can read it. Bots scan for leaked keys constantly.
The habit is simple: the secret lives in an environment variable on your machine, the code reads it by name, and the AI only ever sees the name. If something does leak, GitHub’s guidance is clear that the first step is to revoke or rotate the credential, because deleting history does not undo exposure.
The examples below are illustrative exercises, not recorded results from any tool. Sources were checked on 24 October 2026; menus, limits and prices change, so confirm details on the linked pages.
Before you start
- A project that uses an API key
- A .env file or your platform’s secret settings
- A GitHub account (optional but useful)
Review evidence
Documentation-based review · 2026-10-24
Primary documentation and official guidance checked on 24 October 2026. Examples, checks and exercises are original illustrations, not recorded tool tests. Cover artwork is a conceptual illustration.
Store the secret in an environment variable and ignore the file
Put the key in a .env file or your host’s secret manager, and read it in code by name, for example OPENAI_API_KEY. Add the .env file to .gitignore before your first commit so it is never staged. In prompts, say “read the key from the environment variable named X”, never paste the value.
Write the code to call [service] using an API key read from the environment variable [NAME]. Do not hard-code any key, do not print the key, and do not include a placeholder that looks like a real key. Show me the .gitignore line I need.Example / expected result
Illustrative example; not a recorded model result.
The code reads process.env.PAYMENTS_KEY, and .gitignore contains the line .env.
Check your result
The key exists only in the .env file or secret store, and .gitignore lists the .env file.
Scan before you commit or paste
Search your changes for words like “key”, “token”, “secret” and “password”, and for long random-looking strings. Use your editor’s search and check the staged files before each commit. Turn on GitHub’s secret scanning if it is available for your repository, so leaks are flagged automatically.
Check your result
A search of the staged changes finds no real secret, and scanning is turned on where available.
If a key leaks, revoke or rotate it first
Treat any exposed key as compromised. Create a new key, update your environment variable and revoke the old key at the provider. GitHub’s guidance says this comes first; rewriting history may not be warranted once the key is dead. Then check the provider’s usage logs for activity you do not recognise.
Check your result
The old key no longer works, the new key is in place and you have reviewed recent usage.
When it goes wrong
Deleting a file or a commit does not make a leaked key safe; assume it was copied. A key in a screenshot or error log is also a leak. Give each key the least permissions it needs and set a spending limit where the provider offers one.
Make it your own
Check one real project: find where each secret is stored, confirm .env is ignored by Git and write the steps you would follow tomorrow if a key were exposed today.
Useful next resources
Sources and review
Last checked Oct 24, 2026. Features and account limits can change. Verify important results against your original material.
Did this help you complete your task?
Tell us what needs improving. No account or private output required.
Report incorrect information or a broken linkGenius Forges Editorial
Practical AI lessons with checked sources, labelled examples and human verification.
