Skip to main content
The vault is where your credentials are stored. You can add entries through our UI or API. When adding an entry to your vault through our API, you have to encrypt the user name and password before sending it to us. You can find your encryption key in your workspace settings. Here’s a code snippet you can use:
  • Python
  • JavaScript
from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes
import binascii, json

def encrypt_message(message: dict, key_hex: str) -> str:
    key = binascii.unhexlify(key_hex)  # 32‑byte AES‑256 key
    iv = get_random_bytes(12)          # 96‑bit IV for GCM
    serialized = json.dumps(message)   # ensure deterministic encoding
    cipher = AES.new(key, AES.MODE_GCM, iv)
    ciphertext, tag = cipher.encrypt_and_digest(serialized.encode())
    return iv.hex() + ciphertext.hex() + tag.hex()

​
Security Overview

Our credential vault adopts the envelope‑encryption pattern recommended by NIST SP 800‑57 and mirrors proven designs used by services like AWS Secrets Manager and Google Secret Manager. Plaintext credentials are never persisted or transmitted to our servers. This page outlines the key design choices behind that guarantee.

​
Key hierarchy

  • Per‑user data key (AES‑256‑GCM)
    • Can be generated and managed in your workspace settings
    • Stored only in encrypted form.
    • Can be rotated at any time from the dashboard.
  • Vault master key – a 256‑bit key held in AWS KMS/HSM.
    • Used solely to encrypt/decrypt each user’s data key.
    • Stored as a Kubernetes Secret

​
Secret ingestion flow

  1. Client encrypts the credential locally with their data key.
  2. The ciphertext is sent to the vault. The vault verifies the envelope and stores it verbatim.
  3. The vault keeps a mapping: user‑id → { encrypted_data_key, ciphertext, metadata }.
The vault rejects any credential that is not already encrypted with the correct data key for that user.

​
Runtime access

When a browser agent needs a credential:
  1. The agent requests the ciphertext.
  2. The vault decrypts the data key entirely in‑memory using the master key mounted from the Kubernetes Secret.
  3. The agent uses it, and immediately zeroises the buffer.
  4. No decrypted value is logged, cached, or exported.

​
Key rotation

Users may rotate their data key at any time. The vault automatically:
  1. Generates a new data key.
  2. Decrypts each stored secret with the old key within a secure enclave.
  3. Re‑encrypts the secret with the new key and updates metadata.
  4. Shreds the old key material.

​
Threat model & mitigations

ThreatMitigation
Database breachSecrets remain encrypted with per‑user keys; attacker lacks the data keys.
Compromise of a single data keyBlast radius limited to that user only.
Master key exposureMaster key stored in KMS with hardware isolation & strict IAM; usage logged and alerted.
Replay/tamperingAES‑GCM tag validation prevents bit‑flips or stale ciphertext from being accepted.
For security questions or key‑rotation assistance, email founders@cloudcruise.com.

​
Credential Configuration

Vault entries support comprehensive authentication and session management options to accommodate different website requirements and security needs.

​
Two-Factor Authentication (TFA)

CloudCruise supports multiple TFA methods for automated login flows:

​
Authenticator App (TOTP)

  • Method: AUTHENTICATOR
  • Setup: Provide the TOTP secret key from your authenticator app
  • Usage: CloudCruise generates time-based one-time passwords automatically during login

​
Email TFA

  • Method: EMAIL
  • Setup Options:
    1. Register the CloudCruise email directly with the target account
    2. Forward TFA emails from your account to the CloudCruise email
  • Usage: CloudCruise automatically processes TFA codes received via email

​
SMS TFA

  • Method: SMS
  • Setup Options:
    1. Register the CloudCruise phone number directly with the target account
    2. Forward TFA SMS messages to the CloudCruise phone number
  • Usage: CloudCruise automatically processes TFA codes received via SMS

​
Session Persistence

Control how browser state is maintained across workflow executions:

​
Storage Options

  • Cookies: Maintains authentication cookies between runs
  • Local Storage: Preserves local storage data across sessions
  • Session Storage: Maintains session storage (typically cleared between browser sessions)

​
Concurrent Sessions

  • Allow Multiple Sessions: Enable parallel workflow executions using the same credentials
  • Max Concurrent Sessions: Limit the number of simultaneous sessions (leave empty for no limit)
  • Prevent Concurrency During Login: Block other sessions while login is in progress

​
Session Expiration

Configure automatic session cleanup:
  • Expiry from Last Use: Sessions expire after period of inactivity
  • Expiry from Creation: Sessions expire after absolute time from creation

​
Proxy Configuration

Override workflow proxy settings at the credential level:

​
Static IP Targeting

  • Enable Proxy: Use a static residential proxy for this credential regardless of workflow settings
  • Target IP: CloudCruise selects the proxy closest to the specified IP address
  • Use Case: Ideal for geo-restricted content or region-specific testing
  • Proxy Priority: Credential-level proxy settings take precedence over workflow-level configurations, allowing fine-grained control over network routing for specific accounts.