Amazon Bedrock short-term API keys

• Provider documentation AUTH_PREFIX = "bedrock-api-key-" in AWS's Python, JS and Java token generators · observed 2026-09-26 · AWS-authored generators (aws-bedrock-token-generator, Python, JS and Java) build the short-term key as bedrock-api-key- followed by the standard padded Base64 of a SigV4-presigned CallWithBearerToken URL plus &Version=1, and the AWS Security Blog prints the fixed 133-character Base64 head. Provider code and a provider blog are not a documentation page; the maintainer ruling of 2026-09-27 (redact-secret#779) accepts them as T1 evidence for the prefix, the fixed 133-character head and the standard padded Base64 alphabet only. Total length and the session-token part of the body stay T2
• gitleaks 8.30.1
• awslabs/git-secrets
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7

Arrival evidence (#384, product redact-secret#864; research #779), T1 by maintainer ruling of 2026-09-27 for the prefix, the fixed head and the standard padded Base64 alphabet, graduated to a registry detector at cfe2aec: three AWS-authored token generators fix the bedrock-api-key- prefix, the &Version=1 suffix and standard padded Base64, and the AWS Security Blog prints a fixed 133-character head, but no AWS page documents the key as a format. gitleaks 8.30.1 and awslabs/git-secrets match only the prefix plus a 28-character head (the Base64 of bedrock.amazonaws.com), a weaker anchor than the blog's. The head is the Base64 of the fixed pre-signed URL head, so the generator derives it from that text. The body after the head has no documented width: about 500 characters without a session token, over 1000 with one. No length or ceiling twin is authored. The decoded pre-signed URL is a different lexical form of the same secret and a separate ruling; it is not authored.