GitHub and .gitignore: Never Expose API Keys with AI
By Alexandre Saint-Jean
Audio version
Audio version produced by text-to-speech from the article. Our AI charter
An API key left in plain text in a file pushed to GitHub gets picked up by automated scanners within minutes, not days. With generative AI writing code on your behalf, this risk becomes more frequent: the .gitignore file and the environment variable are the two habits that prevent it.
What is GitHub, exactly?
GitHub is a code-hosting platform built on Git, the most widely used version-control system in the world. Every code change is recorded, timestamped and kept in a searchable history. A repository can be private (restricted access) or public (visible and clonable by anyone, including bots).
That public dimension is what changes everything. A public repository is not just visible to curious humans: it is continuously scanned by automated tools searching for specific patterns in code, notably known formats for API keys, tokens or passwords.
How does an API key end up written in plain text in AI-generated code?
When you ask an AI assistant to set up a connection to a service (a database, a payment API, a third-party AI model), the shortest path is to write the secret's value directly into the code file, in the form api_key = "sk-abc123...". This is not malicious, it is simply the fastest result to produce.
The problem shows up at the first git push: if the file is tracked by Git and the repository is (or becomes) public, the key goes out with the code. It remains visible in the commit history even if it is removed right after, as long as it has not been revoked with the provider, as noted in GitHub's documentation on removing sensitive data.
GitHub itself uses this risk for protection: its secret scanning mechanism automatically detects dozens of known secret formats and raises an alert, sometimes within minutes. Malicious actors do exactly the same thing, continuously, across every public repository.
What does the .gitignore file actually do?
A .gitignore is a text file, placed at the root of a project, that lists the files and folders Git should ignore: it never records them in the history, even if they exist on disk. It is the basic mechanism for stopping a sensitive file from going out by mistake during a commit, as explained in GitHub's official documentation on ignoring files.
In practice, the .env file (which holds environment variables, including secrets) should always be listed in .gitignore. One line is enough: .env. Most project generators create this file by default, but a project started quickly with generative AI can be missing it, especially if a .gitignore was never explicitly requested.
One point of caution: .gitignore only protects files not yet tracked by Git. If a .env file was already added to a commit before being added to .gitignore, it stays in the history. You then need to explicitly untrack it (git rm --cached), on top of ignoring it going forward.
What is the right practice to never expose a secret?
Three habits cover most situations an SME faces when coding with AI assistance. None require an advanced developer profile.
Never hardcode an API key into a code file. The key should live in an environment variable (a local .env file, or secrets configured on the hosting platform), and the code should only reference it by name. This distinction around technical fundamentals (databases, OAuth, API keys) is covered in our foundational article on the basics before coding with AI.
Check the .gitignore before the very first commit of a new project, not afterwards. This is when most mistakes happen: the project has just been created, the .env already holds real test values, and the first git push goes out before anyone has thought about exclusions.
Treat security as a subject for regular audits, not a one-off gesture. This broader dimension (periodic review, team best practices) is covered in generative AI security: best practices and audits for SMEs.
In practice, how do you stay careful depending on the AI tool you use?
Claude (Claude Code, Claude Cowork)
When Claude Code generates a configuration file or a sample API connection, explicitly ask for an environment variable rather than a hardcoded value, and have it check or create the .gitignore before the first commit. A single instruction in your initial request ("use environment variables, never a secret in plain text") is enough to steer all the code generated afterwards.
ChatGPT and Codex
Codex can also create and push code to a connected repository. Same principle: check, before any Git action, that .env is listed in the generated .gitignore, and review the configuration files it produces to make sure no key appears in plain text.
Antigravity (Google's IDE agent)
Antigravity works within the development environment, with access to the terminal and Git. The same points apply: require environment-variable-based configuration, and review every proposed git add or git push before approving it, especially on a freshly initialised project.
Frequently asked questions
- Can generative AI really expose an API key by mistake?
- Yes, directly. When you ask an AI assistant to write a configuration file or a sample API connection, it often reproduces the simplest pattern: the key written in plain text in the code. If that file is then pushed to GitHub without a suitable .gitignore, the secret becomes visible in the repository's history, even if it is removed in a later commit.
- Does a private repository protect against API key leaks?
- It reduces the risk but does not remove it. A private repository can accidentally become public, or become accessible through a misconfigured token. The good practice, an environment variable, never a hardcoded secret, therefore applies even to a private repository.
- What should you do if an API key has already been pushed to GitHub?
- Revoke it immediately with the service provider, not just delete it from the code: a key that has passed through a public commit remains retrievable in the Git history until it is invalidated. Generate a new key, then clean up the history if necessary, as described in GitHub's documentation on removing sensitive data.
- Is a .gitignore file enough to secure a project?
- No, it is a first line of defence. It stops a sensitive file from being added by mistake to a new commit, but it does not protect a file already tracked by Git, nor secrets written directly into source code rather than into a .env file. It needs to be paired with environment variables and, ideally, a secret-scanning tool.