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()

const crypto = require('crypto');

function encryptMessage(message, keyHex) {
    // Convert hex key to bytes
    const key = Buffer.from(keyHex, 'hex');

    // Generate a random initialization vector (IV)
    const iv = crypto.randomBytes(12);

    // Serialize message
    const serializedMessage = JSON.stringify(message);

    // Create cipher object and encrypt the message
    const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
    let encrypted = cipher.update(serializedMessage, 'utf8', 'hex');
    encrypted += cipher.final('hex');

    // Get authentication tag
    const tag = cipher.getAuthTag().toString('hex');

    // Return IV, encrypted message, and tag as hex strings
    return iv.toString('hex') + encrypted + tag;
}

​

Security Overview

​

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

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

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

​

Credential Configuration

​

Two-Factor Authentication (TFA)

​

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

​

Email Magic Links

• Method: MAGIC_LINK
• Setup Options:
  1. Register the CloudCruise email directly with the target account
  2. Forward magic-link emails from your account to the CloudCruise email
• Usage: CloudCruise extracts the login link from the email and navigates to it during the TFA node

​

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

​

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

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

​

Credential Pooling

{
  "run_input_variables": {
    "USER": [
      "user-id-1",
      "user-id-2",
      "user-id-3"
    ]
  }
}

const run = await client.runs.start({
  workflow_id: "your-workflow-id",
  run_input_variables: {
    USER: ["user-id-1", "user-id-2", "user-id-3"],
  },
});

run = client.runs.start(
    StartRunRequest(
        workflow_id="your-workflow-id",
        run_input_variables={
            "USER": ["user-id-1", "user-id-2", "user-id-3"],
        },
    )
)

​

Proxy Configuration

​

Proxy Modes

​

Custom URL (bring-your-own proxy)

• HTTP CONNECT proxies cannot carry UDP by spec. CloudCruise routes DNS over TCP through the proxy so resolution still works; Chrome’s QUIC attempts fail fast and fall back to TCP/HTTP2 automatically; WebRTC over UDP is unavailable.
• SOCKS proxies vary — the spec supports UDP via UDP ASSOCIATE but many real-world deployments are TCP-only. On the first activation of a custom SOCKS proxy CloudCruise probes UDP support via a short DNS query through the proxy. If UDP works, full UDP egress (QUIC, WebRTC, UDP DNS) is preserved. If UDP doesn’t work, the worker reactivates with TCP DNS — same fallback as HTTP CONNECT. The probe result is cached for 24 h.

• The URL is encrypted at rest with the workspace’s AES-256-GCM key (same protection as vault passwords).
• On every dispatch, the URL is re-validated against SSRF rules: private/loopback/link-local IPs (incl. cloud metadata services at 169.254.169.254), .local/.internal/etc. suffixes, and hosts that resolve to CloudCruise infrastructure are all rejected.
• For http/socks5 schemes, the hostname is DNS-pinned at dispatch to eliminate rebinding windows. For https, the hostname is preserved for TLS SNI validation.

• Target-site traffic flows through your proxy. The proxy operator can see and log everything the worker sends to and receives from the target site for plain HTTP. For HTTPS, traffic is end-to-end encrypted to the target — your proxy sees the SNI and connect-traffic envelope but not the request/response body unless it performs TLS interception with a CA that the worker trusts (which is not possible on CloudCruise-managed workers).
• CloudCruise infrastructure traffic (auth tokens, websocket, telemetry, screenshot uploads) is bypassed — it never traverses your proxy. The bypass covers *.cloudcruise.com, *.cloudcruise.app, and your configured Supabase host.
• If sing-box (the OS-level proxy router) dies mid-session, the worker fails the run rather than reverting to direct internet egress. This protects compliance use cases where all automation traffic must stay inside the customer’s network.