Scan for leaked secrets and lock them down

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Scan for leaked secrets and lock them down

Launching means more eyes on the production site, including people who read JavaScript bundles and public repositories for keys. Find any secret that is committed, logged or shipped to the browser, tell me which ones to rotate, and make it hard for a new one to slip in.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Print any secret in full.
- Rewrite git history or force-push.
- Rotate keys with providers: I do that.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Search the working tree

Search the code and config files for things that look like secrets: API keys (`sk_`, `pk_live`, `AKIA`, `ghp_`, `xox`), private keys (`BEGIN PRIVATE KEY`), connection strings with passwords, webhook signing secrets and tokens in URLs. Report each by file and line, with the value masked. Never print a full secret.

### 2. Search the history

Search the git history for the same patterns (for example with `git log -p` on suspicious files). A secret that was removed in a later commit is still public if the repository is. Recommend a dedicated scanner I can run (gitleaks or trufflehog) rather than installing one yourself.

### 3. Check what reaches the browser

List every environment variable exposed to client code (for example `NEXT_PUBLIC_`, `VITE_`, `PUBLIC_` prefixes) and confirm each is safe to be public. Payment secret keys, database URLs and admin tokens must never be among them.

### 4. Lock it down

Move any hard-coded secret into environment variables, add or update an `.env.example` with placeholder values, check `.gitignore` covers `.env*` files, and make sure secrets are not written to logs or error messages. Give me a list of the secrets I must rotate with the provider, most dangerous first.

## Done means

- [ ] No secret remains in the working tree; config reads them from the environment.
- [ ] I have a ranked list of secrets found in the code or history, to rotate.
- [ ] Every variable exposed to the browser is confirmed safe to be public.
- [ ] `.env` files are ignored, and `.env.example` documents the variables with placeholders.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.