Security

1. Scope, and the division of responsibility

Most security failures in connected financial software happen at a boundary nobody wrote down. This section is first for that reason.

In scope: the Warren application, its production infrastructure, the data it stores, the devices used to administer it, and the vendors named in section 8.

Expressly out of scope:

• Your brokerage account and its security. That relationship is between you and your broker. Warren does not open, maintain or control brokerage accounts, does not take custody of assets, and does not hold client funds.
• Your own credentials and devices. Warren never requests, receives or possesses your brokerage password or second factor. You authenticate directly with your own broker. This is a property of the architecture, not a promise about our conduct.
• Execution, settlement, custody and the accuracy of data supplied by your broker. Those are your broker’s, under your agreement with them.
• Third-party market data content. We transmit every figure with its stated source; correctness at source belongs to the source.

Your responsibilities: keeping your Warren credentials confidential, securing the devices you use, telling us promptly of any suspected compromise, revoking a brokerage connection you no longer intend to use, and reviewing any order before you authorise it. Warren presents information and submits instructions at your direction; every trading decision is yours.

2. Data classification and handling

Data is handled in four classes.

• Secrets — brokerage credentials, API keys, session signing material, step-up credentials. Never returned by an API response, written to a log, or rendered in any interface. Displayed only as a mask computed when the value is written; the read path never decrypts for display.
• Client account data — positions, balances and orders retrieved from a brokerage on your behalf. Scoped to you and to administrators of your own firm. Never pooled across clients, never used to train models, never resold or redistributed. Cached only under a key containing both firm and owner identifiers.
• Operational data — accounts, roles, invitations, audit records. Role-scoped and least-privilege. Administrative action against it is recorded in an append-only audit log naming the person who authorised it.
• Market and reference data — carries redistribution rights as a typed property with three values, in which “not established” is treated as not permitted. The system declines to serve data whose licence has not been established rather than assuming permission. See disclosures.

No client data is placed in URL parameters or query strings, and no secret is transmitted to any party other than the venue that issued it.

3. Access control

• Access is invitation-only and fails closed. Registration requires a single-use, expiring, cryptographically random token bound to the invited address, redeemed atomically and rate-limited by source address.
• Social sign-in cannot create an account. Every configured provider has implicit sign-up disabled, so authenticating with an external identity can sign an existing member in but cannot admit a stranger.
• Tenancy isolation fails closed. Every query is scoped through a single facade; an unusable or absent scope resolves to a filter that matches nothing, never to an unfiltered query. Our tests assert on the generated filter rather than on returned rows, because a widened filter still returns correct-looking data in a small dataset.
• The administrative surface is not disclosed. It is served only on a dedicated hostname; on every other hostname the administrative path returns a 404 rather than a redirect, so its existence is not revealed.
• Consequential administrative actions require a step-up credential held in a separate store, hashed with scrypt, single-use, scoped to one action and short-lived. Holding a session is not sufficient authority.
• Automated assistants hold no standing authority. They act on the authenticated operator’s own request and carry that operator’s identity. Anything that writes, sends, spends or revokes requires explicit on-screen authorisation, and a spoken confirmation authorises nothing.

4. Encryption at rest and in transit

At rest. Brokerage credentials and API secrets are sealed with AES-256-GCM, per record, with a random 96-bit initialisation vector. GCM authenticates the ciphertext, so tampering is detected on decryption rather than yielding a plausible value. Administrative integration secrets are held under a separate key domain and additionally bind the field name as additional authenticated data, so such a value cannot be relocated into another field’s slot. We verified this adversarially: the raw database document shows no plaintext, and decryption fails with the database connection string or any guessed passphrase. A database backup alone is inert. Encryption keys are held as platform secrets, never in source control, and are not retrievable through our deployment tooling — only their digests are visible.

In transit. All public traffic is HTTPS with TLS terminated at the edge, and HTTP Strict Transport Security is enforced with a two-year max-age including subdomains. Connections to venues and data sources are TLS.

