How we protect your keys and your code
StrategyCheck does not have users with accounts yet: the private beta opens on February 28, 2027. So this page separates three things: what already exists and was verified, what is written but switches on with accounts, and what we do not have. We never store your broker password, we can never withdraw your money, and your code runs isolated and without network. Every claim carries its label.
Today exists and was verified. Under construction is written or designed, but has not been used with a user account yet. Not available does not exist and we do not promise it for a date, unless a date is given.
Contents
- What data we store
- Your broker keys
- Your Python code
- No custody
- One customer cannot read another
- A decision log that cannot be edited
- Where everything runs
- What we do not have yet
- How to report a vulnerability
1. What data we store
| What | When | Detail |
|---|---|---|
| Waiting list | Today | Your email, the case you picked (optional), the language, which section of the site you signed up from, the date, and an ip_hash: an irreversible digest of your IP address (SHA-256 of the IP, the day and a salt, truncated). It changes every day and cannot be used to recover the IP. The table accepts sign-ups from the site, but a browser cannot read it. Details in Privacy. |
| Public engine status | Today | The Status page shows only aggregate facts about the product's own test account: counts, dates and verdict. It shows no money, positions or prices. |
| Your account | Under construction (beta) | Account email, your strategies (the rule or the code) and their versions, and paper trades and orders with the record of every decision. |
| What we do not store | Today | Your broker password, ever. Card data: nothing is charged today; when billing exists a third party (Paddle) will process it and card data will not pass through our servers. |
2. Your broker keys Under construction
With Alpaca the connection is OAuth: you authorize on Alpaca's own site and StrategyCheck receives a token with trading and data permission. It never receives or asks for your password. With Interactive Brokers, through the open-source bridge, credentials stay on your machine and we store nothing from the broker.
- Encrypted at rest. The token is stored in Supabase Vault, encrypted. The connections table only holds the secret's identifier, not the secret.
- Who reads it. Only the execution gateway, through server functions that only the service role can run. The panel (signed-in users) and the public cannot run them: some of the 58 automated tests in section 5 check this. Your strategy's runtime never sees the token.
- Revocable. You can revoke the permission at any time from your Alpaca account; the token stops working.
What is missing: the vault and the read functions have been applied to the database since October 29, 2026, but the OAuth flow with Alpaca is not wired up yet. Today we store no key from any user, because there are no accounts yet.
3. Your Python code Under construction
- Isolated, no network. Your script runs in a separate process, inside a container with no network and a read-only file system. Its only channel is a local socket to the gateway: price bars come in, intents (not orders) go out. It cannot open connections, read the database or see any key.
- With limits. CPU, memory and time per cycle are bounded. If a cycle runs over its time, the gateway kills the process, the cycle fails and it is logged.
- Checked first. A validator checks syntax, allowed dependencies, look-ahead and time per cycle before accepting a version. The validator is not the security barrier: the container is.
- Not shared, not used for training. We do not train any model on your code and we do not share it with other users. There is also no language model in the execution loop: none decides an order.
What is done and what is not: the protocol between the gateway and the sandbox, the time cut-off and the validator are written and have automated tests, but those tests run the sandbox as an ordinary process. The container with gVisor and no network has not been tested on a real server yet; it is measured before the beta. Until then no user's code runs.
4. No custody Today
We hold no broker or bank accounts in your name and have no permission to withdraw or transfer your money. Your money is always at your broker. With the trading permission the system can send orders to your account (that is what you ask it to do), and they always go through risk limits that no text can override. In the beta, trading with real money does not even exist: paper only. Trading real money, when it exists, is your decision and depends on an approval from Alpaca that we do not have yet.
5. One customer cannot read another Today
Every row of customer data carries its customer identifier (tenant_id) and the database enforces row level security (RLS): the policy takes the customer from a user attribute that the user cannot edit, not from one they can. 58 automated tests check it; the last run was on in the product's Supabase project and 58 of 58 passed. Among other things they verify that:
- a user does not read rows of another customer;
- an attribute the user can edit themselves grants no access;
- the public without a session reads nothing;
- a signed-in user cannot write directly;
- the panel and the public do not run the functions that read secrets.
Limit: the tests cover the main tables (trades, events, strategies, daily summaries, accounts and a few more). The remaining tables with a customer identifier use the same policy template, but still have no tests of their own. And today there is a single real customer: the product's own test tenant.
6. A decision log that cannot be edited Today
Events, intents, risk checks, fills and closed trades are stored in append-only tables: the database rejects UPDATE and DELETE, even for the service role. Strategy versions and risk limits are immutable too: changing them creates a new version. Each decision stores the hash of the data that produced it (bars, positions, parameters, version), and it can be replayed with the same data to check that it gives the same result.
Limit: this is a database protection, not a third-party audit. We do not timestamp the log with an external service or sign it: whoever administers the database could, in theory, switch the protection off. That is why there is a hash and a replay: if something had changed, it would not match.
7. Where everything runs
- Supabase (Postgres database, authentication, secrets vault): Frankfurt, Germany region (the project pooler is aws-1-eu-central-1). Free plan: Supabase keeps daily backups of the database.
- Hetzner (the server where the execution gateway and the engine run): data center in the European Union.
- Cloudflare (site, DNS and the form's functions): serves the site over HTTPS only, with HSTS and security headers (CSP, X-Frame-Options, nosniff).
- Alpaca: market data and, when you connect your account, the broker.
Sub-processors and what they do are listed in Privacy. We have not yet tested a full restore from backup.
8. What we do not have yet
| What | Status | Date |
|---|---|---|
| Second factor (2FA) on the panel | Not available | Estimated: before the beta (February 28, 2027) |
| SOC 2 (or any other certification) | Not available | No date |
| External security audit / penetration test | Not available | No date |
| Bug bounty program | Not available | No date. We do accept reports (section 9), without a reward |
| External timestamping of the decision log | Not available | No date |
| Code sandbox tested on a real server | Under construction | Before the beta |
In the meantime, what exists is concrete technical controls (sections 2 to 7) and automated tests. They are not the same as a third-party certification, and this page does not present them as one.
9. How to report a vulnerability
Write to [email protected] with the subject "Security". Tell us what you found and how to reproduce it. We reply within 72 hours. We ask you to research in good faith: without accessing other people's data, without degrading the service and without publishing the details before we have fixed it. We do not offer a reward; if you want, we will name you as the reporter.
This page describes technical controls of a piece of software. It is not a guarantee of any outcome or a contractual commitment: the terms are in Terms. StrategyCheck is not an investment adviser.