@xemahq/credential-custody

This package belongs to Layer 1 — a framework-agnostic SDK with zero @xemahq dependencies (only the Node fetch runtime). It is the custody abstraction for the Xema OS credential broker (master plan §W4 / Pillar 3.1).

What it is

One CustodyBackend interface — write / read / rotate / delete — that the credential-broker-api drives. Concrete backends are selectable by config, not by a code branch in the broker:

• SecretsApiAdapter — wraps submodules/secrets-api. The first cutover backend (zero new infra); secrets-api owns DEK/KEK custody, versioning, and rotation.
• OpenBaoAdapter — OpenBao KV-v2 (MPL-2.0, the open Vault continuation). The GA self-managed default. Vault-wire-compatible; thin fetch shim, no SDK.

Cloud-managed adapters (AzureKeyVaultAdapter, AwsSecretsManagerAdapter) are reserved in CustodyBackendKind and ship when their provider SDKs are wired.

Invariants

• A CustodyRef is an opaque, non-sensitive handle the broker persists on CredentialBinding.secretRef. It is never the secret value.
• The secret value lives only inside a backend; it surfaces only through read / rotate and is immediately sealed by @xemahq/sealed-credential.
• Every operation fails fast with a closed CustodyError code — no silent fallbacks, no best-effort writes.
• An adapter refuses a CustodyRef minted by a different backend (assertRefBackend), so a misrouted read can never silently succeed.