Know what must stay private
- Hosting, database, mailbox and administrator passwords.
- SSH private keys, recovery codes and two-factor authentication codes.
- Payment gateway, registrar, CDN and third-party API credentials.
- Production .env files, database exports and logs containing customer information.
- Session cookies, access tokens and signed password-reset links.
Prepare the project before using an agent
- Add secret files and generated exports to the ignore rules.
- Create an example environment file containing safe placeholders.
- Search the repository history for credentials before connecting it to another service.
- Use synthetic test data instead of a production customer database.
- Remove sensitive values from logs and screenshots before attaching them to a task.
Inject secrets at runtime
- Store production values in the hosting environment or an approved secret manager.
- Give each application its own credential with only the required permissions.
- Never expose a server secret through a public-prefixed frontend environment variable.
- Do not print environment values during builds, tests or deployment diagnostics.
- Pass an SSH key by file path, not by copying its contents into a prompt or command argument.
Respond to an exposed secret
- Revoke or rotate the secret immediately. Deleting it from the latest file is not enough.
- Check logs for use from unknown addresses or unexpected actions.
- Replace the value in every service that depends on it.
- Remove it from repository history when exposure through Git is confirmed.
- Document the incident without reproducing the secret in tickets or chat.
Important
Assume a committed or pasted credential is exposed even when the repository or conversation was intended to be private.
Official references
Platforms and tools change over time. Use these official references for the current product documentation.