fix(redact): add GitLab and PyPI token prefixes to secret detection

[DevChiniwala]

Summary

KEY_PREFIXES in server/redact.ts covers content-shaped secrets that can appear in bot replies, tool titles, and permission cards — places where the key-name heuristic (isSecretName) does not apply. Two well-documented credential prefixes were missing:

• glpat- — GitLab personal access tokens. Always this prefix, documented by GitLab.
• pypi- — PyPI API tokens. Always this prefix, documented by PyPI.

Both meet the "high precision on purpose" criterion in the module header: they are unmistakably credentials, cannot match ordinary code or prose, and follow the same naming convention as the existing entries.

What changed

• Added two regex entries to KEY_PREFIXES in server/redact.ts, positioned between the existing npm_ and JWT patterns.
• Added two test cases to the content-shaped secret tests in server/redact.test.ts, following the existing split-prefix pattern that avoids the test file itself being redacted.

Test plan

• All 13 redact tests pass
• pnpm typecheck clean
• pnpm check:brand clean

[Copilot]

🟡 Changes recommended

The PyPI token regex is currently too permissive (high false-positive risk vs the module’s stated “high precision” goal) and should be tightened to the documented token format, with the corresponding test fixture updated.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the server-side secret redaction heuristics to recognize additional content-shaped credential prefixes that can appear in free-form text (bot replies, tool titles, permission cards), extending coverage beyond key-name-based detection.

Changes:

• Added glpat- detection to redact GitLab personal access tokens.
• Added pypi- detection to redact PyPI API tokens.
• Extended redactSecretsInText test coverage with new prefix fixtures built at runtime.

File summaries

File	Description
server/redact.ts	Adds new KEY_PREFIXES regex patterns for GitLab and PyPI token prefixes.
server/redact.test.ts	Adds new test cases ensuring redactSecretsInText masks the new token shapes.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[DivyamTalwar]

@DevChiniwala — thanks for this one too. Both prefixes are real gaps and the change is in the right place. server/redact.test.ts passes 13/13 locally.

One of the two needs tightening before I take it.

glpat- — correct as written

/\bglpat-[A-Za-z0-9_-]{20,}/g matches GitLab's PAT format exactly, and I couldn't produce a false positive against it. Nothing to change.

pypi- — over-matches ordinary text

{16,} is short enough that hyphenated prose collides with it. The character class includes -, so hyphens count toward the length:

input	{16,} (current)	{48,}
pypi-publishing-workflow	MATCH	—
pypi-mirror-configuration	MATCH	—
pypi-upload-action-v1	MATCH	—
pypi-trusted-publisher-github-action-config	MATCH	—
a real PyPI token (macaroon, ~150 chars)	MATCH	MATCH

Any transcript discussing Python packaging would get chewed up. That runs against the module's own stated contract, a few lines above your change:

High precision on purpose: a generic "long hex/base64" heuristic would rewrite real code in the transcript, so only shapes that are unmistakably credentials match.

Real PyPI tokens are macaroons — pypi- followed by ~150+ characters of base64url — so there's a lot of headroom to raise the floor without risking a miss.

Requested change

/\bpypi-[A-Za-z0-9_-]{48,}/g, // pypi api token

That clears all four false positives above and still matches a real token comfortably.

Your test fixture uses alpha.slice(0, 24), which won't reach 48 — it'll need lengthening alongside the regex. Something like ${alpha}${alpha} is plenty.

One coordination note

This and #33 both insert after the npm_ line in server/redact.ts and at the same spot in server/redact.test.ts. I confirmed they conflict with each other — whichever I merge first, the other will need a rebase. Nothing wrong with either; just so it isn't a surprise.

CI hasn't run yet — GitHub holds workflow runs for first-time contributors until a maintainer approves. I'll approve it.

Bump the pypi- threshold and the fixture and I'll take this.