KMS

Updated

Store agent signing keys in a hardware-backed KMS instead of the local encrypted store. On Enterprise, agent keys can live in an Asqav-managed KMS: Asqav creates the key in the AWS KMS or GCP KMS account its server is configured with, holds only the key reference, and calls the KMS to sign.

Tier gating

Asqav-managed KMS is Enterprise-only. The Free plan uses the local encrypted key store. Creating an agent with use_cloud_kms=true on Free returns 403 Forbidden.

Concept

By default, each agent holds an ML-DSA secret key encrypted at rest in the Asqav database. With Cloud KMS enabled, the secret key never leaves the KMS. Asqav only holds a key reference (provider, key id, version) and calls the KMS every time it signs. Supported providers are AWS KMS with ML_DSA_65 and GCP KMS with PQ_SIGN_ML_DSA_65. AWS KMS is FIPS 140-3 Level 3. GCP Cloud KMS provides FIPS 140-2 Level 3 key material (ML-DSA is in preview).

The default Asqav signer implements ML-DSA-65 per FIPS 204 and has no FIPS 140-3 module validation; FIPS 140-3 levels belong to the cloud KMS or HSM that holds the key.

The default and this page describe two different protection levels, and the encrypted-at-rest default is not nonexportable signing. Key protection levels compares them line by line against the source.

Create an agent backed by Cloud KMS

Opt in by sending use_cloud_kms=true on agent creation. The API provisions a KMS key in the region and ring configured on the server and stores only the key reference.

bash 
curl -X POST https://api.asqav.com/api/v1/agents/create \
  -H "X-API-Key: sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"payments-bot","algorithm":"ml-dsa-65","use_cloud_kms":true}'

Key rotation

Create a new agent version pointing at a fresh KMS key, then disable the old one. Issued signatures remain verifiable because the public key used for each signature is stored with the record. The old key reference stays readable for audit replay.

Your own cloud account

Asqav has no cross-account KMS option today. The hosted service creates and uses KMS keys in Asqav's cloud account, not in yours.

Verification

A KMS-backed agent lists a key_id prefixed with kms_ and records the provider inside its KMS reference. You can confirm a signature used KMS by inspecting the agent:

bash 
curl https://api.asqav.com/api/v1/agents/agt_abc123 \
  -H "X-API-Key: sk_live_..."

The response includes key_id and whether the agent uses cloud KMS. If KMS is not configured on the server, creation returns 503 Service Unavailable; a failed KMS call returns 500 Internal Server Error for creation and signing; neither creation nor signing falls back to a local key, and we do not fall back to local keys.

Generate local keypairs from the terminal with asqav keys generate.

References