Neon API keys

• betterleaks
• mask-go
• Reference 1
• Reference 2
• Reference 3
• Twin source napi_ prefix (2025-01-31 changelog) · observed 2026-09-24 · Neon states that newly created API keys are prefixed with napi_ so that secret scanning can rely on an identifiable marker, and that existing unprefixed keys stay valid. It states no body length or alphabet. Twins mutate the prefix, its delimiter, the body length floor or the body alphabet

Registry detector neon-api-key since redact-secret#524 (#773, registry pinned at 3144bb3); authored under #259 directly as a registry contract. The napi_ prefix is provider-documented (Neon changelog 2025-01-31, source neondatabase/website content/changelog/2025-01-31.md). The body is not: Neon calls a key "a randomly-generated 64-bit token", and its one written example (napi_examplekey...) is a word and two ordered runs, not a shape. The 64-character [A-Za-z0-9] body floor is corroborated by betterleaks neon-api-key (exactly 64, entropy-gated) and mask-go (64 as a floor). The tier is therefore T2: a T1 prefix with a tool-corroborated body stays at the weakest frozen field. The body is read as a floor, so no fixture asserts silence on a longer body. GitHub secret scanning lists neon_api_key as a partner pattern without publishing the expression. Neither pinned peer (gitleaks 8.30.1, trufflehog 3.97.4) has a Neon rule, so a peer miss is expected. Legacy unprefixed keys are not claimed and are not controls. A Neon connection URI password is a separate credential that the connection-string family already covers, and it is never a control here. Node-API identifiers (napi_create_string_utf8, NAPI_VERSION) are near-miss controls.