Postman collection access keys

• GitLab secret-detection-rules
• Reference 1
• Reference 2
• Reference 3
• Twin source masked PMAT- collection access key · observed 2026-09-24 · Postman documents the collection access key as a read-only credential for one collection's JSON (Share via API), valid for 60 days of inactivity, and renders it masked as PMAT- followed by asterisks and four trailing characters (26 in all). It states no alphabet. Twins mutate the prefix, its delimiter or the body length

Registry detector postman-collection-access-key since redact-secret#700 (#773, registry pinned at 3144bb3); authored under #259 directly as a registry contract. Postman documents the collection access key (Share via API: "Generate New Key to create a read-only collection access key. This key expires after 60 days of inactivity") and tells users to remove sensitive data before sharing one. Its API reference renders the key masked as PMAT- + asterisks + 4 characters, a 26-character body by count (provider example, not a grammar statement). GitLab's secret-detection rule PostmanCollectionAccessKey matches \bPMAT-[A-Z0-9]{26}\b and gates validation on a postman or pstmn.io context; its examples are ULID-shaped, which is recorded as unresolved; GitHub secret scanning lists postman_collection_key as a partner pattern without publishing the expression. The contract freezes GitLab's uppercase alphanumeric body. The product (redact-secret#700) also accepts lowercase, a looser reading. No lowercase twin is authored, because the case is stated by one tool only. Neither pinned peer has a PMAT- rule. The PMAK- API key is a different, secret credential and is never a control. The prefix twin swaps PMAT- for PMAK- with the same 26-character body, which fits neither contract.