Response headers. Enforced on every production response: Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, a Content-Security-Policy restricting frame ancestors, base URI, object sources and form actions, and a Permissions-Policy that denies camera, geolocation, payment and USB by default.

5. Vulnerability and patch management

• Production is immutable. It runs as container images on Firecracker microVMs. There is no interactive shell in the serving path and no in-place mutation: patching replaces the machine rather than modifying it. There are no long-lived servers accumulating drift, and rollback is selecting a prior release.
• Dependencies are installed from a committed lockfile, so builds are reproducible and every dependency change is visible in version control. Images are content-addressed by digest.
• Verification on every change — type checking across the codebase and more than 12,500 automated tests, including tests that specifically pin security properties. Security-critical guards are additionally mutation tested: the defect is deliberately reintroduced and a test confirmed to catch it, so a control is demonstrated rather than asserted.
• Stated plainly: no third-party penetration test has been performed to date, and there is no automated dependency-scanning pipeline.

6. Incident response and recovery

On a confirmed incident we contain first — revoking affected credentials and sessions, and disconnecting affected venue connections where a brokerage credential is implicated. We then establish scope from the append-only audit log, notify affected clients and any venue whose data or credentials are implicated, deploy the fix as a new release, rotate potentially exposed secrets, and add a test that fails if the defect recurs.

Because credentials are sealed with a key held outside the database, exposure of database contents alone does not expose credentials. Rotating that key invalidates all sealed values and requires reconnection — a deliberate trade in favour of containment.

Continuity. Warren holds no client assets or funds, so an outage here does not impede your access to your own brokerage account or positions. You retain your direct brokerage relationship at all times. The application itself is stateless and rebuilt from version control; recovery is a redeployment.

7. Physical security

Warren operates no offices, data centres or physical infrastructure of its own. Production is hosted by Fly.io and MongoDB Atlas, both of which operate in audited third-party facilities. Devices used to administer production require full-disk encryption and multi-factor authentication.

8. Vendor risk

Vendors are selected for the minimum access needed, and no vendor is given standing access to client brokerage credentials. Material vendors are our application host, our database provider, our DNS provider, our transactional email provider, our voice transport and model gateway, and the brokerage aggregation service through which you authorise a connection to your own broker.

Models and AI. Model inference is used for analysis and conversation. Client brokerage credentials are never placed in a model context. Components that read account data on an operator’s behalf call our own permission-checked interfaces rather than the datastore directly, so that redaction applied at that layer cannot be bypassed. Client data is not used to train third-party models.

9. Assurance and certification

Our assurance model is verification in code rather than attestation on paper. We hold no SOC 2, ISO 27001 or equivalent certification, and we employ no dedicated security personnel; the company is small and the document owner is accountable. What stands in their place: every control here is individually verifiable and demonstrable on request, immutable infrastructure removes the largest class of operational risk, and the absence of custody over client assets or funds materially limits loss exposure.

Any control described on this page can be demonstrated on request, including a walkthrough of the enforcing code and its tests. We would rather a counterparty find a problem now than a client find it later.

10. Reporting a vulnerability

Please report suspected vulnerabilities to security@warrendavisdata.com. Tell us what you found and how to reproduce it. We will acknowledge, investigate, and tell you what we did. We will not pursue action against good-faith research that respects client data and avoids degrading the service.

11. Status of this document

This is a statement of the security practices in effect at the date shown. It is not a warranty, guarantee or contractual undertaking, and it does not vary the terms of any agreement between us. Practices evolve; this page is reviewed at least annually and on any material change to our architecture, vendors or regulatory position. Where this page and an executed agreement differ, the agreement governs.

Our full Cybersecurity Policy is published — data classification and handling, access control and privileged access, encryption at rest and in transit, vulnerability and patch management, incident response and disaster recovery, physical security, and vendor risk management.

See also our Privacy Policy, Terms of Service and Disclosures.