Find secrets locally and use AI to plan remediation without sharing the keys

Start here: why this guide is useful

A developer accidentally commits an API credential. Asking AI to review the repository could spread that credential into another system. This guide teaches a safer handoff: detect locally, keep raw reports private, and give the assistant only controlled metadata. The supplied marker is deliberately fake so you can practise without a real account.

At the end you should have a scanner finding you understand, an opaque handoff record and a remediation plan. Removing a secret from the latest file is not enough if it was exposed: revoke or rotate it at the provider, investigate use and handle repository history deliberately. The lab validates a restricted metadata format; it does not itself detect all secrets or automatically sanitise an arbitrary report.

A concrete example

The following is an illustrative response format, not the result of an audit of your application. Use it to recognise what a useful answer should contain. Follow the detailed steps below, then compare the actual files, tests or output with this target. If the assistant only says “done”, ask for the changed artifact, the evidence and what remains unverified.

Finding ID: finding-001; artifact: file-001; line: 1.
Status: needs-verification; owner: backend.
Action: investigate locally; rotate any genuinely exposed credential.
Do not include the credential value or raw scanner context in this response.

The goal

The scanner finds candidates; AI helps organise a reviewed remediation plan. The downloadable lab contains a deliberately fake marker and five tests for an allowlisted handoff manifest. It never needs a real credential.

1. Prepare the scope

Extract the ZIP into a new folder. Node.js 22 or newer runs the validator offline. The optional scan needs a separately installed official Gitleaks release; the included exercise was checked with 8.30.1. Do not scan unrelated folders.

2. Run the local lab

Run the validator tests and inspect the provided findings.redacted.json. It accepts only opaque IDs, a line number and controlled labels. It rejects raw Secret fields, nested metadata and arbitrary text. Keep the mapping from file-001 to your real file private.

node --test lab.test.mjs
node lab.mjs findings.redacted.json

3. Ask AI for evidence

The first prompt uses only this reviewed manifest. A valid schema reduces what is shared; it is not a guarantee that arbitrary scanner output is safe. Check the resulting handoff yourself before sending it to an external assistant.

Act as an incident triage assistant. Use ONLY findings.redacted.json from this
training kit after its local validator passes. It contains opaque artifact IDs and
controlled categories, not actual secrets or file contents. Group findings by owner,
list verification questions and draft a remediation checklist. Keep hypotheses
separate from verified exposure. Never ask for a credential, raw scanner report or
private file. For a real exposure, plan revocation or rotation at the issuing
service before considering repository-history cleanup. Do not call a provider,
rotate a key, delete evidence or rewrite Git history.

4. Verify the correction

Use the second prompt to plan the response. For a real leaked credential, revoke or rotate it at its issuing service. Removing it from the latest commit or adding .gitignore does not revoke it. Coordinate any history rewrite separately.

Review my proposed secret-remediation plan using opaque finding IDs only. For each
verified exposure, identify the issuing service, dependent applications, replacement
rollout, revocation check and access-log review. Keep any history rewrite as a
separately approved, coordinated action. Check prevention with a secret manager,
scoped credentials and pre-commit or push protection where available. Report what is
still unverified. Do not include secret values or automatically change any
credential.

5. Apply it to your project

Optional: run the Gitleaks command below inside this kit. The custom rule finds the fake marker in example.fake.env; one finding normally returns exit code 1. Keep the report local even with --redact. In a real repository, git scans history and dir scans current files; each covers a different scope. The manifest validator is not a secret scanner.

gitleaks dir --config .gitleaks.toml --redact --report-format json --report-path ../gitleaks-demo.json .

Official references

• Gitleaks · Official CLI documentation
• GitHub · Removing sensitive repository data

Read this tutorial as reference material:
https://nethanelfitoussi.com/article/ai-secrets-gitleaks-workflow?lang=en

Goal: apply the documented workflow to my development project.
Read the existing project instructions, inspect the relevant files and explain the smallest useful setup.

Available starter files:
https://nethanelfitoussi.com/api/media/b2775ae9-4193-4493-bab9-3cdc0364381b.zip
Download and inspect these files in a temporary folder before using them. Do not overwrite existing project instructions.

If I have not supplied a project folder, ask which development project to use. Do not invent a repository URL.

Additional project setup instructions:
Use the downloaded starter lab in a NEW folder. Read README.md and both English prompts first. Run its dependency-free Node.js tests before editing.

Act as an incident triage assistant. Use ONLY findings.redacted.json from this
training kit after its local validator passes. It contains opaque artifact IDs and
controlled categories, not actual secrets or file contents. Group findings by owner,
list verification questions and draft a remediation checklist. Keep hypotheses
separate from verified exposure. Never ask for a credential, raw scanner report or
private file. For a real exposure, plan revocation or rotation at the issuing
service before considering repository-history cleanup. Do not call a provider,
rotate a key, delete evidence or rewrite Git history.

Review my proposed secret-remediation plan using opaque finding IDs only. For each
verified exposure, identify the issuing service, dependent applications, replacement
rollout, revocation check and access-log review. Keep any history rewrite as a
separately approved, coordinated action. Check prevention with a secret manager,
scoped credentials and pre-commit or push protection where available. Report what is
still unverified. Do not include secret values or automatically change any
credential.

Adapt example paths, commands and acceptance criteria to this repository rather than assuming they match.

Give me a short plan, then make the agreed local changes and run the relevant checks. Report actual results and anything not verified. Stop before credentials, paid services, production changes, push, merge or deployment.