Guard Idempotency Key

Operator-supplied idempotency key shape validator. Refuses keys that wouldn't be safe to surface in audit logs, persist in the sealed dbStore, or replay across processes:

- oversized (default 256 bytes — operators sometimes pass full JMAP request envelopes as keys; 256 is plenty for any reasonable correlation id without blowing storage) - control chars (C0 / NUL / DEL — defends audit-log injection when the key is rendered in a log message) - non-ASCII (NFC-normalized + ASCII-only; operator-greppable in audit logs across stack boundaries) - path-traversal shapes (.. / / / \ — defends operators who route idempotency keys through a filesystem-shaped path)

Permissive profile opts down the non-ASCII refusal for operators with legacy systems that include Unicode tenant IDs in keys.

b.guardIdempotencyKey.validate(value, opts?) #

{
  profile:    "strict" | "balanced" | "permissive",   // default "strict"
  posture:    "hipaa" | "pci-dss" | "gdpr" | "soc2",
  maxBytes:   number,                                  // per-profile default
}

Validate an operator-supplied idempotency key. Returns the input on success; throws GuardIdempotencyKeyError on refusal.

b.guardIdempotencyKey.validate("jmap-req-abc-123");

b.guardIdempotencyKey.compliancePosture(name) #

Return the effective profile NAME for a compliance posture, or null for a name this parser does not map. Unlike the content-guard variant this returns the resolved profile string (every line-protocol parser composes gateContract.ALL_STRICT_POSTURES, so "hipaa" / "pci-dss" / "gdpr" / "soc2" all resolve to "strict") and never throws — the parser shape carries no overlay-clone, no buildProfile, and no loadRulePack. Wired by gateContract.defineParser.

b.guardIdempotencyKey.compliancePosture("hipaa");                   // → "strict"
b.guardIdempotencyKey.compliancePosture("not-a-regime");            // → null

Last updated 2026-08-08T16:39:49.652Z by seeder.