Everything You Need to Know About Secrets in Local Development

Secrets are the values that let your code reach something valuable: an API key, a database password, a signing token. In local development they leak easily. A key pasted into an example file gets committed. A token printed in a log gets shared. A credential pasted into a prompt goes to whichever service the agent uses.

Where secrets leak

• Committed files. An .env file or a config with a real value is committed to git. Even if you delete it later, it stays in the history.
• Copied examples. An example file with a real key, copied into the code, becomes the real key.
• Logs. A debug line that prints a request header or a connection string exposes the credential to anyone who reads the log.
• Prompts. Pasting a secret into a chat or an agent session sends it to a third party.
• Screenshots and shared terminals. A visible value in a recording is a visible value.

Keep them out of the code

Read secrets from the environment at runtime. The code should name the variable, not contain its value. Provide a template file with placeholder values, and keep the real file out of version control.

Confirm the ignore rules work by checking git status after you create the real environment file. If it appears, it is not ignored.

Keep them out of logs

Log what happened, not the credential that made it happen. Mask values in any output a person or a tool might see, and avoid printing whole configuration objects.

Keep them out of prompts

Do not paste a real secret into an agent session. Use a placeholder and tell the agent where the real value is read from. If an agent needs to call a service, give it a scoped, short-lived credential rather than a master key.

Rotate what leaks

If a secret is exposed, rotate it. Deleting the commit is not enough, because the value may already be copied. Revoke the old credential, issue a new one, and update the environment that uses it.

Scope what you grant

Give each service only the access it needs. A local database user for development should not have rights to production data. A tool that only reads should not be able to write.

Checks worth running

• Search the repository for patterns that look like keys before each commit.
• Run your secret scanner in CI, and treat a finding as a failed build.
• Confirm the environment file is listed in .gitignore and absent from git status.

Summary

Keep secrets in the environment, out of code, logs, and prompts. Rotate anything that has been exposed, scope each credential to its service, and check for leaks before each commit. The cost of a leak is almost always higher than the cost of the check.