Bitwarden Secrets Manager access tokens

• Provider documentation bitwarden/sdk-internal access_token.rs (824c1cf, last changed 2025-09-30): split once on :, the first part on . into exactly three parts, version "0", a UUID, and a Base64 key that decodes to 16 bytes; bitwarden/server CreateAccessTokenCommand (bb3a9da): SecureRandomString(30) with upper, lower and numeric; re-checked 2026-09-29 · observed 2026-09-29 · 0. + UUID + . + exactly 30 [A-Za-z0-9] + : + 22 standard Base64 + == (94 in all); no checksum
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7
• Reference 8
• Reference 9
• Reference 10
• Reference 11

Arrival evidence (#528, product redact-secret#1019; #1014 handoff bitwarden.md, READY). The token authenticates a machine account and carries both the client secret and the key that decrypts its secrets, so a leak exposes every secret the account can read. T1 on every part under R1: the provider SDK parser (version 0, UUID, key decoding to 16 bytes), the server generator (30 alphanumerics) and the docs example (segment lengths 1, 36, 30, 24 with ==). The UUID is written lowercase by the server and the parser also accepts uppercase, so the contract accepts both cases. Excluded: an unpadded key (parser-accepted, never issued), any other version, 0.<uuid> or 0.<uuid>.<secret> without the key, and Password Manager user./organization. API keys (no token grammar). The leading boundary (no [A-Za-z0-9._-] before 0) and trailing boundary (no [A-Za-z0-9+/=] after ==) are handoff decisions that keep 10.<uuid> and v0.<uuid> unclaimed. Neither pinned peer has a Bitwarden rule. Graduated to a registry detector at the 4fb7882 re-pin (redact-secret PR #1039).