[crisfiorini-oss]

Summary

Add the managed-key runtime client needed by a hosted consumer that requires purpose-bound encryption, stable MAC lookup and wrapped signing material. The client uses Azure Managed HSM through the official Azure SDK; no Vault server or replacement proxy is introduced.

Changes

• Add a leaf Go module owned by the existing key-service agent, keeping provider code outside Host. Reuse the established service-agent-owned runtime-library pattern.
• Require three distinct, version-pinned HSM keys and an explicit workload tenant/client. Validate custody and operations at boot, then exercise encryption/decryption and MAC access.
• Retain ciphertext key versions across rotation, pin MAC versions, preserve the consumer's signing algorithm, and isolate organization keys from deployment capabilities.
• Add race-tested SDK transport cases covering restart, rotation, wrong purpose/key, exportable or disabled keys, denied access and error redaction. Add the leaf module to CI.

Classification: fix at the provider owner. This is source implementation, not a live backend deployment.

Build or reuse	Result
Existing agent external binding/provisioning, Host key-service interfaces, CLI #924, SDK Go and handbook service inventory	No managed runtime client exists. Extend this owner with a leaf runtime client, as service-redis/cache and service-postgres/libs/go already do; retain Host framing rather than duplicate it.
Azure SDK azkeys/azidentity and Go standard library	Reuse identity, challenge handling and provider operations. No new HTTP/auth client or crypto primitive.

Testing

• cd keyservice && go test -race ./... && go vet ./...: passed against a controlled service transport using the actual Azure SDK and AES-GCM/HMAC.
• Existing Vault agent behavior is unchanged; its complete lifecycle suite was not run.
• No live HSM, workload federation, backup/restore, secret publication or application deployment is claimed. Live HS256 compatibility and service limits remain to be qualified.

Open questions / Next steps

Consumer integration follows the existing generic Host key-service interface. Infrastructure must supply an activated HSM, recovery custody, exact grants and key versions before live qualification. This PR does not provision an HSM or choose a recovery quorum. Related owner gap: codefly-dev/cli#924.

Live-protocol correction at a6c7256b: Azure Managed HSM rejected a caller-supplied GCM nonce. Encryption now accepts and validates the nonce generated by the HSM; decryption retains the framed nonce. Controlled SDK transport tests reject a supplied encryption nonce and cover roundtrip/tamper behavior. The analogous infrastructure signing-seed wrap succeeded against the live HSM; this is protocol evidence, not yet an Accounts workload or HMAC qualification.

Current CI gate (2026-10-28)

The branch is already based on current main. The upstream pull-request workflows require maintainer approval; the contributor cannot approve those runs.

An unchanged-head draft fork validation PR ran the full workflows (run 40717181840). The managed-key client and shared build passed. Both lifecycle/test lanes fail at TestVaultImageAudit against the existing canonical runtime-v2.0.3-patched.16 image, not in the managed-key client tests.

The image audit reports CVE-2026-116587 in go-jose/v3 3.0.5 and go-jose/v4 4.1.4. The upstream advisory publishes a v4 fix in 4.1.6 and no patched v3 release. The runtime image owner must supply a remediated, published image and pin before these lanes can pass. Changing only the Dockerfile does not repair CI, which audits the published digest. No audit exception or weakened gate has been introduced. Keep this PR draft until the upstream workflows and runtime-image audit pass.