Most teams protect sensitive data with a patchwork: a KMS for keys, a tokenization service for cards, hand-rolled crypto for everything else - and hope the seams hold. Vaulty replaces the patchwork with one API that stores, computes on, and selectively unlocks encrypted data. The seams are gone. So is the plaintext.
Every record in Vaulty sits behind three independent layers. An attacker has to beat all of them. You get all three with one API call.
Data is sealed with AES-256 the instant it arrives - before it ever touches a disk. Nothing at rest is readable, including the backups.
Confidential computing in secure enclaves means data stays encrypted even while it's being used. The host OS and the cloud provider can't read enclave memory.
Decryption is a privilege, not a default. Bind it to the end user's own authentication, scope it by role, and put an expiry date on it.
At rest, in transit, in use - the three states where data gets stolen. Vaulty keeps it encrypted through all of them.
| State | Mechanism | Guarantee |
|---|---|---|
| At rest | AES-256-GCM per record. Keys generated and held inside FIPS 140-2 HSMs, isolated per client - and per user, if you want it. | A stolen disk, dump, or backup is ciphertext. Attackers walk away with noise. |
| In transit | TLS 1.2+ on every connection, from your app to the API to the enclave. | Nothing readable ever crosses the wire - not to us, not past us. |
| In use | Confidential computing in secure enclaves (AWS Nitro Enclaves). Compute happens inside encrypted memory. | The host OS, the hypervisor, the cloud provider - none of them can read enclave memory. Neither can Vaulty. |
Here's an employee record, sealed the way Vaulty stores everything. Hover to decrypt it - a privilege you're borrowing for demo purposes.
In production, this is the part where everyone else gets nothing. The record only opens when its owner authenticates - passkey, biometric, MFA. Not the developer. Not the DBA. Not Vaulty. And definitely not whoever just exfiltrated the database. You, the reader, don't hold the key. The user does.
Swap the sensitive column for a tokenized reference and keep the rest of your stack exactly as it is. SDKs for Node.js (@vaulty/sdk) and Python (vaulty on PyPI), plus a REST API atapi.vaulty.xyz/v1 for everything else.
import { Vaulty } from '@vaulty/sdk';
const vault = new Vaulty(process.env.VAULTY_API_KEY);
// Tokenize a partner API key - ciphertext stays in the vault,
// your app keeps a harmless reference
const ref = await vault.store({
data: { partner_key: 'pk_prod_9f31xk52' },
policy: { rbac: ['billing-service'], expiry: '90d' },
});
// => 'ref_9f27ac31' - safe in your DB, your logs, your prompts
// Validate it inside a secure enclave - plaintext never comes back
const { valid } = await vault.compute(ref, 'validate:credential', {
field: 'partner_key',
});import os
from vaulty import Vaulty
vault = Vaulty(os.environ["VAULTY_API_KEY"])
# Decrypt only with the user present - passkey-bound
record = vault.retrieve(
"ref_9f27ac31",
auth={"user": "usr_8f3a2c", "method": "passkey"},
)
# Or skip decryption entirely and compute in place
masked = vault.compute("ref_9f27ac31", "mask:last4", field="partner_key")
# => '•••• xk52'ref_9f27ac31 drops into any schema, log line, or agent context - it decrypts to nothing without the vault.vault.store(), vault.retrieve(), andvault.compute(). No migration, no re-architecture.POST /records,GET /records/:ref, POST /compute - same guarantees, any language. Full reference in the docs.No brand mudslinging - just capabilities. Each column is a category of tools teams currently stitch together. Vaulty is the whole row.
| Capability | Secrets managers | Cloud KMS | Tokenization vaults | DIY in-house | Vaulty |
|---|---|---|---|---|---|
| Stores actual data, not just keys | ~ | ✗ | ✓ | ✓ | ✓ |
| Compute on encrypted data | ✗ | ✗ | ~ | ✗ | ✓ |
| User-bound decryption | ✗ | ✗ | ✗ | ~ | ✓ |
| HSM-backed keys | ~ | ✓ | ~ | ✗ | ✓ |
| No infrastructure to run | ~ | ✓ | ✓ | ✗ | ✓ |
| Multi-cloud portability | ~ | ✗ | ~ | ~ | ✓ |
✓ built in · ~ partial or bring-your-own · ✗ not available
User-controlled encryption binds each record to its owner's passkey, biometric, or MFA. It's how Universal Name Space ships unified digital identity - even UNS can't read user data without the user. Your competitors promise privacy. You can prove it.
Store, compute, unlock - the full three-layer architecture is one SDK install away.
AI agent? Connect our MCP server: npx -y @vaulty/mcp - see vaulty.xyz/mcp