Security Levels: One-Click Security Policy for Your Trading Org
Managing a crypto trading organization means balancing two things that rarely cooperate: operational speed (bots that restart automatically, sessions that stay unlocked so backtests can run overnight) and data security (passphrase-gated decryption, runner isolation, per-action proof of key knowledge). Until now, configuring that balance required setting five or six independent flags — and nothing stopped you from reaching a state that was technically impossible, like enabling Strict mode without passphrase encryption first.
VolatiCloud just shipped Security Levels — a preset-based approach to security policy that eliminates impossible states and makes the right configuration a single click. Instead of toggling individual flags, you pick one of four named levels: Basic, Standard, Hardened, or Maximum. The platform applies a coherent, dependency-checked bundle atomically and rejects any combination that would produce a broken policy state.
The Problem with Freeform Security Flags
The original organization security page exposed a grid of toggles:
- Passphrase encryption on/off
- Strictness mode (Convenience / Strict / Airgapped)
- Runner location (Anywhere / Self-hosted)
- Runner attestation on/off
Each flag has dependencies. Strict mode requires passphrase encryption — there's nothing to unlock per-action if encryption isn't on. Airgapped mode requires both passphrase encryption and self-hosted runners — decryption that never leaves your infrastructure only works if your runners are your infrastructure. Turning on Strict without turning on passphrase first was a silent misconfiguration that the original UI allowed.
This wasn't a hypothetical — it was the concrete bug that drove the Security Levels redesign. The fix wasn't better validation messages; it was making level the primary configuration concept so intermediate impossible states can't occur.
Four Levels, One Decision
Each level is a named bundle of flags that satisfies all dependency constraints by construction. You pick the level; the platform applies it as a single atomic transaction.
| Level | Passphrase Encryption | Strictness | Runner Location | Attestation |
|---|---|---|---|---|
| Basic | Off | Convenience | Anywhere | Off |
| Standard | On | Convenience | Anywhere | On |
| Hardened | On | Strict | Anywhere | On |
| Maximum | On | Airgapped | Self-Hosted | On |
Basic
No encryption. Strategies, exchange config, and bot settings are stored in plaintext within the VolatiCloud database. All decryption happens server-side with no user involvement.
Choose Basic only if your organization has no encryption requirement — a staging org, a demo environment, or a team that's evaluating the platform before committing to a security posture. It's the default for new organizations.
Standard
Passphrase encryption on, Convenience strictness. This is the most common production configuration.
Your exchange API keys, strategy code, and runner credentials are encrypted at rest with your organization's passphrase-derived key. Bots and backtests run autonomously after you approve a session once — the platform caches a short-lived decryption session so overnight jobs don't need you awake to type the passphrase. Recovery codes are generated at setup and let your team regain access if the passphrase is lost.
Standard is the right choice for most trading teams: data is protected, automation isn't interrupted, and operational overhead is minimal.
Hardened
Passphrase encryption on, Strict strictness. Decryption requires you to prove knowledge of the passphrase at the moment of each sensitive operation — not once per session, but per action.
Under Hardened, the server cannot decrypt anything on your behalf without a fresh proof. That means bots cannot auto-restart unattended after a runner reboot, and backtests that run overnight need the passphrase re-entered each time decryption is needed. The tradeoff is explicit: operational friction for stronger guarantees that your key material is never cached server-side beyond the immediate operation.
Hardened fits regulated or high-value environments where "convenience" is a security risk and operational teams are available to manually re-approve decryption operations.
Maximum
Passphrase encryption on, Airgapped strictness, self-hosted runners. The server never decrypts on your behalf, and the runtime never runs on VolatiCloud infrastructure.
Under Maximum, all bot execution happens on runners you control — on your own hardware or a BYOC (bring your own cloud) environment. Airgapped strictness means decryption keys only exist within your perimeter. If a VolatiCloud server is compromised, there is nothing to read: the ciphertext lives in our database, but the decryption never happens there.
Maximum is the appropriate choice for proprietary trading firms, regulated entities, or organizations with strict data-residency requirements. It requires the most operational investment — you're running and maintaining the runner infrastructure — but it provides the strongest isolation guarantees the platform offers.
Custom Mode: When Presets Aren't Enough
The five-level menu also includes Custom — but Custom is a derived state, not an applicable one. You can't "select Custom"; the system derives it automatically when your policy has been individually adjusted to a combination that doesn't match any preset bundle.
Custom mode exposes the individual toggles inside a collapsible drill-down section. Each toggle shows why it's locked ("required by Hardened"), what selecting it will force ("will enable Passphrase Encryption"), and what will be disabled if you turn it off ("will disable Strict mode"). The dependency graph is enforced server-side: even if you call the GraphQL API directly, a request that would create an inconsistent policy state returns ErrPolicyInconsistent with the violated rule.
Tip: If you're in Custom and want to return to a clean preset, just click the preset chip. The platform applies the full preset bundle atomically, overwriting your customizations for the flags that preset controls while preserving orthogonal settings (Passkey E2EE, BYOK, recovery-code state).
How It Works Under the Hood
The Security Levels feature is built around a single source of truth: a canonical preset table in api/internal/securityposture/preset.go that maps each level to its exact flag bundle. Every surface in the platform — the level selector UI, the scorecard chips, the security hero widget — reads summary.securityLevel from the server, which is derived live from your current policy via the SecurityLevelOf(policy) pure function.
When you click a level chip, the setOrgSecurityLevel mutation:
- Reads your current policy.
- Applies the preset bundle via
ApplySecurityLevel(current, level)— a copy-on-write merge that preserves orthogonal flags like Passkey E2EE and BYOK. - Runs
DependencyCheck(next)as defense-in-depth (preset bundles satisfy constraints by construction, but this catches any accidental preset table regression). - Persists the result atomically in a single database transaction.
- Emits a posture-transition event and an audit log entry (
org_security_level_changed).
The entire operation is atomic: you cannot be left with a half-applied policy where, say, Strict mode is on but encryption is still off.
Changing Your Security Level in VolatiCloud
Organization admins can update the security level from the Organization → Security page. The level selector appears in the Advanced Policy section (requires the manage-encryption scope, which is part of the admin role). Members without that scope see the Security Scorecard, which shows the current level as a chip alongside the other active security features.
When you change levels:
- Navigate to Organization → Security in the sidebar.
- In the Advanced Policy section, click the level chip you want to apply (Basic, Standard, Hardened, or Maximum).
- Review the implications callout — the UI shows which flags will change.
- Confirm. The platform applies the bundle atomically and the scorecard updates immediately.
If you're moving to Standard or higher for the first time and haven't yet set a passphrase, the security wizard will prompt you to set one before completing the level change. Passphrase setup is a prerequisite for any level above Basic.
Downgrading from Hardened or Maximum to Standard or Basic reduces your security posture. Existing encrypted data remains encrypted (no data is re-encrypted or decrypted just from a level change), but future decryption operations will use weaker authorization guarantees. Review your threat model before downgrading.
Why This Matters for Team Security
Crypto trading organizations face a specific challenge: multiple people need operational access, but not everyone should be able to change the security posture. The manage-encryption scope — required to use the level selector — is an admin-only scope. Regular members can see the current level, run bots, and execute backtests, but they cannot change the underlying policy.
This separation means a team member who needs to run a backtest at 2am doesn't also have the ability to silently downgrade the organization from Hardened to Basic to avoid entering the passphrase. The security posture is a governance decision; the platform enforces that boundary at the API layer.
The same server-side dependency enforcement applies to direct API consumers. If you're using VolatiCloud's API client and call setTrustPolicy with flags that create an inconsistent state, you get ErrPolicyInconsistent — not a silent accept. Impossible states are impossible everywhere in the stack, not just in the UI.
Choosing the Right Level for Your Organization
Most teams starting with VolatiCloud should begin at Standard. It's the inflection point where encryption is on (your API keys and strategy code are protected) and automation still works (your overnight bots don't page you to re-enter the passphrase). The operational cost is minimal — you set the passphrase once per session — and the protection is substantial.
Move to Hardened when your organization's policies require that decryption never happens without explicit per-action authorization — typically when you're running strategies with material capital and want auditability of exactly when decryption occurred.
Maximum is for organizations with dedicated infrastructure teams who are already running self-hosted runners and need data-residency guarantees. The setup is more involved, but VolatiCloud's Bot Runners documentation covers the runner deployment options in detail.
Stay at Basic only for non-production environments.
Security Levels ship today and are available for all organizations. If you're on a production deployment and haven't yet configured a passphrase, now is the right time to move from Basic to Standard. Start at console.volaticloud.com → Organization → Security, or read the Encryption docs for a detailed breakdown of what each layer protects.