Coding agents run in your working tree, often with the same file access you have. That includes .env files, private keys, and package manager credentials. Most runs never touch them. When one does, the review is different from a normal code review, because the risk is not only a wrong line of code but a credential that ends up somewhere it shouldn't.

This guide covers what to check when an agent reads, writes, or creates secret-bearing files, and what to do if a secret is exposed.

Know which files hold secrets in your project

Before reviewing, list the files where secrets live. Common ones include:

  • .env, .env.local, .env.production, and similar environment files
  • private keys and certificates, such as *.pem, *.key, and *.p12
  • package registry configuration such as .npmrc and .pypirc, which can hold auth tokens
  • cloud and tool credentials in the repository, if your project keeps any there

Then check which of them Git ignores. git check-ignore -v prints the ignore rule that matches each path:

git check-ignore -v .env .env.local .npmrc

One detail matters here: ignore rules do not apply to files Git already tracks. If a secret file was committed once, adding it to .gitignore later does not stop changes to it from showing up, or from being committed again.

Check what the agent changed

Look at three kinds of change.

Edits to secret files. An agent might add a variable to .env while wiring up a feature. Check that it added a placeholder or a local-development value rather than a real credential copied from elsewhere, and that it did not overwrite existing values.

New files that may hold secrets. Agents sometimes create a config file, fixture, or script with a credential inlined. Search the added lines for values that look like keys or tokens, and for new files that aren't ignored but should be.

Changes that expose secrets indirectly. These are easy to miss:

  • a log statement or error message that prints configuration or request headers
  • a test fixture or snapshot that captured a real token
  • a change to .gitignore that removes or narrows a rule
  • a frontend build setting that exposes server environment variables to the browser
  • a new .env.example that contains real values instead of placeholders

For the last category, read the code around the change, not only the changed line. A new console.log(config) is one line, but what it prints depends on what config holds.

If a real secret was written to a tracked file

If the secret has not been committed, remove it from the file, move it to an ignored file or your secret manager, and check git diff again before committing.

If it was committed or pushed, the priority changes. GitHub's guidance on remediating a leaked secret is that the most important step is revoking the secret with its provider, and that it is not sufficient to remove it from your codebase. Rewriting Git history can come after, but it does not make an exposed credential safe again.

So the order is:

  1. Revoke or rotate the credential with the provider.
  2. Update the places that use it.
  3. Remove it from the code and, if needed, from history.

Reduce the chance of it happening again

A few habits make these reviews rarer:

  • Keep real secrets out of the repository directory where you can, for example in a secret manager or your shell environment.
  • Keep .env.example files with placeholder values only, so an agent has a safe template to copy.
  • Check your agent's own settings for file-access or permission controls, and use them for secret files if it supports them.
  • Use a secret scanner in your pre-commit hooks or CI as a second check.

Where Diffward fits

Diffward is a VS Code extension that groups a local agent session into one review. It recognizes common secret-bearing file names, including .env files, .npmrc, .pypirc, and key files such as *.pem and *.key, and marks changes to them as high-risk.

It deliberately does not snapshot gitignored files. If an agent writes to an ignored secret file during a session, Diffward lists that the file was written, but it can't show the contents or discard the change. That keeps secret values out of its snapshots, and it also means you need to open the file yourself to check what changed.

Diffward is not a secret scanner. It does not look for credential patterns inside ordinary source files, so an API key pasted into config.ts is a normal code change to it. The checks above still apply.

A short checklist

  • Which secret-bearing files exist in this project, and which are ignored?
  • Did the agent edit, create, or delete any of them?
  • Did any added line contain something that looks like a real credential?
  • Did anything change that could expose a secret indirectly, such as logging, fixtures, .gitignore, or build settings?
  • If a real secret was committed or pushed, has it been revoked first?

Conclusion

Most agent runs never go near your credentials, which is exactly why the ones that do are easy to wave through. Know where your secrets live, look at every change to those files and to anything that could print or publish them, and if something slips out, revoke it before you clean it up.