Scan sessions for exposed credentials and surface findings (#327)

[mando]

Closes #327.

What

A deterministic, regex-based secret scanner runs at materialize time over each session's in-memory prompt/response text — no LLM call, no throttle, and independent of the retainText setting (the text is in memory at write time either way). Findings are stored in a new resolved_secret_findings table (schema v23 → v24 migration included).

A finding never contains the secret — only a category (aws_access_key, github_token, anthropic_api_key, openai_api_key, stripe_key, slack_token, private_key, jwt, generic_secret), a location (interaction + prompt/response slot), and a redacted hint (AKIA…WXYZ, the card-statement last-4 convention) so the user recognizes which credential it was.

Surfacing

• Session detail: warning banner listing each finding (kind, hint, prompt vs response) with a Dismiss action. Dismissal is anchored to the finding set's digest (resolved_sessions.secret_scan_dismissed, carried forward by materialize like is_hidden), so it lapses automatically when a re-scan finds something different. A dismissed banner collapses to a muted line with "Show again".
• Session list: red count badge on rows with undismissed findings.
• Recommendations: an "N sessions may contain exposed credentials" warning that leads the list, so the signal reaches users who never open the session.

Explicit decisions (the issue's open questions)

• Where it runs: inline in toMaterializeSessions, not a drain — it's free and deterministic, and a drain reading retained text back would go blind when retainText is off.
• Sync: findings stay local-only in v1 — push.ts never reads the table (the same structural guarantee resolved_interaction_text gets), so even the redacted locators can't cross the wire. A count-level org signal is a possible future decision, documented in the design doc.
• Rule set: small, high-precision subset in the spirit of gitleaks; the generic KEY=value rule is gated by length + Shannon entropy + a placeholder blocklist. Precision over recall so the banner stays trustworthy.
• Dismissal: digest-anchored acknowledge, per above.

MCP (/mcp) strips findings alongside firstPrompt when transcript access is off — findings are derived from transcript text, so they inherit its gate.

Verification

• 33 new tests: scanner rules/redaction/dedupe (test/secret-scan.test.ts), store persistence/dismissal/migration (test/secret-findings.test.ts, test/store.test.ts incl. a v23→v24 migration test), serve routes incl. CSRF + read-only drops (test/serve.test.ts), the recommendations rule (test/recommendations.test.ts).
• Full suite green (756 tests), tsc --noEmit clean for root + web/, build:web succeeds.
• End-to-end smoke test against a live serve: indexed a fixture session with synthetic keys, verified the detail payload, list badge, dismiss → banner/badge/recommendation all clear, undismiss, and the CSRF 403. Visually verified the banner and dismissed state in a browser.

Design doc: docs/internals/secret-scanning.md.

Fixes: #328

[mando]

Low: Session-level secret deduplication is not implemented

Location: src/indexing/secret-scan.ts:124-141

scanTextForSecrets creates a fresh seen set for each text chunk. scanSessionForSecrets calls it separately for every prompt and response, then concatenates the results. As a result, the same credential repeated in two interactions is emitted twice, despite the comment at lines 100-101 saying that a key repeated across prompts is kept only at its first location.

Reproduction at the PR head:

const key = "AKIA" + "Q3G5X7BDFHJKLMNP";
scanSessionForSecrets({
  interactions: [
    { seq: 0, promptText: key },
    { seq: 1, promptText: key },
  ],
});
// returns two findings with the same category and hint

This can inflate warning counts and exhaust MAX_FINDINGS_PER_SESSION before distinct credentials are reported. Please keep a session-level seen set, or deduplicate the accumulated findings by a stable rule/value key while preserving the first location.

[mando]

Low: Finding list has no explicit user-visible ordering

Location: web/src/components/SecretFindingsBanner.tsx:86-90

The banner renders a <ul> directly from findings.slice(0, 5). The source order is scanner rule order followed by interaction traversal, which is not an obvious ordering for users. This also conflicts with the repository UI rule that user-visible lists must be explicitly ordered and must not be presented as unordered lists.

Please choose and document an ordering, such as interaction sequence, prompt before response, then category and hint, and render an ordered or otherwise visibly ordered presentation.

[mando]

Fixed in eca4cb2 — the dedupe seen set is now shared across the whole session (passed from scanSessionForSecrets into each scanTextForSecrets call) instead of being recreated per chunk, so a credential repeated across interactions flags once at its first location. Added a regression test covering the exact repro.

[mando]

Fixed in 0a7b7a4 — the banner now sorts findings by interaction seq, then prompt before response, then category and hint (the scanner emits rule-order within a chunk; the user cares about where in the session a credential appeared), and renders an ordered <ol>. The ordering is documented on orderFindings.