Privacy & your code
The short version
- Your code is not used to train any model. Not ours, not the model providers'.
- We do not store the code you submit. It lives in memory for the length of your review session and is gone when you disconnect.
- We do save what a review found: the issues, the discussion and the final document, so a reload doesn't lose it. Never the files themselves.
- We do store metering data: how many tokens a review used, which model, and what it cost us. Never the content.
- To review your code, we must send it to the model providers. That is the product. Who they are, and what they may do with it, is set out below.
1. Who we are
Apex Directive is operated by StackForge Labs, LLC. If you want to reach a human about anything on this page, write to privacy@apexdirective.dev.
2. What happens to code you submit for review
This is the section you came for, so it goes first and it is specific.
While a review is running
The files you attach are held in memory by our engine, for the lifetime of one WebSocket connection. They are sent to the model providers that make up your panel, and their responses come back to your browser.
We write no part of your code to disk, to a database, or to a log. There is no table it lands in, and there is no backup of it, because there is nothing to back up.
When the review ends
When you close the tab, sign out, or lose your connection, the engine's copy of the session is destroyed and the files go with it. They are never written anywhere.
Saved reviews: the findings, not the code
Your browser saves what a review produced to your account, so a reload does not lose work you paid for and you can reopen a review from last week. That means the issue list, the discussion, and the final document.
It does not mean your code. Saved reviews record the names of the files reviewed and nothing of their contents. There is no setting that changes this and no plan on which it differs.
The consequence is real and we would rather state it than quietly widen what we keep: a reopened review can be read, searched and exported, but re-running it needs the files attached again. That is the cost of the promise above, and we think it is the right way round.
You can delete any saved review from the History screen. It goes immediately. There is no trash we quietly keep.
Reviewing straight from GitHub
You can connect a GitHub app and review a pull request without downloading and re-uploading its files. What the app may read is decided by you, on GitHub, and it is narrow: repository contents and pull requests, both read-only, on only the repositories you choose. It cannot write to your code, open or comment on anything, or see a repository you did not select.
Code pulled from GitHub follows exactly the same path as a file you upload: held in memory for the life of one connection, sent to your panel, and never written down. Connecting GitHub does not create an exception to anything above it on this page.
A review pulled this way additionally records where it came from — the repository name, the pull request or branch, and the commit — so a reopened review can tell you what it read. That is a label, not a copy: the code itself is no more stored than any other attachment.
We hold no long-lived GitHub credential. Access is a token minted for one hour at a time from our app's own key, and we store nothing that could outlive your removing the app. You can revoke it at any moment from GitHub's settings, without asking us, and it stops working immediately.
Everything we store, in one table
This is the whole list. None of it contains your file contents: the one row that touches a review holds what the review produced, never what you submitted.
| What | Why | Kept for |
|---|---|---|
| Email address, and a hashed password if you use one | To sign you in | Until you delete your account |
| Your settings: review templates, custom prompts you have saved, which models sit in which chair | So the app looks the same next time | Until you delete your account |
| Your own provider API keys, if you are on the BYOK plan | So the engine can run the panel on your keys | Until you remove the key or delete your account |
| Saved reviews: the issue list, the discussion transcripts, the final document, the names of the files reviewed, and — when the review came from GitHub — the repository, branch or pull request, and commit | So a reload does not lose a review, and so you can reopen an old one | Until you delete the review or your account |
| If you connect GitHub: which installation of our app belongs to your account, and the organisation or username it was installed on. No token, and no list of your repositories | So we know whose app to read a pull request through | Until you remove the app on GitHub or delete your account |
| Metering: per model call, the number of input and output tokens, the model, which phase of the review it belonged to, and what it cost | To enforce your plan's budget, and to know whether the business works | Retained after account deletion, with your identity removed (see §7) |
| Subscription state and Stripe customer id | To bill you and to know what you have access to | As required for tax and accounting records |
3. Training: the explicit statement
Nothing you send to Apex Directive is used to train, fine-tune, or evaluate any machine learning model. We do not do it, and we do not permit it downstream.
We have no training pipeline, no evaluation set built from customer data, and no arrangement with anyone to supply them. We could not train on your code if we wanted to: as described above, we do not keep it. Saved reviews are not an exception: they hold findings, and they are not used for this either.
Your code does reach the model providers, because that is how a review happens. We access those providers through their commercial APIs, whose terms exclude API content from training by default. We do not opt in to any program that would change that, and we do not enable any provider feature that retains your content for model improvement.
We are describing third parties here, so read this carefully: we can tell you which contractual terms we operate under and which settings we have chosen, and we do. We cannot personally guarantee another company's internal conduct. If that distinction matters to your organisation, and for some regulated work it should, the providers' own policies are the primary sources, and we have linked them below.
4. Who else sees your data
We use the following sub-processors. This list is exhaustive at the date above.
| Who | What reaches them | Their terms |
|---|---|---|
| Anthropic, OpenAI, Google | Your prompt and attached files, when a seat on your panel runs their model | Anthropic · OpenAI · Google |
| OpenRouter | Only if you configure an OpenRouter key yourself. It is available on the BYOK plan only, and never runs on our keys. | OpenRouter |
| Supabase | Your account, settings, saved reviews and metering rows. Never the files you attached. | Supabase |
| Stripe | Your email and payment details. Card numbers go to Stripe directly and never touch our servers. | Stripe |
We do not sell your data, and we do not share it with advertisers. There is no advertising or third-party analytics on the app.
5. Your API keys, if you bring your own
On the BYOK plan your provider keys are encrypted and stored in a vault that our application database cannot read directly. The browser can write a key and can ask whether one exists; there is no path by which the browser can read a key back, so a stolen session cannot be used to extract your keys. Only the engine can decrypt them, and only to make the model call you asked for.
Deleting a key deletes the encrypted secret, not just the reference to it.
6. Security
- Everything is encrypted in transit. The app refuses to connect to a review engine over an unencrypted connection unless that engine is on your own machine.
- Data is isolated per account at the database level, so one account's rows are unreachable from another's session.
- Dependency, container, secret and static analysis scans run against every change.
No system is perfect, and anyone who tells you otherwise is selling something. If you find a security problem, please write to security@apexdirective.dev. we would much rather hear from you than not.
7. Deleting your account
You can ask us to delete your account at any time by writing to privacy@apexdirective.dev. When you do, your settings and your stored API keys are destroyed, along with the encrypted secrets behind them.
Your metering rows are kept, with your identity detached from them. What survives is token counts, model names, phases and dollar amounts: the record of what the business spent, not who it was spent for. We are telling you this rather than claiming a clean sweep, because destroying those rows would silently rewrite our own financial history.
Depending on where you live you may also have rights to access, correct, export or object to the processing of your personal data. Write to the same address and we will action it.
8. Changes
If we change this policy in a way that affects what happens to your code, we will email you before it takes effect, rather than merely update the date at the top and consider you notified.