Remove API Keys, Credentials, and Secrets Before Using AI Coding Tools

Secrets appear outside source files

API keys, access tokens, private keys, passwords, connection strings, webhook secrets, session values, certificates, and signed URLs can appear in more places than the code being discussed.

Review .env files, configuration, deployment manifests, CI logs, shell history, notebooks, test fixtures, screenshots, stack traces, copied terminal output, generated artefacts, build folders, documentation, and sample requests. A small code excerpt can include a live value in a comment or error message.

Also check filenames, repository URLs, internal hostnames, tenant IDs, customer data, and security findings. These may not be credentials but can still be inappropriate for the selected AI tool.

If exposure already happened, contain it first

1. Revoke or rotate the credential. Use the provider's controls; do not wait for repository cleanup.
2. Review use. Check audit, access, billing, and security logs for unexpected activity.
3. Limit related access. Review permissions, sessions, derived tokens, and dependent systems.
4. Notify the right people. Follow the organisation's incident and legal procedures.
5. Then remove the value. Clean the current file, repository history, artefacts, caches, and other copies as appropriate.

GitHub's guidance stresses that removing a secret from the latest commit does not remove it from history, clones, forks, cached views, or pull-request references. Rotation changes what an attacker can do; text removal alone does not.

Create the minimum code bundle

Share only the files and lines required to explain the problem. Exclude environment files, lock down logs, and replace live configuration with a small synthetic example. Avoid uploading an entire repository when one function and an invented input reproduce the issue.

Use explicit inert placeholders that preserve syntax, such as OPENAI_API_KEY=REDACTED_TEST_VALUE or postgresql://USER:PASSWORD@HOST/DB. Do not use a truncated live key or a reversible encoding as a sample.

OpenAI's API-key safety guidance recommends keeping keys out of client-side environments and source repositories, using environment variables, and monitoring usage. The same principles apply before code is copied into an AI conversation.

Scan supported and organisation-specific patterns

Secret scanners recognise known provider formats and sometimes validate whether a credential is active. Coverage is not complete. Internal tokens, database passwords, proprietary headers, short secrets, and values split across files may not match a public pattern.

Add custom patterns for organisation-specific prefixes and configuration conventions. Search for variable names such as password, secret, token, private_key, and connection_string, then review the assigned values and surrounding context.

Do not copy detected live secrets into a report or prompt. A finding can be shown by category, file, line, and a safely truncated fingerprint that is not usable as authentication.

Check history and generated output

Final pre-upload checklist

• Only the minimum reproducing code and synthetic input are included.
• Environment, configuration, logs, notebooks, images, and generated artefacts were reviewed.
• Known provider patterns and organisation-specific patterns were scanned.
• Live values were replaced with inert, non-reversible placeholders.
• The exact bundle was re-scanned after transformation.
• The AI coding service, account, workspace, retention, and policy are approved.
• Any previously exposed secret was revoked or rotated and investigated.