RunPod API keys

• Provider documentation runpod/runpod-mcp src/alp/scrub.ts (added 2026-09-16, a provider-authored scrubber; R2): \brpa_[A-Za-z0-9]{16,}\b; the RunPod blog on scoped keys (2024-11): "Any new keys will be created with an rpa_ prefix"; re-checked 2026-09-28 · observed 2026-09-29 · rpa_ + [A-Za-z0-9], open-ended, provider floor 16; the contract floor 31 is policy under R10; no separator or checksum
• betterleaks (unpinned)
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7
• Reference 8
• Reference 9
• Reference 10
• Reference 11
• Reference 12
• Reference 13

Arrival evidence (#464, product redact-secret#974; #860 handoff runpod.md, READY with an open-ended body by ruling R10). T1: the prefix is the provider blog and the alphabet and provider floor of 16 are a provider-authored scrubber (R2). POLICY under R10, not T1: a floor of 16 would claim Redirect.pizza's rpa_ + 30 tokens, so project policy raises it to 31, the first width above that shape, and every RunPod width seen (46 empirical; a withdrawn 48-character docs example) is above it; the 128-byte upper bound is policy too (a bounded run for streaming; rejected whole, never truncated). The alphabet stays the provider's [A-Za-z0-9]. The contract pattern therefore carries the policy floor and the twin at 30 says POLICY; a body of 16-30 is an accepted false negative (none known), positives reach 128 and nothing asserts silence on 129. The 46-byte body and the 40-upper-plus-6-mixed layout are tool and empirical facts, so positives are authored with and without that layout. Excluded: Redirect.pizza rpa_ + 30 (another issuer), RunPod S3-compatible rps_ secrets and access keys (another credential), legacy unprefixed keys, and rpa_..., rpa_xxxx, rpa_your_key placeholders. A Redirect.pizza token of 31 or more bytes, if one exists, would read as RunPod: misattributed, still redacted. Graduated to a registry detector at the 4fb7882 re-pin (redact-secret PR #1037).