New Relic license keys

• Provider documentation ingest license key length and NRAL suffix · observed 2026-09-23 · New Relic's own documentation (docs.newrelic.com, IBM MQ host-integration page) states the ingest license key as 40 characters with the literal suffix NRAL, establishing the suffix and total length; its eBPF install pages show elided examples ending FFFFNRAL. The body alphabet, the FFFF segment and the EU eu01xx prefix are not provider-stated: they rest on New Relic-authored code (newrelic-cli IsValidLicenseKeyFormat, docs-website check-for-keys.sh) and trufflehog 3.97.4
• trufflehog 3.97.4
• Reference 1
• Reference 2
• Reference 3

Re-tiered 2026-09-23 (#112, provider evidence redact-secret#656). The provider source is a config-example comment ("New Relic ingest license key (40 chars, suffix NRAL)"), not a reference-page sentence. Retained contradiction: New Relic's own canonical page, docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/, still says "The license key is a 40-character hexadecimal string" and never mentions NRAL, which is not hex; the research reads it as describing the legacy key, but New Relic does not say so. A docker-monitoring troubleshooting page also says the license key "Should be 40-character NRAK-prefixed key", which conflicts with every other source (NRAK- is the User key prefix) and reads as a docs error. This pattern is stricter than the provider source: it requires FFFFNRAL (TruffleHog 3.97.4's newreliclicensekey detector matches exactly `\b(([0-9a-f]{32}|eu01xx[0-9a-f]{26})FFFFNRAL)\b`; no gitleaks rule targets the license key), where the provider proves only ...NRAL at 40 total. Two earlier, still-issued generations are corroborated by neither pinned tool and stay outside this pattern: a legacy all-hex 40-character key with no marker, and an intermediate 36-hex-plus-NRAL key (without the FFFF segment) that New Relic's own docs-website repository's internal key-format check script labels the "OLD" ingest key — provider-authored code hosted on github.com, not accepted as documentation here, per this file's existing precedent for e.g. sentry-org-auth-token and twilio-auth-token. Region prefixes other than eu01xx are likewise outside it. A fixture whose value does not match this pattern falls back to the policy classification already used for other multi-generation families (e.g. vault-token, slack-token).