Security

Reporting a vulnerability

Email hello@thecompound.tech. Include the URL, what you did, and what you saw. There is no bounty and no NDA to sign. We will confirm receipt, and we will tell you what we changed.

The same address, with a machine-readable expiry, is published at /.well-known/security.txt under RFC 9116.

Accounts

ParseRail has user accounts. What is stored against one, and who else touches it, is below.

What is stored

• Your account: the email address you sign in with, your API keys (stored as a hash and a short prefix, the full key is shown once and never again) and your credit balance
• A usage row per call: which endpoint, when, whether it succeeded and what it cost in credits. That ledger is what your balance is computed from
• The documents you send are forwarded to a third-party model provider, which reads them to generate your response. What we ourselves store depends on how you call: a synchronous call writes no document content to our database at all, only a usage row. An asynchronous job stores the text you sent and the JSON we returned on the job row, because that is what you fetch the result from later; uploaded file bytes are stripped before that row is written
• Anonymous usage analytics on this marketing site, page views and clicks

Who else processes data

• Supabase, authentication, the key store and the usage ledger
• Stripe, takes credit top-ups and holds the card details, we never see a card number
• Google, the OAuth sign-in option, if you use it
• Google, a model provider your document may be routed to in order to produce the JSON
• OpenAI, a model provider your document may be routed to in order to produce the JSON
• Anthropic, a model provider your document may be routed to in order to produce the JSON
• Vercel, serves this site and the API, and holds their access logs

Also true

• A call is served by whichever model rail is configured and answers first; the request is attempted against the rails in a fixed order and moves on when one fails. Which of the model providers listed above receives a given document therefore depends on which rail served that call, and we do not promise it will be any particular one.
• An API key is stored as a hash plus a short prefix. The full key is displayed once, at creation, and cannot be recovered, which is why revoking and reissuing is the only recovery path, and why that is the honest design.
• Credits are charged on success only. A call that errors does not bill, so a broken integration cannot quietly drain a wallet.
• Sign-in lives on api.thecompound.tech rather than on this host, deliberately: Supabase cookies and the OAuth redirect URIs are host-scoped, and serving the gate on the marketing host bounce-loops it.
• The playground on this site does not call the API. It replays responses captured from production against a fixed set of sample documents, so nothing there is generated on demand, loading the page invokes no model, and there is nothing for it to collect.

ParseRail is built and run by Compound Labs. The declarations on this page are part of this product's own configuration and are re-checked at every deploy against the repository they describe: a product that claims to have no accounts and ships an authentication route fails the build, and so does one that takes payment without naming its payment processor here.