Org Passphrase: User-Controlled Encryption for Exchange API Keys

Server-managed encryption protects your exchange API keys from database dumps — but it still means the platform holds both the ciphertext and the decryption key. If the key management system is ever compromised alongside the database, that protection collapses. VolatiCloud's organization passphrase feature adds a second, independent layer: a key derived entirely from something only you know, using an algorithm designed to make brute-force infeasible. Your API keys are encrypted before the platform ever sees the raw values.

Why Platform-Managed Encryption Is Not the Full Story

A common security baseline for SaaS platforms is to encrypt sensitive data at rest using a managed key — typically stored in a hardware security module or secrets manager like HashiCorp Vault. VolatiCloud does this: every exchange API key is wrapped with AES-256-GCM before it touches the database.

That architecture is solid against a standalone database breach. But it depends on one assumption: the key management system and the application layer are not compromised simultaneously. In a sophisticated attack — a supply chain compromise, a long-lived intrusion, an insider threat — both could be accessed at once. The cryptographic guarantee collapses because the key and the ciphertext are both within reach.

The organization passphrase feature changes this calculus. Your API keys are encrypted with a key derived from a passphrase that lives only in your head. VolatiCloud's servers never hold this derived key in persistent storage. Even with full read access to the database and the platform's own key material, an attacker cannot decrypt your secrets without knowing your passphrase.

How the Passphrase Key Derivation Works

When you set an organization passphrase, VolatiCloud derives an AES-256 encryption key from it using Argon2id. You do not supply the encryption key directly; the passphrase is the input to a key derivation function (KDF) that produces the key.

Argon2id is the current winner of the Password Hashing Competition and the NIST-recommended choice for password-based key derivation. It is intentionally slow and memory-hard: deriving a key takes on the order of seconds and requires hundreds of megabytes of RAM. That cost is negligible for legitimate use — you enter your passphrase once per session — but it makes offline brute-force attacks extremely expensive.

A 12-character passphrase with mixed case, digits, and symbols has roughly 72 bits of entropy. Argon2id at the parameters VolatiCloud uses requires approximately 0.5–2 seconds and 256 MB of RAM per guess attempt. Recovering such a passphrase by brute force would take millions of years on current hardware — even if the attacker has your database backup.

The derived key is used as the AES-256-GCM encryption key for your secrets. Each encrypted field has its own initialization vector, ensuring that the same plaintext value encrypted twice produces different ciphertexts. This prevents pattern analysis on the encrypted blob even when two users happen to use the same exchange credential format.

What Gets Protected

The passphrase encryption layer covers the fields in your exchange connections and bot runner configurations that constitute actual credentials:

• Exchange API keys and API secrets
• Passphrases for exchanges that require a third credential (OKX, KuCoin, and similar)
• Any sensitive configuration value that VolatiCloud classifies as a secret

When you are not authenticated to the platform with a valid session, these fields decrypt as empty — the ciphertext exists, but without the derived key, there is nothing to read. If you are authenticated but have not yet unlocked the organization passphrase for your current session, the same applies: the platform can serve bot configuration to your running bots (a separate trust boundary), but it cannot expose raw credentials through the API or UI.

The Session Cache: Balancing Security and Usability

Re-deriving an Argon2id key from your passphrase on every API request would be prohibitive — both for you as a user and for the server. VolatiCloud caches the derived key in memory for the duration of your authenticated session.

This means you enter the passphrase once when you log in (or when you explicitly lock and re-unlock the organization), and your credentials remain accessible for that session. The cache lives only in application memory and is never written to disk or the database. When your session expires, the cache is cleared, and the next session requires passphrase re-entry.

The session-bound cache is the practical tradeoff point between security and friction. If your threat model requires shorter windows, you can manually lock the organization from the Security settings page — this clears the cache immediately and requires passphrase re-entry before credentials can be accessed again.

Recovery Codes: Do Not Skip This Step

A passphrase-based system introduces a hard problem: what happens if you forget the passphrase? With a server-managed key, the platform can reset or rotate it. With a user-controlled passphrase, that escape hatch does not exist by design — no one on VolatiCloud's team can recover your passphrase.

Recovery codes solve this. When you generate recovery codes, VolatiCloud creates a set of single-use codes that can each reset the organization passphrase one time. Each code is a high-entropy random string that functions as an alternative passphrase: present it, and you can set a new passphrase and re-encrypt all secrets with the new derived key.

Recovery codes are displayed only at generation time. VolatiCloud stores a hash of each code, not the plaintext — so if you lose all of them, no one can recover them. The only path from "lost all recovery codes and forgot the passphrase" is to revoke all your exchange connections and reconnect them with new API keys.

