Security model

What we store, where, and what happens if any of it leaks. Plain English. No marketing copy.

1. What's actually at risk

Asset	Where stored	Form	Worst case if leaked
Your Mirror API key (`ce_mirror_…`)	Browser `localStorage` + your records (Catalyst Edge never has the cleartext after signup)	Cleartext on your side; only sha256 hash on our side	Read your paper portfolio + place paper orders for your account. No real money. Zero financial loss.
Your email address	Postgres `mirror_users.email`	Cleartext (used for recovery)	Spam. We do not share it.
Catalyst Edge admin keys (real-money brokers)	Cerebro filesystem only — `/opt/catalyst/.sec_email_env`, mode 0600, root-only	Cleartext (legacy; encryption-at-rest planned)	NEVER reachable from any web endpoint. Verified by grep across the entire web stack. Architecturally separated.
Phase B: your real Alpaca tokens (when you connect a live broker)	Postgres, encrypted at rest with Fernet (AES-128 + HMAC)	Encrypted; master key only on cerebro filesystem	Database breach alone is useless without the master key. Two systems must be compromised at once.

2. The architectural separation

Mirror users cannot trigger real-money trades on Catalyst Edge brokers

This is not a policy — it's a code property. The web-facing API server (api_server.py, api_v1_router.py) never imports the modules that hold real-money broker credentials (agent_tradier_equities.py, agent_coinbase.py). A user calling /api/v1/mirror/* with their key only writes to mirror_orders — a paper-only table. Real-money agents run as separate cron jobs with their own root-owned environment.

You can verify this yourself: grep -E 'TRADIER_TOKEN|COINBASE_API_KEY' <web-stack-files> returns zero matches.

3. Hardening already in place

→ API keys hashed. We store sha256(key), not the key. We literally cannot show it to you again — recovery issues a new one.

→ Rate limiting. 60 calls/min per key, enforced server-side via the audit log.

→ Audit log. Every API call (including failed auth attempts) is logged with method, path, status, IP, user-agent.

→ Cross-user isolation. /api/v1/portfolio/{client_id} verifies the API key matches the client_id and returns 403 otherwise.

→ Idempotent fanout. Each published pick mirrors to a user exactly once via a pick_id hash; replay attacks have no effect.

→ Rotate / revoke endpoints. POST /api/v1/mirror/rotate issues a new key + invalidates the old, atomically. POST /api/v1/mirror/revoke permanently disables the account.

→ Email-bound recovery. POST /api/v1/mirror/email_recovery issues a fresh key for an existing email. Returns 200 even for non-registered emails (prevents enumeration).

→ HTTPS everywhere. Cloudflare TLS 1.3 in front; HSTS preload pending.

→ Database. Supabase Postgres with pgcrypto, supabase_vault. Connection over TLS.

4. Hardening on the roadmap (Phase B prerequisites)

→ Encryption-at-rest for any user broker tokens we ever hold (master key already provisioned at MIRROR_VAULT_KEY on cerebro).

→ HMAC-signed requests for trade execution endpoints.

→ Per-trade explicit confirm default. Pre-authorization only after user signs a strategy-specific consent.

→ 2FA via TOTP for the recovery flow.

→ Anomaly detection: flag any unusual rate / pattern, require fresh confirmation before honoring.

→ SOC 2 Type II when revenue justifies (~$50k MRR threshold).

5. What you should do

→ Save your API key in a password manager (1Password, Bitwarden) the moment we issue it.

→ Rotate it any time you suspect leak: POST /api/v1/mirror/rotate.

→ Pause auto-mirroring while you're reviewing: POST /api/v1/mirror/pause.

→ Use a unique email per service so a leak elsewhere doesn't compromise this one.

→ Until Phase B ships, do not give any third party your real broker credentials claiming integration with Catalyst Edge — we don't accept them.

6. Reporting a vulnerability

Email [email protected] with subject [security]. Mention "Mirror" or "API" in the body. We aim to acknowledge within 48 hours and have a fix or workaround within 7 days for high-severity findings. We do not yet run a paid bounty but will publicly credit good-faith reports.

Last reviewed: 2026-05-08. This page is the source of truth for our current security posture. We commit to updating it any time the posture changes — encryption, scope, or process. Legal & full disclosures →