🛡️

Keeping Secrets Safe: API Keys, Passwords, .env Files, and AI Chat

How to handle API keys, passwords, and .env files without leaking them — why they don’t belong in Git, how to share credentials safely, and what to paste (and never paste) into AI chat tools.

A single leaked API key or committed password can drain a cloud account, expose customer data, or hand over a whole environment. The good news: nearly every real-world leak comes from a handful of avoidable habits. This guide covers the ones that matter most — secrets in Git, credential sharing, and the newest one, pasting sensitive data into AI chat tools.

What counts as a secret

Treat all of these as “never expose”:

API keys and tokens — cloud providers, payment processors, email/SMS services, OpenAI/Anthropic keys, webhook signing secrets
Passwords — service accounts, database logins, admin panels, Wi-Fi/PSKs
Connection strings — they usually embed a username and password (postgres://user:pass@host/db)
Private keys and certificates — SSH keys, TLS private keys, code-signing certs
`.env` files — the single most commonly leaked file, because it bundles all of the above in one place

Rule #1: secrets never go in Git

Git remembers everything. Committing a secret and “deleting” it in a later commit does nothing — it’s still in the history, and on a public repo it’s scraped by bots within minutes. The fix is prevention, not cleanup.

Keep secrets in a `.env` file and add .env to .gitignore before your first commit
Commit a `.env.example` with the variable *names* and dummy values, so teammates know what to fill in — never the real values
In production, set secrets as environment variables in your host’s dashboard (Vercel, Azure, AWS), not in files in the repo

.gitignore — and how to verify it’s working

# In .gitignore
.env
.env.local
.env.*.local
*.pem
*.key

# Confirm Git is ignoring your .env (should print ".env"):
#   git check-ignore .env

# List everything currently tracked, to catch a secret already committed:
#   git ls-files | findstr /I "env key pem secret"

If a secret was already committed, rotate it first

Assume any secret that ever touched a repo is compromised — scrubbing Git history (git filter-repo, BFG) is worth doing, but the only real fix is to revoke and regenerate the key/password at its source. Rotate first, clean history second.

Detect leaks before (and after) they happen

Enable GitHub secret scanning + push protection on your repos — it blocks a push that contains a recognized key format
Run a scanner like gitleaks or trufflehog in CI so a secret never reaches the remote
Turn on billing/usage alerts on cloud and API accounts — a spend spike is often the first sign of a leaked key

Quick local scan with gitleaks

# Scan the working tree and full history for committed secrets
gitleaks detect --source . --verbose

Sharing credentials safely

The unsafe defaults are email, chat/Teams/Slack messages, and text files on a share — all of them persist and get forwarded. Use tools built for the job:

A team password manager (1Password, Bitwarden, Keeper) — the correct answer for anything a team reuses. Share by vault, not by copy-paste, so access can be revoked centrally.
One-time secret links (e.g. a self-destructing note service) for a single hand-off — the link works once, then the secret is gone.
Prefer credentials that aren’t shared at all — per-user API keys, SSO, and short-lived tokens beat a shared password everyone knows.

MSP tip: rotate on offboarding

Any shared secret a departing employee knew is compromised the day they leave. Per-user credentials and SSO make offboarding a single revoke; shared passwords make it a scramble to rotate everything. Design for the former.

AI chat tools: what’s safe to paste

AI assistants are now part of daily IT work — and pasting the wrong thing into one is the newest way to leak a secret. The core principle: treat an AI chat like a third party you don’t fully control. Depending on the tool and plan, what you paste may be stored, logged, or (on some consumer tiers) used to train models.

Don’t paste: - API keys, tokens, passwords, or connection strings — redact them to <REDACTED> or sk-...xxxx - Full .env files — share the variable names, not the values - Customer PII, credentials from tickets, or anything under NDA/compliance scope

Safer habits: - Paste the *shape* of the problem, not the live values — a config with placeholders debugs just as well - Prefer business/enterprise AI tiers, which typically contractually exclude your data from training and add retention controls - If a secret does get pasted, rotate it — treat it as exposed

Assume paste = disclosure

The safe mental model for any external tool — AI chat, a pastebin, an online JSON/JWT decoder, a “format my SQL” site — is that whatever you paste has left your control. Redact secrets before they hit the text box, not after.

The five-minute checklist

.env is in .gitignore, verified with git check-ignore .env
A .env.example documents the variables without real values
Production secrets live in the host’s environment settings, not the repo
Secret scanning / push protection is on for every repo
Shared credentials live in a password manager, not chat or email
Billing and usage alerts are enabled on cloud and API accounts
Nobody pastes real keys, passwords, or .env contents into AI chat
There’s a habit of rotating any secret that might have been exposed