How TradeLoop Keeps Your Polygon and Broker API Keys Safe (Device-Bound Encryption)

The Plaintext Secret Problem

A trader's API keys are not low-stakes secrets. A Polygon or Finnhub key is your paid data feed. A broker key can read positions — and in some cases place orders. The default way most tools configure credentials is a JSON file that looks like this:

{
  "providers": {
    "polygon": { "api_key": "your-actual-polygon-key-here" },
    "broker":  { "api_key": "live-trading-key", "secret": "..." }
  }
}

This file sits in your home directory, readable by any process running as your user. If your machine is compromised, if you accidentally commit it to a repo, if a malicious npm package reads environment variables — your data feed and possibly your brokerage account are exposed.

TradeLoop's credential system makes this impossible by construction.

Layer 1: Device-Bound Master Key

When you first run tradeloop login, we generate a 256-bit random master key and store it in your OS-native keychain — Keychain Access on macOS, libsecret on Linux, Windows Credential Manager on Windows. This key never touches disk in plaintext. It is bound to your device and your user account.

Every operation that reads or writes credentials fetches this key from the keychain first. If the keychain lookup fails (the key was deleted, permissions changed, the user isn't the key owner), credential operations fail safely rather than falling back to unencrypted storage.

Layer 2: Encrypted Credential Files

All provider API keys and OAuth tokens are encrypted with AES-256-GCM using the master key before being written to disk. Each encrypted blob includes a random 96-bit nonce, so identical secrets produce different ciphertext on every write.

The file structure looks like:

~/.tradeloop/
  credentials/
    polygon.enc      # AES-256-GCM encrypted Polygon API key
    finnhub.enc
    broker.enc       # broker key + secret
  identity.enc       # Encrypted Supabase session (identity JWT)

No plaintext secrets anywhere on disk.

Layer 3: Atomic Writes

A subtle but critical detail: we write credential files atomically. The sequence is:

1. Encrypt the new credential blob in memory

2. Write it to a temp file in the same directory (polygon.enc.tmp)

3. rename() the temp file over the existing file

The rename() syscall is atomic on all POSIX systems. There's no window where a partial write leaves a corrupted credential file — you either have the old key or the new one, never a broken intermediate state. This matters when the monitoring loop is polling a feed concurrently with a config update that's also touching credentials.

Layer 4: Vault Sync (Optional)

If you trade from more than one machine — a desktop at home, a laptop on the road — TradeLoop provides an encrypted vault sync via Supabase. Credentials are encrypted client-side before upload; we only ever see the ciphertext. tradeloop update pulls the latest from the vault and re-encrypts it with the local machine key.

Prefer to stay entirely local? Opt out of vault sync. The device-bound encryption layers work identically offline. Your Polygon key never leaves 127.0.0.1.

How Skills Use Keys Without Holding Them

When your agent invokes a TradeLoop market-data tool — say a Polygon aggregates call — the daemon injects the current API key as an environment variable just before spawning the skill process:

POLYGON_API_KEY=...   # injected by daemon at call time

The skill reads the variable, calls the Polygon API, and returns the result. It never reads or writes the credential store itself. This isolation means a buggy skill can't leak your key to disk, and a compromised skill process can't exfiltrate the master key, because it never has access to it.

The Threat Model

What TradeLoop protects against:

• Plaintext API keys in config files being committed to git
• Keys readable by other processes running as your user (they're encrypted at rest)
• Partial writes corrupting credentials (atomic rename)

What TradeLoop doesn't protect against:

• A fully compromised OS where the attacker can dump keychain contents
• A malicious skill that exfiltrates a key from its own process environment at runtime

The second threat is a property of any system that injects credentials into subprocess environments. We mitigate it through skill review and code signing, but can't eliminate it architecturally — it's the same threat model as any secrets manager that injects env vars. For a key that can move money, that's a tradeoff worth understanding before you wire in a live broker.