Yes, a secret typed into PowerShell can be saved in command history. PSReadLine lets you decide what gets saved with the AddToHistoryHandler option, which takes a script block that returns true to keep a line or false to skip it. Filtering helps, but moving secrets out of commands is safer.
What AddToHistoryHandler does
Microsoft's documentation for Set-PSReadLineOption lists an -AddToHistoryHandler parameter. You give it a script block that receives the typed line and returns a decision. One documented example prevents any command that starts with git from being saved. The block returns $false for those lines, which has the same effect as returning the SkipAdding value, and $true for everything else.
That is the whole mechanism. PSReadLine calls your block for each line, and your logic decides whether the line is stored.
A cautious filter pattern
You can adapt the documented example to skip lines that look like they carry a credential. Here is a sketch:
$ScriptBlock = {
param([string]$Line)
if ($Line -match 'password|token|secret|apikey|Authorization') {
return $false
}
return $true
}
Set-PSReadLineOption -AddToHistoryHandler $ScriptBlock
Put it in your PowerShell profile so it loads in every session. Test it by typing a harmless line that contains the word token, then pressing the up arrow in a new session to confirm it was not saved.
What this does not cover
A keyword filter is a net with holes. A secret pasted as a bare string with no telltale word will pass straight through. A filter also does nothing for a value you export into an environment variable on a line that does not match your pattern, or for output that prints a secret to the screen.
It also hides commands you might want to keep. Matching on the word token will drop harmless lines such as one that lists token scopes. Keep the pattern narrow enough that people do not switch the filter off out of annoyance.
Better options for secret input
Treat the filter as a backstop, and fix the cause:
- Prompt for secrets with a secure prompt rather than typing them as arguments.
- Use the tool's built-in sign-in so a token lives in a credential store rather than your command line.
- Read values from your password manager or a secrets manager at run time.
- Use short-lived credentials where the platform offers them.
If a secret did reach history, rotate it first. Editing history comes second, because the exposure already happened.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Does the handler run for every line?
Per the documentation it is a script block that decides whether each line is added to history. Test your own setup to confirm the behaviour on your PowerShell version.
Should I filter on the word password?
It is a reasonable start, but it will miss bare values. Treat it as a backstop, not a control.
Where do I put the setting?
In your PowerShell profile, so it applies to each new session.
Sources
Last reviewed: 19 October 2026.
