Developers integrate through API or MCP. A human account grants the agent a limited scope. Cloak KMS performs only the permitted signing, verification, encryption, decryption, or derivation operation and returns only the permitted result. Supported protected-file workflows can add a signed receipt.
Agents do not provision the root of trust or receive private-key material. Hardware assurance depends on the configured custody path.
The differentiator is the authorization and evidence layer, not inexpensive hardware by itself.
Grant only the operation, key, environment, expiry, and usage the workflow needs.
Keep sensitive actions behind an explicit approval or pre-authorized policy.
Evaluate with software keys, then use managed or customer-controlled hardware when required.
Operations run inside the configured key boundary: SoftHSM software tokens for free and trial users, or hardware HSM custody for BYO and hosted pilot deployments.
Generate RSA-2048/4096, ECDSA P-256/P-384, and AES-256 keys inside a SoftHSM sandbox or HSM-backed vault. Keys are assigned a stable key_id and are not returned as plaintext.
Pass a digest to POST /keys/{id}/sign and get a signature back. The signing operation happens inside the configured KMS boundary; your app never receives private key material.
Schedule automatic rotation on any key. The old key is retired after a configurable grace period. Re-encryption of dependent data is handled by the KMS — your app sees the same key_id.
Wrap your own data-encryption keys with a KMS-managed key encryption key (KEK). Store the wrapped DEK anywhere; in HSM deployments, the KEK stays inside the hardware boundary.
Each account's keys are logically isolated. Hosted HSM pilots can add dedicated hardware partitioning; BYO HSM deployments can keep the hardware boundary under your control.
KMS enforces the credential scope for each operation. Signed receipts are shipped for supported protected-file operations; KMS-wide signed operation receipts and the full analytics view remain planned.
# Agent signs a document digest via KMS result = mcp.call_tool( "kms_sign", { "alias": "agent-signing-key", "keyId": "0101", "algorithm": "ECDSA_SHA_256", "digestHex": digest_hex } ) # Signature returned; private-key material is not returned sig = result["signatureBase64"] # Agent provisions a new key key = mcp.call_tool( "kms_create_masterkey", { "alias": "project-alpha-signing", "keyType": "ECC_SECP256R1", "keyUsage": "SIGN" } )
AI agents that sign artifacts, encrypt outputs, or issue credentials need their own key identity — and that identity needs to be auditable, scoped, and revocable. Cloak KMS gives every agent a named key in the software sandbox first, with BYO HSM and paid hosted HSM pilots available for hardware custody.
The MCP server exposes nine KMS primitives — list, read public key, create, delete, sign, verify, encrypt, decrypt, ECDH-derive — with scoped agent credentials per tool. See the full tool reference. KMS-wide signed operation receipts are planned; today, signed receipts are available in supported protected-file workflows.
kms_create_masterkey — provision a KMS key (ECC, RSA, AES)kms_sign — sign a SHA-256 digest inside the configured key boundarykms_encrypt / kms_decrypt — bytes-level RSA-OAEP / AES-CBCStart in a software-key sandbox. Managed smartcard-HSM access is capacity-limited and subject to plan controls. Customer-controlled or other production HSM options require a compatibility and deployment assessment. Receipt support is workflow-specific.
SoftHSM-backed trial keys
Guided hardware smartcard flow
Durable hardware custody
Cloak Files is a first-party consumer of this KMS: every file protect, open, and revoke resolves to a scoped KMS key operation. It is the working example of the integration pattern — your product can use the same one.
ecdh-derive) for ECC identities, RSA-OAEP for RSA.An agent protecting or reading customer files holds only a scoped, TTL-limited KMS credential. Private-key material is never in the prompt, the code, or the agent runtime.
In hardware custody paths, the masterkey behind every file key is generated inside a PKCS#11 HSM — smartcard HSM, YubiHSM 2, AWS CloudHSM, or BYO — and is non-exportable. Wrap and unwrap execute inside the device.
Evaluate the full file workflow on SoftHSM sandbox keys, then move the same keyspace concept to managed or customer-controlled hardware. The file APIs and MCP tools do not change.
For developer teams
Start with scoped credentials and software keys. Move to managed hardware subject to capacity and service limits, or connect a supported customer-controlled HSM after an asynchronous fit assessment.
The full KMS surface over OAuth2 — generate keys, sign, verify, encrypt, decrypt, manage keystores and policies. Best for first-party services and deep integrations (it's how Cloak Files uses KMS).
A self-service, least-privilege door for AI agents and scoped app integrations — owner-bound, TTL-limited, revocable credentials with sign / verify / encrypt / decrypt / key tools. No client provisioning needed.
Start with an asynchronous deployment questionnaire, device compatibility guidance, and documented PKCS#11 setup. Add paid remote engineering help only after the technical fit is clear.
Send the workload, custody requirement, and device model. We will return a written fit assessment and next steps.
Evaluate the human-to-agent grant and key-operation flow with software keys. Move to managed or customer-controlled hardware only when the production threat model requires it.
Governed by the OMMAU Charter — humans authorize, agents execute, receipts record supported actions.