Folio I · Controlled beta
Most teams skip application-layer encryption because getting key management right is hard. VellumGuard handles that — hybrid post-quantum crypto, key rotation, and an audit trail, as a hosted service. TypeScript SDK on npm. API live. Controlled beta.
Encrypted data captured today can be stored and decrypted later — once quantum hardware arrives. If your records need to stay confidential for 10 years or more, you are already behind.
NIST published the post-quantum cryptography standards in 2024. Security questionnaires now ask for a migration plan. "We're looking into it" is no longer a complete answer.
Cloud KMS products don't support post-quantum yet. Rolling your own means choosing algorithms, building key distribution, managing rotation, and logging everything — before writing a line of your actual application.
Healthcare records, research data, AI training sets, government files — anything with a 10-plus-year sensitivity window is exactly what a future quantum adversary would target first. The encryption you apply today is what you will be relying on then.
Encrypt patient notes, clinical records, or research data at the application layer. When quantum-resistant encryption becomes a regulatory requirement, you will have already shipped it.
Add encryption to your product without building crypto infrastructure from scratch. Workspace-scoped API keys give each customer isolated key material and a separate audit log.
Training sets that include personal information, proprietary examples, or sensitive content need protection that holds up over the model's lifetime — not just during the training run.
Start your post-quantum migration before the procurement questionnaire arrives. VellumGuard gives your security team something concrete to show while the standards are still being adopted.
CNSA 2.0 requires post-quantum migration for national security systems by 2035. If your customers include federal agencies, you are already in scope. We support that planning work now.
If you have been meaning to encrypt a specific data class — messages, documents, model weights, financial records — and kept deferring because key management is hard, this is the direct path.
Short guides covering the problem, an example workflow, where VellumGuard fits, and what it does not replace — for each use case.
Protect clinical, research, and patient-adjacent records that may remain sensitive for 10 or more years. Test application-layer encryption and post-quantum migration paths without replacing every system at once.
Not currently HIPAA compliant. No BAA is currently available.
Read guide →Add encryption, workspace-scoped API keys, identity-scoped authorization, and audit events to a SaaS product without building a key-management platform from scratch.
Read guide →Protect sensitive datasets, embeddings, and evaluation payloads that require long-term confidentiality and clear access boundaries across teams and third-party contributors.
Read guide →Start post-quantum migration at the application layer now. CNSA 2.0 sets a 2035 deadline for national security systems. Building the implementation early reduces the scope of the larger migration.
Read guide →For defense contractors, VellumGuard can support application-layer encryption, key-management discipline, and operational evidence within a broader security program. It does not make an organization CMMC compliant.
Not a CMMC compliance platform. Does not replace a C3PAO assessment.
Read guide →The API is live. The TypeScript SDK is on npm. The full key rotation lifecycle has been executed in production — not just documented.
One npm install. Address encrypted data to your user IDs — not raw keys. The SDK calls the hosted KMS to resolve each identity's public key and returns a sealed ciphertext. No key bytes, no algorithm choices.
Private key blobs live encrypted in the VellumGuard database. DEKs are wrapped by Google Cloud KMS — the raw DEK never touches disk or logs. The KEK registry tracks active, rotated, and retired key versions for a full audit trail.
Recipients decrypt with one SDK call. Every encrypt, decrypt, key promotion, rewrap, and retire operation is recorded in the security and audit event log — a queryable, durable record your team can actually use.
Every ciphertext is sealed with X25519 and ML-KEM-768. If either scheme is ever broken, the other still holds. You are never worse off than today's encryption.
ML-KEM-768 (FIPS 203) and ML-DSA-65 (FIPS 204). No experimental schemes — exactly the algorithms an auditor expects to see named.
Customer plaintext never reaches VellumGuard. Payload encryption and decryption happen inside the SDK. In the current beta, signing and key decapsulation use the VellumGuard service — private keys do not leave it.
The wire format is published with reference test vectors. Decrypt your data with any conforming implementation — no lock-in, no "what if they vanish."
Every authorization decision, key operation, and SDK call is recorded. Workspace- scoped API keys with identity-scoped authorization let you answer exactly who accessed what — and when.
No home-grown cryptography. VellumGuard composes well-reviewed, open implementations — the boring choice, on purpose.
Sensible, conservative defaults. The full ciphertext format specification is public — see the documentation.
The full lifecycle has been executed in production. Every step is audited. Old key rows are preserved — never deleted.
VellumGuard is available for controlled beta and design-partner access. The platform is live and the key rotation lifecycle works end-to-end. The limitations below are real.
The API is live at api.vellumguard.com. The TypeScript SDK is on npm. DEK wrapping is backed by Google Cloud KMS. The full key rotation lifecycle — generate, promote, rewrap, retire — has been executed end-to-end in production. Workspace-scoped API keys, identity-scoped authorization, and audit events are all working.
TypeScript SDK only (Python and Go coming). No developer portal or dashboard. No BYOK / customer-managed keys. No self-serve billing. Manual onboarding only. Not currently SOC 2 certified. Not currently HIPAA compliant. No BAA is currently available. No formal SLA during beta.
Use test or synthetic data during beta integration. Do not send PHI, PCI card data, or other regulated production data without a separate written data-handling agreement. Contact beta@vellumguard.com to discuss before sending regulated data.
Learn how VellumGuard integrates with applications, existing secure transport, legacy systems, and customer-controlled infrastructure.
In the current beta, payload encryption and decryption are local. Signing and decapsulation use the hosted service on every call.
No. Payload encryption and decryption occur inside the application process. Customer plaintext does not need to be sent to a VellumGuard-hosted server.
The current beta does use the VellumGuard service for two private-key
operations: a hosted signing call on every encrypt(), and a
hosted key-decapsulation call on every decrypt(). Public
identity keys are cached in memory for up to one hour per SDK instance,
which can avoid repeated lookups. The cache does not remove the
live-service requirement for signing or decapsulation.
VellumGuard is therefore not the routine processing location for customer plaintext, but the current hosted service is still part of the cryptographic execution path.
For the strongest application-level protection, the SDK can be embedded directly in each service. This allows each participant to establish its own identity, encrypt and decrypt payloads locally, and use hosted signing and decapsulation calls for private-key operations.
Legacy systems that cannot be directly modified can instead integrate through a local gateway, adapter, sidecar, or proxy. Direct SDK integration provides greater application-level visibility; boundary integration protects data at the gateway but cannot provide complete insight into activity inside an unmodified system.
No. TLS and secure tunnels protect the transport connection. VellumGuard adds protection and verification at the application and data level — cryptographic identity, local payload encryption and decryption, hosted signing and decapsulation, and signature verification.
A secure transport layer protects the route. VellumGuard helps protect and verify the participants and the payload. The two are complementary.
The application does not store raw cryptographic key material. Private keys remain on the VellumGuard service and are never transmitted to the SDK. The application holds an API key credential for authentication only.
The SDK maintains an in-memory cache of public keys within each
VellumGuard instance (1-hour TTL per identity). Public key
lookups can be served from this cache on repeat calls for the same identity.
The cache holds public keys only and does not persist across processes or
function invocations.
Customer-managed keys (BYOK) and alternative key-storage integrations are planned but not currently available in beta.
Every encrypt() makes exactly one network call for signing
and every decrypt() makes exactly one for decapsulation.
These private-key operations are performed server-side on every call and
cannot be cached.
Public key lookups are served from an in-memory cache (1-hour TTL per identity, per instance) when available, avoiding a network round-trip on cache hit. In serverless or short-lived environments where each invocation creates a fresh instance, public key lookups will also incur a network call.
No benchmark data for the current beta configuration is published. VellumGuard does not claim zero overhead. Performance should be measured against your specific workload and deployment architecture.
The SDK is endpoint-configurable. The baseUrl parameter in
HttpKmsClient defaults to
https://api.vellumguard.com but can be overridden to point
to any VellumGuard-compatible service endpoint.
Current beta: The hosted service and local development
(http://localhost) are the supported targets. A fully packaged
customer-hosted production service is planned enterprise architecture and is
not yet available. The SDK is designed to be endpoint-configurable rather
than permanently coupled to a single hosted service.
We are onboarding a small group of design partners. Healthcare, defense, long-lived-data, and AI training-data use cases prioritized. Beta is free unless otherwise agreed in writing. No charges without a written agreement before general availability.
Please do not submit PHI, regulated production data, API keys, passwords, or sensitive customer data through this form.
You can also contact us directly at beta@vellumguard.com.