secret_guard has no npm-token detector: _authToken=npm_... passes cleanly in block mode, including a verbatim .npmrc credential line #716

Summary

mutation_guard.secret_guard ships four detectors — github_token, private_key, aws_access_key, high_entropy_assignment — and they work well. But npm tokens are not among them, and they slip past block mode in every form, including a verbatim .npmrc credential line.

For an ecosystem whose primary publish target is npm, that is the one credential most likely to end up pasted into a release-tracking item.

Verified on 2026.7.25 with mutation_guard.secret_guard = "block".

Reproduction

With block mode active and confirmed working (a ghp_ token in the same field is rejected with mutation_secret_guard_blocked):

# all three ALLOWED — item created, no warning, exit 0
$ pm create --title "npm bare"       --description 'npm_1a2B3c4D5e6F7g8H9i0J1k2L3m4N5o6P7q8R'
$ pm create --title "npm assignment" --description 'NPM_TOKEN=npm_1a2B3c4D5e6F7g8H9i0J1k2L3m4N5o6P7q8R'
$ pm create --title "npm in npmrc"   --description '//registry.npmjs.org/:_authToken=npm_1a2B3c4D5e6F7g8H9i0J1k2L3m4N5o6P7q8R'

The third case is the canonical .npmrc line an agent would paste while debugging a publish failure. It is stored verbatim in the item and its history stream.

Control — the guard is otherwise active in the same workspace:

$ pm create --title "gh pat" --description 'github_pat_11ABCDEFG0abcdefghijkl_1a2B3c...'
  BLOCKED (github_token)
$ pm create --title "aws key" --description 'AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set in ci'
  BLOCKED (aws_access_key)

Note NPM_TOKEN=npm_... is an assignment of a 36-char random-looking value, yet high_entropy_assignment does not fire either — so there is no incidental coverage to fall back on. (That detector does fire on e.g. password = "Xq7Lm2Pv9Rt4Wz8Yc1Nb6Hj3Kd5Fg0Sa", so the gap looks specific to the npm_ shape rather than to assignments generally.)

Slack bot tokens are likewise undetected (xoxb-123456789012-1234567890123-AbCdEfGhIjKlMnOpQrStUvWx passes), which is relevant given the ecosystem ships pm-slack and pm-slack-standup.

Suggested resolution

Add detector rules alongside the existing four:

• npm_token — npm_[A-Za-z0-9]{36}, which covers the bare, assignment, and _authToken= forms in one pattern.
• slack_token — xox[baprs]- prefixed tokens.

Both are fixed, well-known prefixes with negligible false-positive risk, matching how github_token is already handled.

It would also help to expose the active rule set (pm config list or a --explain on the guard) so an operator can see which credential classes a workspace is actually protected against rather than inferring it from source.

Related: #715 (the guard's block mode is undiscoverable through pm config set --help in the first place).