We hold broker API credentials. That fact is unavoidable for a routing platform and is the largest single risk we carry. Here's what the current control stack does and what the launch-readiness work still pending will add.
What lives where today
- Credentials enter the platform over TLS, never logged, encrypted before they hit persistent storage with app-managed AES-GCM. They are never returned to a client in plaintext.
- Broker scopes are restricted to trading — withdrawal scopes are explicitly rejected at onboarding. If a broker only offers a single permission tier, we surface that clearly.
- Every credential read, write, rotation, and use is recorded in the audit log with an actor identity (user or system), an IP, and a reason. Reads outside an active trading-routing context page the on-call.
- Workspace isolation: every credential is scoped to a workspace; server-side query guards block cross-tenant access at the DB layer.
What is launch-readiness work still pending
Two things, both honest about their state. First, KMS-backed key rotation — moving the encryption keys out of app-managed storage and into a cloud KMS — is tracked as a launch gate but is not done yet. Second, an external penetration test against the credential-handling endpoints is scheduled but not complete; we will not publish the result until the test report exists and an independent auditor signs it.