Amazon Bedrock long-term API keys

• Provider documentation AWS Security Blog detection pattern for long-term keys (ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+/]+={0,2}) · observed 2026-09-26 · AWS's own security blog prints a scan pattern for the long-term key: the ABSK prefix, a fixed head that is the Base64 of BedrockAPIKey-, and a standard-Base64 body with up to two = pad characters. A provider blog is not a format specification; the maintainer ruling of 2026-09-27 (redact-secret#778) accepts it as T1 evidence for the ABSK prefix and the standard-Base64 alphabet only. Lengths and IAM user-name variants stay T2
• gitleaks 8.30.1
• awslabs/git-secrets
• Wiz measurement
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6

Arrival evidence (#384, product redact-secret#864; research #778), T1 by maintainer ruling of 2026-09-27 for the ABSK prefix and standard-Base64 alphabet, graduated to a registry detector at cfe2aec: the AWS Security Blog pattern is provider-authored (prefix, fixed head, standard Base64 with up to two = pads), and gitleaks 8.30.1 and awslabs/git-secrets agree on the ABSK prefix with a 109..269-character standard-Base64 tolerance, but no provider page states a length, and the blog is a scan pattern rather than a format specification. Wiz measured 132 characters for a console key; layout arithmetic gives 136 for a second key on the same IAM user, which the positives carry. The key decodes to BedrockAPIKey-<user>-at-<account>:<secret>, where the public alias is the part before the colon. The 18-character head holds only when the IAM user name starts BedrockAPIKey-; an ABSK-only key with another head is a T2 shape that this contract does not assert either way (no fixture asserts silence on a head-less ABSK value). No length, ceiling or checksum twin is authored: the widths are tool-corroborated ranges, not a provider statement.