residoo 0.4.5 → 0.4.6

package/README.md

@@ -82,6 +82,30 @@ precise about rather than lumping together:
   different set of choices, and its README is honest about its own tradeoffs
   too. Worth a look if broader source coverage matters more to you than a
   minimal dependency footprint.
+- **On verifying a found value is still live**, not just shaped like one:
+  the field splits into two real postures, and residoo picked a side.
+  [trufflehog](https://github.com/trufflesecurity/trufflehog) verifies
+  **by default**, an opt-out (`--no-verification`) rather than an opt-in,
+  across 700+ vendor-specific checks; that means a plain, unconfigured
+  trufflehog run makes network calls. gitleaks never added verification at
+  all and is now feature-complete (security patches only); its declared
+  successor, [betterleaks](https://github.com/betterleaks/betterleaks),
+  added it the other way: **off by default**, one global `--validation`
+  flag, each rule's own validate expression deciding whether and how it
+  calls out, with repeated occurrences of the same value deduped to one
+  request. agentsweep has none either, and is explicit about it: its own
+  README scores trufflehog's verification with a checkmark and its own
+  with an X, and states it is "fully offline, with zero network calls
+  during scanning or redacting" apart from an optional PyPI version-check
+  ping. residoo's `--verify` follows betterleaks' posture, not
+  trufflehog's: off by default, an explicit flag, and 27 vendors today
+  (still short of trufflehog's 700+) rather than every vendor its own
+  detection can name, deduped the same way betterleaks dedupes, and gated
+  the same way patterns.js's own detection rules are: only added where a
+  real, cited endpoint exists, not assumed by analogy to a similar vendor.
+  See [verify.js](src/verify.js) and
+  [What it does not do](#what-it-does-not-do) for exactly what it touches
+  and when.
 
 This isn't a gap Anthropic is planning to close upstream, either: a
 [request to scrub secrets from `~/.claude/projects` natively](https://github.com/anthropics/claude-code/issues/50014)
@@ -125,17 +149,27 @@ won't be built into the tool that writes it.
   discarded. See `src/jwtExpiry.js`.
 - **`--verify`** (opt-in, makes a real network call): asks a credential's own
   vendor whether it still authenticates, using the exact value found in your
-  transcript. Five vendors today: **AWS** (an access key id found paired with
+  transcript. 27 vendors today: **AWS** (an access key id found paired with
   its secret, checked via `sts:get-caller-identity`, the same free,
   read-only, permission-less call the AWS CLI and tools like aws-vault use
   for exactly this; shells out to your own `aws` CLI rather than
   reimplementing AWS request signing, since residoo ships zero runtime
   dependencies and a subtly wrong signing implementation would silently
-  report real keys as invalid, worse than not checking), and **Slack,
-  OpenAI, Anthropic, GitHub** (a direct API call to each vendor's own free
-  "list what I can see" endpoint, no CLI needed, no request signing to get
-  wrong). A verified-active credential is escalated to "rotate immediately";
-  a verified-invalid one is reported as already dead, no action needed, and
+  report real keys as invalid, worse than not checking), and **26 more via a
+  direct API call each, no CLI needed**: Slack, OpenAI, Anthropic, GitHub,
+  Hugging Face, Replicate, DigitalOcean, Pinecone, SendGrid, Groq, xAI,
+  OpenRouter, Stripe, npm, Notion, GitLab, Supabase (management tokens
+  only, project-scoped anon/service_role keys need a project URL residoo
+  doesn't have), ElevenLabs, CircleCI, Airtable, Cloudflare, Heroku,
+  Netlify, Linear, Telegram, and Discord webhooks. Every one of the 27 was
+  researched against that vendor's own current docs or a named open-source
+  scanner's real, running verifier code before being wired up, the same bar
+  as the first five; a real, sourced reason (no free endpoint, needs
+  external context the credential doesn't carry, or a paired credential
+  residoo doesn't yet detect together) is why some detected credential
+  types aren't wired to `--verify` at all, not an oversight. A
+  verified-active credential is escalated to "rotate immediately"; a
+  verified-invalid one is reported as already dead, no action needed, and
   sorted out of the way. Off by default; every environment variable the
   `aws` CLI reads is built from scratch, never inherited, so it can never
   fall back to your own real AWS profile. See `src/verify.js`.
@@ -150,10 +184,10 @@ won't be built into the tool that writes it.
   preview, never the real value, including in `--json` mode. A decoded or
   rejoined secret is redacted exactly like a plain one.
 - On an interactive terminal, prints who it is and where it lives before
-  scanning starts (`residoo v0.4.5 · find secrets your AI coding agent left
+  scanning starts (`residoo v0.4.6 · find secrets your AI coding agent left
   on disk` plus the repo URL), then a live spinner naming the current file
   as it scans. Every report also opens with the exact version and timestamp
-  it was run with (`residoo v0.4.5 · scanned 2026-01-01 12:00`; `--json`
+  it was run with (`residoo v0.4.6 · scanned 2026-01-01 12:00`; `--json`
   carries the same as `residooVersion`/`scannedAt`), so a report pasted or
   screenshotted later never leaves you guessing which build produced it.
   When there are findings, the report closes with a "Next steps" pointer to
@@ -384,7 +418,7 @@ As a GitHub Action (this repository doubles as a composite action):
 ```yaml
 steps:
   - uses: actions/checkout@v4
-  - uses: dandovdub/residoo@v0.4.5
+  - uses: dandovdub/residoo@v0.4.6
 ```
 
 As a pre-commit hook:
@@ -392,7 +426,7 @@ As a pre-commit hook:
 ```yaml
 repos:
   - repo: https://github.com/dandovdub/residoo
-    rev: v0.4.5
+    rev: v0.4.6
     hooks:
       - id: residoo
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "residoo",
-  "version": "0.4.5",
+  "version": "0.4.6",
   "description": "Find secrets leaking through your AI coding agent's session history. Zero network calls in the scan path, zero dependencies.",
   "license": "MIT",
   "author": "CloudRoam (https://cloudroam.io)",

package/src/cli.js

@@ -57,9 +57,9 @@ const HELP = `residoo: find secrets leaking through your AI agent's session hist
   Scanning makes NO network calls by default and changes nothing on disk.
   Findings are redacted in every output format. The one opt-in exception is
   --verify, which asks a credential's own vendor whether it still
-  authenticates (AWS, Slack, OpenAI, Anthropic, GitHub today); see below.
-  Sealing (--seal) writes NEW encrypted files only. It never modifies or
-  deletes anything that already exists.
+  authenticates (27 vendors today, see below). Sealing (--seal) writes NEW
+  encrypted files only. It never modifies or deletes anything that already
+  exists.
 
 Usage:
   residoo scan [options]
@@ -102,17 +102,19 @@ Scan options:
   --verify                ask the credential's own vendor whether it still
                           authenticates, using the exact value found in
                           your transcript. THIS MAKES A REAL NETWORK CALL.
-                          Off by default. Five vendors today:
-                            AWS: every access key id found paired with its
-                            secret (see Rotation below) is checked via
-                            sts:get-caller-identity. Needs the aws CLI on
-                            PATH; residoo shells out to it rather than
-                            reimplementing AWS request signing.
-                            Slack: every token via auth.test.
-                            OpenAI, Anthropic, GitHub: every key/token via
-                            that vendor's own models/user listing endpoint.
-                          All four non-AWS vendors are a direct, dependency-
-                          free API call, no CLI needed. A verified-invalid
+                          Off by default. 27 vendors today: AWS (an access
+                          key id found paired with its secret, see Rotation
+                          below, checked via sts:get-caller-identity;
+                          needs the aws CLI on PATH, residoo shells out to
+                          it rather than reimplementing AWS request
+                          signing) and 26 more via a direct, dependency-
+                          free API call each, no CLI needed: Slack, OpenAI,
+                          Anthropic, GitHub, Hugging Face, Replicate,
+                          DigitalOcean, Pinecone, SendGrid, Groq, xAI,
+                          OpenRouter, Stripe, npm, Notion, GitLab, Supabase
+                          (management tokens only), ElevenLabs, CircleCI,
+                          Airtable, Cloudflare, Heroku, Netlify, Linear,
+                          Telegram, Discord webhooks. A verified-invalid
                           credential is reported as already dead, not as
                           something to rotate; a JWT's own signed exp claim
                           is checked locally with no network call at all,
@@ -572,7 +574,17 @@ async function main(argv) {
   }
 
   const progress = makeProgressReporter(noColor);
-  const result = await scan({ sources, includeNoisy, includeSuppressed, onProgress: progress.onProgress, verify });
+  const result = await scan({
+    sources, includeNoisy, includeSuppressed, verify,
+    onProgress: progress.onProgress,
+    // Clears the spinner's last frame before --verify's own stderr lines
+    // print; without this the last spinner line sits uncleared on screen
+    // and the first --verify line gets appended directly onto its end with
+    // no separator (a real rendering bug caught live). Safe to call twice:
+    // stop() is idempotent, and the normal post-scan progress.stop() below
+    // still runs regardless of whether this fired.
+    onBeforeVerify: progress.stop,
+  });
   progress.stop();
   const integrity = wantsIntegrity ? runIntegrity() : null;
   const rotation = renderRotation(result.findings, acks, dismissed);

package/src/patterns.js

@@ -105,12 +105,44 @@ const PATTERNS = [
     re: /\bpplx-[A-Za-z0-9]{40,200}\b/g },
   { id: "replicate_token", label: "Replicate API token", confidence: "high",
     re: /\br8_[0-9A-Za-z_-]{37}\b/g },
+  // Confirmed via ElevenLabs' own docs (elevenlabs.io/docs/api-reference/authentication):
+  // sk_ + 48 hex. Distinct from the sk-/sk_live_/sk_test_ families above —
+  // underscore not hyphen, and no "_live_"/"_test_" substring, so it cannot
+  // collide with any of them.
+  { id: "elevenlabs_key", label: "ElevenLabs API key", confidence: "high",
+    re: /\bsk_[a-f0-9]{48}\b/g },
 
   // ── Cloud / infra ──────────────────────────────────────────────────────
   { id: "digitalocean_token", label: "DigitalOcean access token", confidence: "high",
     re: /\b(?:dop|doo|dor)_v1_[a-f0-9]{64}\b/g },
   { id: "supabase_token", label: "Supabase personal access token", confidence: "high",
     re: /\bsbp_[a-z0-9]{40}\b/g },
+  // Current CircleCI PAT format only (CCIPAT_<22 alnum>_<40 hex>, confirmed
+  // via circleci.com/docs/api/v2). The legacy format is a bare 40-char hex
+  // string with no prefix at all — nowhere near specific enough to be a
+  // vendor signal, so deliberately left out, same reasoning as Vault's
+  // legacy "s." format above.
+  { id: "circleci_token", label: "CircleCI personal API token", confidence: "high",
+    re: /\bCCIPAT_[A-Za-z0-9]{22}_[a-f0-9]{40}\b/g },
+  // Confirmed via airtable.com/developers/web/api: pat + 14 alnum + "." + 64 hex.
+  { id: "airtable_token", label: "Airtable personal access token", confidence: "high",
+    re: /\bpat[A-Za-z0-9]{14}\.[a-f0-9]{64}\b/g },
+  // Current Cloudflare API Token format only (cfat_/cfut_, confirmed via
+  // developers.cloudflare.com). The legacy format is a bare 40-char string
+  // with no prefix, left out for the same reason as CircleCI's legacy form.
+  { id: "cloudflare_api_token", label: "Cloudflare API token", confidence: "high",
+    re: /\bcf[au]t_[a-zA-Z0-9]{40}[a-f0-9]{8}\b/g },
+  // Current Heroku API key format only (HRKU-AA + 58 chars, confirmed via
+  // Heroku's own help docs). The legacy format is a bare UUID, left out:
+  // "any UUID-shaped string" is exactly the noisy, unspecific shape this
+  // file's header says to avoid.
+  { id: "heroku_api_key", label: "Heroku API key", confidence: "high",
+    re: /\bHRKU-AA[0-9a-zA-Z_-]{58}\b/g },
+  // Current Netlify PAT format only (nfp_ + 36, confirmed via trufflehog's
+  // live netlify/v2 detector). The legacy format is a bare 43-45 char
+  // opaque string with no prefix, left out for the same reason as above.
+  { id: "netlify_token", label: "Netlify personal access token", confidence: "high",
+    re: /\bnfp_[a-zA-Z0-9_]{36}\b/g },
   { id: "vault_token", label: "HashiCorp Vault service token", confidence: "high",
     // Vault 1.10+ format only (hvs.<90-120 chars>). The pre-1.10 legacy
     // format is a bare "s." + 18-40 chars — "s." is nowhere near specific

package/src/report.js

@@ -85,7 +85,14 @@ function makeProgressReporter(noColor) {
     const label = `scanning ${source}… ${count} file${count === 1 ? "" : "s"}  ${safeBasename(file)}`;
     write(paint(c.bold + c.cyan, SPINNER_FRAMES[frame]) + " " + paint(c.dim, label), 2 + label.length);
   };
-  const stop = () => { if (lastLineLen > 0) process.stderr.write("\r" + " ".repeat(lastLineLen) + "\r"); };
+  // Idempotent: a caller may legitimately stop() more than once (scan.js's
+  // onBeforeVerify calls it before --verify's own stderr lines, and the
+  // normal post-scan call still follows); lastLineLen resets to 0 so a
+  // second call is a true no-op, not a second blank-line clear.
+  const stop = () => {
+    if (lastLineLen > 0) process.stderr.write("\r" + " ".repeat(lastLineLen) + "\r");
+    lastLineLen = 0;
+  };
   return { onProgress, stop };
 }
 

package/src/rotation.js

@@ -435,6 +435,19 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Disabling stops all API requests with that token immediately.",
   },
+  // Fetched https://elevenlabs.io/docs/api-reference/authentication
+  // (2026-09-03): keys are managed and deleted from the Profile + API keys
+  // page in the ElevenLabs dashboard.
+  elevenlabs_key: {
+    label: "ElevenLabs API key",
+    consolePath: "elevenlabs.io > Profile + API keys",
+    steps: [
+      "Open Profile + API keys in the ElevenLabs dashboard",
+      "Delete the leaked key",
+      "Create a replacement and update the applications using it",
+    ],
+    revokeNote: "A key grants full account access (voices, generations, billing); deletion is immediate.",
+  },
 
   // ── Cloud / infra ─────────────────────────────────────────────────────
   // docs.digitalocean.com/reference/api/create-personal-access-token/
@@ -491,6 +504,70 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Revoking immediately removes the token's access to every vault the service account could reach.",
   },
+  // Fetched https://circleci.com/docs/managing-api-tokens/ (2026-09-03):
+  // Personal API Tokens tab under User Settings, revoke deletes it
+  // immediately.
+  circleci_token: {
+    label: "CircleCI personal API token",
+    consolePath: "circleci.com > User Settings > Personal API Tokens",
+    steps: [
+      "Open Personal API Tokens under your CircleCI user settings",
+      "Revoke the leaked token",
+      "Create a replacement and update whatever used the old one",
+    ],
+    revokeNote: "Revocation is immediate; the token stops authenticating on the next request.",
+  },
+  // Fetched https://airtable.com/developers/web/guides/personal-access-tokens
+  // (2026-09-03): tokens are managed and deleted from the Personal access
+  // tokens page in the Airtable developer hub (airtable.com/create/tokens).
+  airtable_token: {
+    label: "Airtable personal access token",
+    consolePath: "airtable.com/create/tokens",
+    steps: [
+      "Open the Personal access tokens page in the developer hub",
+      "Delete the leaked token",
+      "Create a replacement scoped only to what your integration needs",
+    ],
+    revokeNote: "Deletion is immediate and applies to every base the token could reach.",
+  },
+  // Fetched https://developers.cloudflare.com/fundamentals/api/get-started/create-token/
+  // (2026-09-03): tokens are managed and revoked from My Profile > API
+  // Tokens.
+  cloudflare_api_token: {
+    label: "Cloudflare API token",
+    consolePath: "dash.cloudflare.com > My Profile > API Tokens",
+    steps: [
+      "Open My Profile > API Tokens in the Cloudflare dashboard",
+      "Roll (regenerate) or delete the leaked token",
+      "Update whatever used the old token with the replacement",
+    ],
+    revokeNote: "Deleting is immediate; a scoped token only affects the zones/permissions it was granted.",
+  },
+  // Fetched https://help.heroku.com/PBGP6IDE (2026-09-03): API keys are
+  // regenerated from Account Settings, which invalidates the previous key.
+  heroku_api_key: {
+    label: "Heroku API key",
+    consolePath: "dashboard.heroku.com/account > API Key",
+    steps: [
+      "Open Account Settings in the Heroku dashboard",
+      "Regenerate the API key (this immediately invalidates the old one)",
+      "Update the CLI/CI configs and tools that used the old key",
+    ],
+    revokeNote: "Regeneration is the only way to invalidate a Heroku API key; there is no separate revoke action.",
+  },
+  // Fetched https://docs.netlify.com/api/get-started/#authentication
+  // (2026-09-03): personal access tokens are managed from User settings >
+  // Applications > Personal access tokens.
+  netlify_token: {
+    label: "Netlify personal access token",
+    consolePath: "app.netlify.com/user/applications#personal-access-tokens",
+    steps: [
+      "Open User settings > Applications > Personal access tokens",
+      "Delete the leaked token",
+      "Create a replacement and update whatever used the old one",
+    ],
+    revokeNote: "Deletion is immediate; the token stops authenticating on the next request.",
+  },
 
   // ── Comms / SaaS ──────────────────────────────────────────────────────
   // The user-facing support article (support.discord.com article 228383668)

package/src/scan.js

@@ -9,6 +9,11 @@ const { decodeJwtExpiryMs } = require("./jwtExpiry");
 const {
   isAwsCliAvailable, verifyAwsCredential,
   verifySlackToken, verifyOpenAiKey, verifyAnthropicKey, verifyGithubToken,
+  verifyHuggingFaceToken, verifyReplicateToken, verifyDigitalOceanToken, verifyPineconeKey,
+  verifySendgridKey, verifyGroqKey, verifyXaiKey, verifyOpenRouterKey, verifyStripeKey, verifyNpmToken,
+  verifyNotionToken, verifyGitlabToken, verifySupabaseToken, verifyElevenLabsKey,
+  verifyCircleciToken, verifyAirtableToken, verifyCloudflareToken, verifyHerokuKey,
+  verifyNetlifyToken, verifyLinearKey, verifyTelegramToken, verifyDiscordWebhook,
 } = require("./verify");
 
 // Never verify more than this many distinct credentials of ONE vendor in a
@@ -20,17 +25,69 @@ const MAX_VERIFICATIONS_PER_VENDOR = 10;
 // Every vendor whose credential is a single, unpaired bearer token: no
 // AWS-style "two halves make one credential" pairing step, so these all
 // share one collection/verification path below (see pendingSimpleVerifications).
+// Deliberately NOT here despite being detected: google_api_key (a key can
+// belong to any Google product; testing it against one product's endpoint
+// would misreport a valid key for a DIFFERENT product as invalid) and
+// perplexity_key (no free, side-effect-free endpoint exists at all). See
+// verify.js's own header comment for the fuller reasoning, including the
+// vendors deferred rather than rushed (PlanetScale, Fly.io).
 const SIMPLE_VERIFY_FNS = {
   slack_token: verifySlackToken,
   openai_key: verifyOpenAiKey,
   anthropic_key: verifyAnthropicKey,
   github_pat: verifyGithubToken,
+  huggingface_token: verifyHuggingFaceToken,
+  replicate_token: verifyReplicateToken,
+  digitalocean_token: verifyDigitalOceanToken,
+  pinecone_key: verifyPineconeKey,
+  sendgrid_key: verifySendgridKey,
+  groq_key: verifyGroqKey,
+  xai_key: verifyXaiKey,
+  openrouter_key: verifyOpenRouterKey,
+  stripe_key: verifyStripeKey,
+  stripe_test_key: verifyStripeKey,
+  npm_token: verifyNpmToken,
+  notion_token: verifyNotionToken,
+  gitlab_pat: verifyGitlabToken,
+  supabase_token: verifySupabaseToken,
+  elevenlabs_key: verifyElevenLabsKey,
+  circleci_token: verifyCircleciToken,
+  airtable_token: verifyAirtableToken,
+  cloudflare_api_token: verifyCloudflareToken,
+  heroku_api_key: verifyHerokuKey,
+  netlify_token: verifyNetlifyToken,
+  linear_key: verifyLinearKey,
+  telegram_bot_token: verifyTelegramToken,
+  discord_webhook: verifyDiscordWebhook,
 };
 const SIMPLE_VERIFY_VENDOR_LABEL = {
   slack_token: "Slack's auth.test",
   openai_key: "OpenAI's models endpoint",
   anthropic_key: "Anthropic's models endpoint",
   github_pat: "GitHub's user endpoint",
+  huggingface_token: "Hugging Face's whoami endpoint",
+  replicate_token: "Replicate's account endpoint",
+  digitalocean_token: "DigitalOcean's account endpoint",
+  pinecone_key: "Pinecone's indexes endpoint",
+  sendgrid_key: "SendGrid's scopes endpoint",
+  groq_key: "Groq's models endpoint",
+  xai_key: "xAI's api-key endpoint",
+  openrouter_key: "OpenRouter's key endpoint",
+  stripe_key: "Stripe's balance endpoint",
+  stripe_test_key: "Stripe's balance endpoint",
+  npm_token: "npm's whoami endpoint",
+  notion_token: "Notion's users endpoint",
+  gitlab_pat: "GitLab's user endpoint",
+  supabase_token: "Supabase's projects endpoint",
+  elevenlabs_key: "ElevenLabs' user endpoint",
+  circleci_token: "CircleCI's me endpoint",
+  airtable_token: "Airtable's whoami endpoint",
+  cloudflare_api_token: "Cloudflare's token-verify endpoint",
+  heroku_api_key: "Heroku's account endpoint",
+  netlify_token: "Netlify's sites endpoint",
+  linear_key: "Linear's GraphQL API",
+  telegram_bot_token: "Telegram's getMe endpoint",
+  discord_webhook: "Discord's webhook-info endpoint",
 };
 
 // Rule ids that findPairedSecret's window search applies to (see pairing.js):
@@ -154,7 +211,7 @@ function safeName(file) { return path.basename(file); }
  * absolute path can itself carry a username or a project name the rest of
  * this report is careful never to print.
  */
-async function scan({ sources, includeNoisy = false, includeSuppressed = false, onProgress = null, verify = false } = {}) {
+async function scan({ sources, includeNoisy = false, includeSuppressed = false, onProgress = null, verify = false, onBeforeVerify = null } = {}) {
   const rules = includeNoisy ? PATTERNS.concat(NOISY_PATTERNS) : PATTERNS;
   // The decode pass (see decode.js) only applies high-confidence, vendor-
   // prefixed rules to decoded bytes: random binary that decodes to printable
@@ -492,6 +549,20 @@ async function scan({ sources, includeNoisy = false, includeSuppressed = false,
   // distinct credential, one at a time (not concurrent), so this is the one
   // place a scan's wall-clock time depends on something other than disk
   // I/O; that tradeoff only exists when a caller explicitly asked for it.
+  //
+  // onBeforeVerify exists so a caller with its own stderr chatter (the
+  // progress spinner) can clear it first: this pass writes its own stderr
+  // lines below, and the spinner's own stop() doesn't run until scan()
+  // fully returns, which is AFTER those lines have already printed. Without
+  // this, the last spinner frame sits uncleared on screen and the first
+  // --verify line gets appended directly onto the end of it with no
+  // separator, a real rendering bug caught live. Only called when there is
+  // actually something to verify, so a plain --verify with nothing to check
+  // never clears a spinner line for no reason.
+  const anyPending = pendingAwsVerifications.size > 0 ||
+    [...pendingSimpleVerifications.values()].some((byValue) => byValue.size > 0);
+  if (verify && anyPending && typeof onBeforeVerify === "function") onBeforeVerify();
+
   // Same field names (verified/verifiedDetail) regardless of which vendor
   // produced the result: rotation.js and report.js render them identically,
   // and the finding's own ruleId already says which vendor answered.

package/src/verify.js

@@ -199,13 +199,25 @@ async function verifySlackToken(token, { fetchFn = fetch, timeoutMs = DEFAULT_TI
  * Shared implementation for every vendor below Slack: a plain GET to a
  * free, side-effect-free, already-authenticated endpoint (each vendor's own
  * "list what I can see" call), where the HTTP status code alone says
- * whether the credential authenticated. 200 is active; 401/403 is a real
- * rejection; anything else (429 rate limited, 5xx, a network failure) is
- * inconclusive, never guessed as either active or invalid. Slack needed its
- * own function above because its auth.test always returns HTTP 200 and
- * signals failure inside the JSON body instead.
+ * whether the credential authenticated. 200 is active by default; 401/403
+ * is a real rejection by default; anything else (429 rate limited, 5xx, a
+ * network failure) is inconclusive, never guessed as either active or
+ * invalid. Slack needed its own function above because its auth.test
+ * always returns HTTP 200 and signals failure inside the JSON body
+ * instead.
+ *
+ * invalidStatuses/activeExtra override the defaults for the handful of
+ * vendors whose docs document a DIFFERENT meaning for a given code: Discord
+ * signals a dead webhook with 404, not 401/403; Pinecone, SendGrid, and
+ * GitLab each document 403 as "the credential is real but this specific
+ * call is out of scope," not "dead" — treating that as invalid would be
+ * exactly the false-negative-in-the-dangerous-direction failure this
+ * module exists to avoid, so those three pass 403 in activeExtra instead.
  */
-async function verifyByStatusCode(vendorName, url, buildHeaders, { fetchFn = fetch, timeoutMs = DEFAULT_TIMEOUT_MS } = {}) {
+async function verifyByStatusCode(vendorName, url, buildHeaders, {
+  fetchFn = fetch, timeoutMs = DEFAULT_TIMEOUT_MS,
+  invalidStatuses = [401, 403], activeExtra = [],
+} = {}) {
   let res;
   try {
     res = await fetchFn(url, {
@@ -216,10 +228,10 @@ async function verifyByStatusCode(vendorName, url, buildHeaders, { fetchFn = fet
   } catch (e) {
     return { status: "error", detail: `could not reach ${vendorName} (${sanitizeDetail(e && e.message)})` };
   }
-  if (res.status === 200) {
+  if (res.status === 200 || activeExtra.includes(res.status)) {
     return { status: "active", detail: `${vendorName} accepted this key` };
   }
-  if (res.status === 401 || res.status === 403) {
+  if (invalidStatuses.includes(res.status)) {
     return { status: "invalid", detail: `${vendorName} rejected this key (HTTP ${res.status})` };
   }
   return { status: "error", detail: `could not verify: HTTP ${res.status} from ${vendorName}` };
@@ -260,7 +272,221 @@ function verifyGithubToken(token, opts) {
   return verifyByStatusCode("GitHub", githubUserUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
 }
 
+// ── The rest of this file: 18 more vendors added after researching ~65
+// candidates against real vendor docs and open-source scanner source (see
+// the project's verification coverage research). Each one below already
+// has a residoo detection rule (src/patterns.js) with a specific enough
+// prefix that wiring it to a vendor is safe; several confirmed-viable
+// vendors from that research are deliberately NOT here, for reasons worth
+// stating precisely rather than silently omitting:
+//   - google_api_key, perplexity_key: DETECTED, but not wired. A Google API
+//     key can belong to any Google product (Maps, Firebase, Gemini, ...),
+//     and residoo's detection can't tell which; testing it against
+//     Gemini's endpoint specifically would report a perfectly valid Maps
+//     key as "invalid" — the exact false-negative-in-the-dangerous-
+//     direction failure this file exists to avoid. Perplexity has no free,
+//     side-effect-free endpoint at all (only a paid /chat/completions).
+//   - Cohere, Mistral, Together AI, Fireworks, DeepSeek: not detected in
+//     the first place (see patterns.js's own comment on this), so wiring a
+//     verifier would be dead code — verification needs detection first.
+//   - PlanetScale, Fly.io: real, confirmed endpoints, deliberately deferred
+//     rather than rushed. PlanetScale's auth header needs BOTH the token
+//     id and the secret together, a paired-credential shape residoo has no
+//     detection rule for (only the secret's pscale_tkn_ prefix is
+//     detected). Fly.io needs one of two different Authorization header
+//     schemes depending on which of two token prefixes was found (a plain
+//     Bearer header for one, the literal string "FlyV1 <token>" for the
+//     other) layered on top of a GraphQL body check — real, but more
+//     engineering than the rest of this batch, better done as its own
+//     careful pass than folded in here.
+
+function huggingfaceUrl() { return process.env.RESIDOO_TEST_HUGGINGFACE_API_URL || "https://huggingface.co/api/whoami-v2"; }
+function sendgridUrl() { return process.env.RESIDOO_TEST_SENDGRID_API_URL || "https://api.sendgrid.com/v3/scopes"; }
+function replicateUrl() { return process.env.RESIDOO_TEST_REPLICATE_API_URL || "https://api.replicate.com/v1/account"; }
+function digitaloceanUrl() { return process.env.RESIDOO_TEST_DIGITALOCEAN_API_URL || "https://api.digitalocean.com/v2/account"; }
+function pineconeUrl() { return process.env.RESIDOO_TEST_PINECONE_API_URL || "https://api.pinecone.io/indexes"; }
+function groqUrl() { return process.env.RESIDOO_TEST_GROQ_API_URL || "https://api.groq.com/openai/v1/models"; }
+function xaiUrl() { return process.env.RESIDOO_TEST_XAI_API_URL || "https://api.x.ai/v1/api-key"; }
+function openrouterUrl() { return process.env.RESIDOO_TEST_OPENROUTER_API_URL || "https://openrouter.ai/api/v1/key"; }
+function stripeUrl() { return process.env.RESIDOO_TEST_STRIPE_API_URL || "https://api.stripe.com/v1/balance"; }
+function npmUrl() { return process.env.RESIDOO_TEST_NPM_API_URL || "https://registry.npmjs.org/-/whoami"; }
+function notionUrl() { return process.env.RESIDOO_TEST_NOTION_API_URL || "https://api.notion.com/v1/users"; }
+function gitlabUrl() { return process.env.RESIDOO_TEST_GITLAB_API_URL || "https://gitlab.com/api/v4/user"; }
+function supabaseUrl() { return process.env.RESIDOO_TEST_SUPABASE_API_URL || "https://api.supabase.com/v1/projects"; }
+function elevenlabsUrl() { return process.env.RESIDOO_TEST_ELEVENLABS_API_URL || "https://api.elevenlabs.io/v1/user"; }
+function circleciUrl() { return process.env.RESIDOO_TEST_CIRCLECI_API_URL || "https://circleci.com/api/v2/me"; }
+function airtableUrl() { return process.env.RESIDOO_TEST_AIRTABLE_API_URL || "https://api.airtable.com/v0/meta/whoami"; }
+function cloudflareUrl() { return process.env.RESIDOO_TEST_CLOUDFLARE_API_URL || "https://api.cloudflare.com/client/v4/user/tokens/verify"; }
+function herokuUrl() { return process.env.RESIDOO_TEST_HEROKU_API_URL || "https://api.heroku.com/account"; }
+function netlifyUrl() { return process.env.RESIDOO_TEST_NETLIFY_API_URL || "https://api.netlify.com/api/v1/sites"; }
+function linearUrl() { return process.env.RESIDOO_TEST_LINEAR_API_URL || "https://api.linear.app/graphql"; }
+function telegramUrl(token) {
+  const base = process.env.RESIDOO_TEST_TELEGRAM_API_URL || "https://api.telegram.org";
+  return `${base}/bot${token}/getMe`;
+}
+
+function verifyHuggingFaceToken(token, opts) {
+  return verifyByStatusCode("Hugging Face", huggingfaceUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+function verifyReplicateToken(token, opts) {
+  return verifyByStatusCode("Replicate", replicateUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+function verifyDigitalOceanToken(token, opts) {
+  return verifyByStatusCode("DigitalOcean", digitaloceanUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+/** 403 from SendGrid's own /v3/scopes means the key is real but lacks the scope for this call, not that it's dead — trufflehog's own detector treats it identically. */
+function verifySendgridKey(key, opts) {
+  return verifyByStatusCode("SendGrid", sendgridUrl(), () => ({ Authorization: `Bearer ${key}` }), { ...opts, activeExtra: [403] });
+}
+/** 403 from Pinecone means the key is real but lacks control-plane permissions, not that it's dead. */
+function verifyPineconeKey(key, opts) {
+  return verifyByStatusCode("Pinecone", pineconeUrl(), () => ({ "Api-Key": key }), { ...opts, activeExtra: [403] });
+}
+function verifyGroqKey(key, opts) {
+  return verifyByStatusCode("Groq", groqUrl(), () => ({ Authorization: `Bearer ${key}` }), opts);
+}
+function verifyXaiKey(key, opts) {
+  return verifyByStatusCode("xAI", xaiUrl(), () => ({ Authorization: `Bearer ${key}` }), opts);
+}
+function verifyOpenRouterKey(key, opts) {
+  return verifyByStatusCode("OpenRouter", openrouterUrl(), () => ({ Authorization: `Bearer ${key}` }), opts);
+}
+/** Stripe: HTTP Basic auth, the key as username and an empty password — NOT a Bearer header. */
+function verifyStripeKey(key, opts) {
+  return verifyByStatusCode("Stripe", stripeUrl(), () => ({
+    Authorization: `Basic ${Buffer.from(`${key}:`).toString("base64")}`,
+  }), opts);
+}
+function verifyNpmToken(token, opts) {
+  return verifyByStatusCode("npm", npmUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+/** Notion requires an explicit API version header on every request, regardless of endpoint. */
+function verifyNotionToken(token, opts) {
+  return verifyByStatusCode("Notion", notionUrl(), () => ({
+    Authorization: `Bearer ${token}`,
+    "Notion-Version": "2022-06-28",
+  }), opts);
+}
+/**
+ * GitLab's own docs recommend PRIVATE-TOKEN over a Bearer header for
+ * personal access tokens. 403 there means valid token, wrong scope for
+ * this specific call (trufflehog's own detector treats it the same way,
+ * except when the response body says the account itself is blocked — a
+ * rare enough edge case, and one where reporting "active" instead of
+ * "invalid" is the safe direction to be wrong in, that this doesn't
+ * special-case it further).
+ */
+function verifyGitlabToken(token, opts) {
+  return verifyByStatusCode("GitLab", gitlabUrl(), () => ({ "PRIVATE-TOKEN": token }), { ...opts, activeExtra: [403] });
+}
+/** The Supabase Management API personal access token (sbp_ prefix) only — project-scoped anon/service_role keys need a project URL residoo doesn't have and are not verifiable this way. */
+function verifySupabaseToken(token, opts) {
+  return verifyByStatusCode("Supabase", supabaseUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+function verifyElevenLabsKey(key, opts) {
+  return verifyByStatusCode("ElevenLabs", elevenlabsUrl(), () => ({ "xi-api-key": key }), opts);
+}
+function verifyCircleciToken(token, opts) {
+  return verifyByStatusCode("CircleCI", circleciUrl(), () => ({ "Circle-Token": token }), opts);
+}
+function verifyAirtableToken(token, opts) {
+  return verifyByStatusCode("Airtable", airtableUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+/**
+ * Cloudflare's own /user/tokens/verify endpoint exists for exactly this
+ * check (its whole purpose, per Cloudflare's docs, is confirming a
+ * token's validity), so treating any HTTP 200 from THIS SPECIFIC endpoint
+ * as active is a documented guarantee, not an approximation the way it
+ * would be for a generic "list resources" endpoint.
+ */
+function verifyCloudflareToken(token, opts) {
+  return verifyByStatusCode("Cloudflare", cloudflareUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+function verifyHerokuKey(key, opts) {
+  return verifyByStatusCode("Heroku", herokuUrl(), () => ({
+    Authorization: `Bearer ${key}`,
+    Accept: "application/vnd.heroku+json; version=3",
+  }), opts);
+}
+function verifyNetlifyToken(token, opts) {
+  return verifyByStatusCode("Netlify", netlifyUrl(), () => ({ Authorization: `Bearer ${token}` }), opts);
+}
+
+/**
+ * Linear: a GraphQL API, one POST endpoint for everything, not a plain GET.
+ * A GraphQL server can answer HTTP 200 even for some authorization-level
+ * failures (the error lives in the response body's `errors` field, not the
+ * status code), so this checks for a populated `data.viewer` instead of
+ * trusting status code alone — the same reasoning that gave Slack its own
+ * function above. Linear's own docs confirm no "Bearer" prefix on personal
+ * API keys (Bearer is reserved for OAuth tokens).
+ */
+async function verifyLinearKey(key, { fetchFn = fetch, timeoutMs = DEFAULT_TIMEOUT_MS } = {}) {
+  let res;
+  try {
+    res = await fetchFn(linearUrl(), {
+      method: "POST",
+      headers: { Authorization: key, "Content-Type": "application/json" },
+      body: JSON.stringify({ query: "{ viewer { id } }" }),
+      signal: AbortSignal.timeout(timeoutMs),
+    });
+  } catch (e) {
+    return { status: "error", detail: `could not reach Linear (${sanitizeDetail(e && e.message)})` };
+  }
+  if (res.status === 401) return { status: "invalid", detail: "Linear rejected this key (HTTP 401)" };
+  let body;
+  try {
+    body = await res.json();
+  } catch {
+    return { status: "error", detail: `Linear returned a non-JSON response (HTTP ${res.status})` };
+  }
+  if (body && body.data && body.data.viewer && body.data.viewer.id) {
+    return { status: "active", detail: "Linear accepted this key" };
+  }
+  return { status: "error", detail: `could not verify: ${sanitizeDetail(JSON.stringify(body && body.errors)).slice(0, 120) || `HTTP ${res.status}`}` };
+}
+
+/**
+ * Telegram: the token is embedded directly in the URL path, not a header,
+ * and (like Slack) the response is always HTTP 200 with an `ok` boolean in
+ * the body signaling success or failure — never a 401.
+ */
+async function verifyTelegramToken(token, { fetchFn = fetch, timeoutMs = DEFAULT_TIMEOUT_MS } = {}) {
+  let res;
+  try {
+    res = await fetchFn(telegramUrl(token), { method: "GET", signal: AbortSignal.timeout(timeoutMs) });
+  } catch (e) {
+    return { status: "error", detail: `could not reach Telegram (${sanitizeDetail(e && e.message)})` };
+  }
+  let body;
+  try {
+    body = await res.json();
+  } catch {
+    return { status: "error", detail: `Telegram returned a non-JSON response (HTTP ${res.status})` };
+  }
+  if (body && body.ok === true) return { status: "active", detail: "Telegram accepted this bot token (getMe)" };
+  if (body && body.ok === false && typeof body.error_code === "number") {
+    return { status: "invalid", detail: `Telegram rejected this token (${sanitizeDetail(body.description) || body.error_code})` };
+  }
+  return { status: "error", detail: `could not verify: HTTP ${res.status} from Telegram` };
+}
+
+/**
+ * Discord webhooks: the credential IS a full URL, not a token to attach to
+ * a fixed endpoint elsewhere. A plain GET on that URL is Discord's own
+ * documented read-only "fetch webhook info" call, distinct from POSTing to
+ * it (which would send a real, visible message — never done here).
+ */
+function verifyDiscordWebhook(webhookUrl, opts) {
+  return verifyByStatusCode("Discord", webhookUrl, () => ({}), { ...opts, invalidStatuses: [404] });
+}
+
 module.exports = {
   isAwsCliAvailable, verifyAwsCredential, verifySlackToken,
   verifyOpenAiKey, verifyAnthropicKey, verifyGithubToken,
+  verifyHuggingFaceToken, verifyReplicateToken, verifyDigitalOceanToken, verifyPineconeKey,
+  verifySendgridKey, verifyGroqKey, verifyXaiKey, verifyOpenRouterKey, verifyStripeKey, verifyNpmToken,
+  verifyNotionToken, verifyGitlabToken, verifySupabaseToken, verifyElevenLabsKey,
+  verifyCircleciToken, verifyAirtableToken, verifyCloudflareToken, verifyHerokuKey,
+  verifyNetlifyToken, verifyLinearKey, verifyTelegramToken, verifyDiscordWebhook,
 };