How to avoid leaking a token before git push

securitysecretsgitCIAI review

A practical pre-push secret check for code changes, tokens, local verification, and exposed-secret cleanup

Where secrets usually hide

Start with the changed files, not the whole repository. The problem is often not in the main application code, but in files that feel secondary:

  • .env, .env.local, .npmrc, .pypirc, .dockercfg;
  • config examples and README snippets;
  • CI files, deploy scripts, Dockerfile;
  • tests, fixtures, snapshots;
  • temporary logs, debug output, exported JSON.

A dangerous secret does not always say password. It can be a webhook URL, private registry token, deploy key, cloud credential, session cookie, or a test key that accidentally has access to a real service.

What you can safely give AI

Do not paste the real token into AI, even if that is the thing you want checked. Replace the value with its shape:

  • ghp_...redacted;
  • sk_live_...redacted;
  • https://hooks.example.com/...redacted;
  • DATABASE_URL=postgres://user:REDACTED@host/db.

AI does not need the full secret value to spot the risk. It needs the context, file names, project type, and the shape of the suspicious line.

Verify the findings locally

After the AI pass, still run a local check. Start with:

git diff --cached
git status --short

If the project has a secret scanner, run it before push. If it does not, at least search the staged diff for common terms:

git diff --cached | rg -i "token|secret|password|api[_-]?key|private|credential"

That is not a complete security guarantee, but it catches many avoidable mistakes before they become incidents.

If the secret is already in a commit

Do not start by deleting the line and adding a new commit. If the secret has already been in git history or a remote repository, the order is different:

  1. Rotate the secret so the old value stops working.
  2. Remove the secret from the current code.
  3. Decide whether history needs to be rewritten.
  4. Check access logs if the secret had real permissions.
  5. Add a scanner, rule, or pre-commit hook to reduce repeat mistakes.

The key point: a deleted line does not make a secret safe again. If someone could have seen it, treat it as exposed.

In short

Checking secrets before push is not paranoia. It is normal hygiene. AI is useful as a careful second look, but only if you do not give it the secret itself.

The best token mistake is the one you catch before git push.

Quick checklist

  • Check `.env`, config examples, tests, README, and CI files.
  • Do not paste real secrets into the AI prompt.
  • Tell safe placeholders apart from real tokens.
  • Run a local check before `git push`.
  • If a secret is already exposed, rotate first, then clean history.
  • Add a rule or hook so the same mistake is harder next time.

Audit secrets before git push

Help me check these changes before git push so I do not leak secrets. Context: - Project type: [frontend / backend / CLI / infra / other] - Changed files: [paste the file list] - Suspicious snippets or diff: [paste only relevant snippets, with real secrets redacted] - Where configuration usually lives: [.env, CI variables, secret manager, other] - What counts as a secret in this project: [API keys, tokens, passwords, private URLs, certs] Check the changes: 1. Name the places where secrets are most likely to have entered the code. 2. Flag lines or patterns that look like tokens, passwords, keys, private URLs, or test credentials. 3. Say what must be removed from git and what can stay as a safe example. 4. Suggest local commands to run before push. 5. If a secret is already in a commit, give a short plan: rotate, remove, rewrite history, or follow-up issue. Output format: - High-risk findings - Suspicious but needs human check - Safe examples - Commands to run before push - If already exposed: next actions