Treat your recovery codes like a physical vault backup. Print them and store them in a secure location. Save them in a password manager that is not the same system as the one holding your passphrase. Give a copy to a trusted co-admin if your organization has one. The distribution strategy matters: store enough copies that a single failure (house fire, failed hard drive, terminated employee) doesn't leave you locked out, but not so many that the codes themselves become a liability.

When your remaining codes fall below a threshold, VolatiCloud displays a warning in the Security settings and recommends regenerating. Regenerating invalidates all existing codes — so if you distribute codes to a team member, let them know before you rotate.

Setting Up the Organization Passphrase in VolatiCloud

The passphrase system lives in Organization → Security in the console. The flow is straightforward:

1. Navigate to Organization → Security and find the Key Custody panel.
2. Enter your passphrase in the input field and confirm it. The passphrase is never sent to the server in plaintext — key derivation happens client-side, and only the derived key material is used.
3. Click Set Passphrase. Your existing secrets are immediately re-encrypted with the new derived key.
4. Before leaving, generate recovery codes. The system will prompt you; do not skip this.
5. Store the recovery codes securely. You can regenerate them at any time from the same page.

Once configured, future sessions will prompt you for the passphrase after login. You can also lock the session manually, which forces re-entry immediately.

For organizations with multiple administrators, one passphrase protects the entire organization. All admins who need to unlock credentials for editing or viewing must know the passphrase. VolatiCloud supports an optional admin escrow mode, which allows designated admins to re-encrypt secrets if the primary passphrase holder leaves — this is available in the Trust Policy settings alongside the passphrase configuration.

What This Protects Against — and What It Does Not

The organization passphrase is a defense against credential theft from VolatiCloud's infrastructure. It is not a replacement for the other layers described in Exchange API Key Security: Why Your Trading Bot Can't Drain Funds.

Threat	Withdrawal-disabled keys	IP allowlist	Platform encryption	Org passphrase
Stolen key used to withdraw funds	✅ Blocks it	✅ Blocks it	—	—
DB breach, plaintext credentials exposed	—	—	✅ Blocks it	✅ Blocks it
DB + KMS breach, both exposed simultaneously	—	—	❌ Keys accessible	✅ Blocks it
Passphrase guessed by brute force	—	—	—	✅ Argon2id makes this infeasible
User's device is compromised	—	—	—	❌ Not in scope
Passphrase forgotten, no recovery codes	—	—	—	❌ Permanent lockout

The passphrase layer is most valuable in the "DB + KMS compromise" scenario — the case that platform-managed encryption cannot cover on its own. Combined with withdrawal-disabled keys and IP allowlisting, it means an attacker who breaches every layer of VolatiCloud's server infrastructure still cannot extract usable exchange credentials or move funds.

What the passphrase does not protect against: threats to your own device or credentials. If your VolatiCloud account password and passphrase are both known to an attacker, they can log in and unlock the session the same way you do. The passphrase is an additional factor of protection for the server side, not a replacement for strong account passwords and two-factor authentication on your Keycloak account.

Connecting to the Exchange Permission Scanner

A related recently-shipped feature is the exchange permission scanner, which runs as a background process and automatically checks every connected API key for withdrawal permissions — including keys added before the connection-time enforcement was in place. If a withdrawal-capable key is discovered, a banner appears in the Exchanges view flagging the specific connection so you can replace the key.

This makes the withdrawal-disabled guarantee retroactive: even if you connected a key years ago and the permission check was not enforced at that time, the scanner will surface it now. The two features — passphrase encryption and permission scanning — address different attack surfaces but together they form a meaningful improvement in the overall security posture of any organization running trading bots on VolatiCloud.

Putting It Together

Connecting API keys to any automated trading platform is a calculated risk. The goal is not to eliminate that risk — it cannot be eliminated — but to constrain it to the minimum possible blast radius. The current stack on VolatiCloud looks like this:

1. Withdrawal-disabled keys — the attacker cannot move funds even with a valid key
2. IP allowlisting — the key only works from VolatiCloud's own egress IPs
3. AES-256-GCM at rest — platform-managed encryption for the database layer
4. Organization passphrase — user-controlled encryption layer independent of platform KMS
5. Recovery codes — the break-glass mechanism to avoid permanent lockout

Each layer fails independently. An attacker who defeats any one of them is still stopped by the rest. The passphrase feature is the newest addition to this stack — and the only one where the encryption key never touches VolatiCloud's persistent storage at all.

Set up the passphrase in Organization → Security, generate your recovery codes, and store them somewhere safe. The whole process takes about three minutes and provides a meaningful improvement in your security posture.

Ready to configure it? Log in at console.volaticloud.com and navigate to Organization → Security. For more detail on the full encryption architecture, see Encryption: AES-256-GCM at Rest, TLS in Transit in the knowledge center.