Datadog application keys

• Provider documentation Access-token comparison table (mirrored at /account_management/service-access-tokens/) · observed 2026-09-22 · Application keys column: "Identifiable prefix … ddapp_ (new)" establishes ddapp_ as the identifying prefix of current-format application keys. Body length (34 characters) and alphabet are not stated on this page; both are corroborated only by Datadog-owned code and a third-party partner doc, never by a provider-domain page
• trufflehog 3.97.4
• gitleaks 8.30.1
• DataDog/datadog-agent (Agent app-key validator)
• DataDog/datadog-agent (Agent log/config scrubber)
• DataDog/cloudformation-template
• DataDog/terraform-module-datadog-agentless-scanner
• AWS Secrets Manager partner doc

Re-checked 2026-09-22 (redact-secret#162, product research at redact-secret#645): the legacy bare 40-character shape, gated on a same-line datadog/dd marker, is unchanged and corroborated only by TruffleHog's datadogtoken detector and gitleaks's datadog-access-token rule, neither of which accepts ddapp_. The current shape carries its own identifying grammar: a ddapp_ prefix Datadog documents on its own domain (personal-access-tokens and service-access-tokens comparison tables), plus a 34-character body corroborated only by Datadog-owned code (the Agent app-key validator, the Agent scrubber, CloudFormation and ARM templates) and AWS's partner doc. The Agent scrubber alone allows an underscore inside the body where every other Datadog-owned validator, and every corroborating source, states pure alphanumeric; that source is read as lenient-by-design, not as the real grammar, so `pattern` stays alphanumeric-only. Neither pinned scanner registers any rule for this shape. Re-checked 2026-09-23 (redact-secret#671, PR #679): the product split the legacy bare-hex generation into its own datadog-application-key-legacy detector, so that shape is the separate datadog-application-key-legacy contract here and this family now carries the ddapp_ shape only.