How your brokerage credentials are stored — and why you should trust it

Your brokerage API credentials — the keys that allow Apex1819 to place trades on your behalf — are stored using an encrypted vault, a server-side encryption layer where secrets are encrypted at rest with keys managed by the database infrastructure, never by Apex1819's application code. There is no database column anywhere in the Apex1819 schema that holds your API key or secret key in plaintext. This is enforced at the schema level: the database tables define no such column, and the application has no code path to write credentials anywhere except the encrypted vault.

The credential lifecycle is deliberately minimal: fetch once, use immediately, discard. When the system needs to place a trade, it retrieves your credentials from the vault for that single request, authenticates the broker API call, places the order, and deletes the in-memory credential object before returning. The credential does not persist in application state between trades. This is an architectural decision — not a policy statement — enforced by the structure of the code itself.

Supabase Vault explained

When you connect a broker account, Apex1819 stores your API key and secret key in the encrypted vault and receives a reference UUID. This UUID is what's stored in your account metadata alongside your connection details. The UUID is useless without the ability to query the vault — which requires server-side database access. Your browser never has, and cannot have, access to the vault decryption layer.

Why no plaintext storage exists

The Apex1819 database schema contains no column intended to hold credentials in plaintext. The broker connection records hold an encrypted vault reference — a pointer to the encrypted secret — and nothing else credential-related. This schema constraint means there is no mechanism, even for an Apex1819 engineer with full database access, to query a table and retrieve a user's API key in plaintext.

This distinction matters: many systems claim credentials are "encrypted" but store them in application database columns with application-managed encryption keys. If the application is compromised, the keys that decrypt the credentials are also compromised. The vault's architecture separates the decryption keys from the application entirely — they live in the database layer, not in application configuration or environment variables accessible to the application runtime.

The fetch-use-discard lifecycle

The trade execution system's credential handling is a strict fetch-use-discard cycle. At the moment a trade needs to be placed, the system calls the vault API with the reference ID, receives the decrypted credential, instantiates a broker client, places the order, logs the result, and then explicitly deletes both the credential object and the broker client from memory. The delete is not left to garbage collection — it is an explicit operation in the code.

The consequence: at any point in time between trades, Apex1819's application memory contains no user broker credentials. If the application were somehow compromised at a moment when no trade was actively being placed, there would be no credentials in memory to extract. The credential's window of existence in application memory is measured in milliseconds per trade — not minutes, hours, or persistently across sessions.

Row-level security at the database level

Every query originating from the frontend is executed with the authenticated user's session token. Row-level database isolation ensures that a query for positions returns only your positions, a query for signals returns only your signals, and so forth. This enforcement happens at the database layer, before the query result is returned to any application code. It cannot be bypassed by a bug in the frontend application logic.

Backend operations use elevated privileges that are necessary because the system needs to write trade results, update portfolio state, and read data across users during platform operations. These elevated credentials exist only in server-side environment variables and are never included in any frontend bundle, never returned to the browser in any API response, and never logged. The frontend code has no reference to them.

The 7-year immutable audit trail

Every trade decision — executed or vetoed — is written to an immutable audit log at the moment the decision is made. Each record includes a cryptographic hash computed from the decision's content at write time. If any record in the audit log were subsequently altered — by anyone, including Apex1819 engineers — the hash would no longer match, making the tampering detectable.

The audit trail is retained for 7 years, the standard requirement for financial record-keeping in the United States. It covers every execution and every compliance veto, with the exact parameters, signal scores, and account state that were present at decision time. This record is not just a security and compliance feature — it is the foundation of the counterfactual analysis system that allows the learning system to improve the AI's accuracy over time by comparing what was predicted with what actually happened.