/PRIVACYPrivacy Policy
Privacy Policy
This is an LLM API whose whole point is that the operator cannot read your prompts. So this page does two things: it lists the data we do process — mostly a meter and an invoice — and it explains why the content of your requests is not on the list, in terms you can check for yourself instead of taking our word for it.
- Last updated
- Version
privacy@2026-09-27- History
- Every revision is a commit in this page’s repository.
/PP_01The short version
The short version
- We never store your prompts or the model’s answers. Not in the database, not in logs, not in metrics, not in error reports. Inside the enclave they are not readable by us in the first place — and you can verify that before you send anything, which is the part a privacy policy normally cannot offer.
- What we do keep is a meter. Per request: the model, how many tokens went in and out, what it cost, how long it took, and which API key made it. That is the billing record and the Activity screen.
- No cookie is set for analytics, on either surface, so there is no consent banner to click. This page uses a cookieless, aggregate tool; the console sends its events from our own servers, not from your browser.
- There is nothing to pay for yet, and we never see your card. Paid top-ups are not enabled on the service today. When they are, payment happens on Stripe’s own page and we keep the amount and Stripe’s reference for it — never the card.
- We do not sell or share data, and we run no advertising. There is nothing here for a Global Privacy Control signal to switch off, because there is no sale to object to.
/PP_02Who we are, and how to reach us
Who we are, and how to reach us
Confidential Router is a Super Protocol product. The controller for the processing described here is Super Protocol Corp., 65 Oceana Dr E, Apt 2F, Brooklyn, NY 11235, United States. That is the company that decides what is processed and why, and the one these rights are exercised against.
For anything about your data — access, export, correction, deletion, or an objection — write to privacy@superprotocol.com. A person reads it, and we answer within 30 days.
Security reports have their own address and their own policy: security@superprotocol.com.
The service is for developers and businesses, and accounts are for adults. We do not knowingly process the data of children; see the Terms of Service for eligibility.
/PP_03Three surfaces, and what runs where
Three surfaces, and what runs where
The product is three things on three hostnames, and they are deliberately not the same machine. It matters for this page, because what each one can see is different.
- router.superprotocol.com — this page. Marketing content, served as static files from a commercial cloud host. No account, no session, no prompt ever touches it. It sets no cookie.
- console.router.superprotocol.com — the console, where you sign in, create keys, see usage and buy credits. It runs inside the confidential cluster and holds the database described below.
- api.router.superprotocol.com — the OpenAI-compatible endpoint your code calls. It runs inside the confidential cluster too, in enclave memory, and TLS terminates inside the enclave rather than at a proxy in front of it. That is the difference between “we promise not to look” and “the front door is inside the box”.
The split is not cosmetic. TLS terminates per hostname, so a single host could not serve marketing from a commercial cloud and prompts from inside an enclave — a proxy of ours in front of the API would read every request in plaintext and break the binding between the evidence and the certificate. Separating the hosts is what keeps the claim on this page true.
/PP_04What we process to run the service
What we process to run the service
The tables below are the ones the service actually writes. The schema is public — see the data model — so this list can be compared against it rather than believed.
Your account
Your email address, your name, and the avatar URL your sign-in provider gives us, plus the date the account was created. If you sign in with GitHub or Google, we store the provider’s account id and the tokens that sign-in issued; if the deployment you use offers a password, we store a hash of it and never the password. Sign-in links and email verification codes are single-use and expire within minutes.
Signing in creates a session record: a session token, the IP address the sign-in came from, and your browser’s user-agent string. It is deleted when the session expires — 30 days, refreshed while you keep using it — or when you sign out. The session cookie is the only cookie either surface sets, it is strictly necessary for signing in, and it carries no analytics.
Your API keys
A key is shown to you once, at creation, and then only ever stored as a SHA-256 hash plus its first twelve characters for display. We cannot recover a key, which is also why we cannot mail you a copy of one. Each key keeps its name, the models it is allowed to call, its spending limit, when it was last used and whether it was revoked. Revoking is a timestamp, not a deletion, so past usage stays attributable to the key that made it.
The meter, one row per request
Per request we record: the model and endpoint that served it, the number of prompt and completion tokens, the cost and the prices those were computed with, whether it was streamed, whether it succeeded, the error or finish reason, the latency, the time to the first token, the tokens per second, a request id, which key was used, a salted one-way hash of the client IP address, and the time. We also record which published attestation evidence was current when the request was served, so you can show afterwards what was running.
There is no column in that table that can hold message text — and a unit test walks the table’s definition and fails the build if anyone adds one. The salted hash of the IP exists so that abuse can be investigated; the address itself is never written down, and the hash is only comparable by someone who already holds the deployment’s secret.
Credits and workspace
Every account gets a personal workspace: a name, a balance, and — once you have paid for something — the customer reference Stripe gave us and your automatic top-up settings if you switched them on. The credits ledger is append-only: grants, purchases, per-request usage and refunds are rows, a correction is another row, and nothing is ever edited or deleted.
Your settings, and the evidence you archive
Console preferences: whether to archive attestation evidence and for how long (90 days by default), whether to be notified when a deployment’s measurement changes, and whether to receive email receipts. Archived evidence is a fact about our deployment, not about you.
/PP_05What we never hold: your prompts
What we never hold: your prompts
Prompt text, completions, attachments and the inputs you send for embeddings are never stored — not in the database, not in logs, not in metrics, not in error reports. The router forwards request bodies upstream and counts tokens; it does not buffer them, inspect them or write them anywhere. A log sanitiser drops the fields a body arrives in before any line is written.
The reason to believe that is not this paragraph. It is that the deployment runs in CPU and GPU enclaves, where memory is encrypted and the operator — us — is outside the boundary, and that the deployment publishes signed evidence of exactly which code and configuration are running. Our open-source Gatekeeper checks that evidence against the TLS certificate of the connection it is about to use, on your machine, before your first prompt leaves it. If the running code changed, the evidence changes with it and a Gatekeeper pinned to what you reviewed refuses to send anything.
What we can still see, honestly stated: the metadata in the meter above, and — while a request is being served — its content in enclave memory, because that is what inference is. What we cannot do is read that memory from outside, keep it, or change the code that handles it without the evidence saying so. The threat model sets out each of these claims with the mechanism that enforces it and the residual risk that remains.
/PP_06Analytics
Analytics
We measure how the launch is going with two tools, both chosen because neither needs a cookie. The full list of events either one may receive is published as a machine-readable taxonomy, and the reasoning is in a public decision record.
This page: Plausible
Plausible Analytics (Plausible Insights OÜ, Estonia; data stored in Germany) receives the page URL and referrer, your browser, operating system and device type as categories, an approximate location derived from your IP address — the address itself is never stored — and a daily-rotating hash that lets a returning visitor be counted once without an identifier that follows anyone. Query parameters are not forwarded: the campaign tag travels as a named property, and an invitation code never leaves your browser.
Plausible sets no cookie, stores nothing on your device, and reads nothing from it: no cross-site identifier, no fingerprinting, no session recording, no advertising. It does record, in aggregate, how long a page was open and how far down it was read — as a percentage, not as a recording of anything. Retention: aggregate counts for as long as the site runs; the daily hash lives for its day.
This page does keep one thing in your browser, and it is not analytics: the invitation code from your link. §7 says what it is for.
The console: PostHog, from our servers only
The console loads no third-party analytics script, so your browser never talks to PostHog at all. Our own server sends the events after the fact they describe has already happened: that an account signed up, redeemed an invitation, created a key, sent its first request, requested a model, opened the feedback form. They are keyed by the account’s internal id — not your email, not your name — and carry no IP address; autocapture, session recording, heatmaps and surveys are switched off at the project. Two events are posted by the browser to our own server first, which validates them against the published list before forwarding.
PostHog Inc. is a US company; this project is on its EU Cloud, stored in Frankfurt. Retention: 12 months.
Legal basis, and why there is no banner
The processing runs on legitimate interest (GDPR Art. 6(1)(f)): understanding how a product we are launching is used, in aggregate, with no profiling, no advertising, no automated decisions about anyone, and nothing sold or shared. You can object at the address in §2 and we will exclude you.
The cookie-banner obligation in the EU comes from ePrivacy Art. 5(3), which is about storing or reading information on your device. Neither tool does either: Plausible stores nothing, and the console has no third-party script in it to store anything. That determination holds only while the configuration above holds — a browser SDK with persistence, session recording, an advertising pixel or an embedded third-party widget would each put a banner back on the table, which is why changing any of them is a recorded decision rather than a commit.
The price we pay for that, stated plainly: a visitor to this page and an account that appears later are not linked. The funnel is joined on the campaign tag from the invitation, not on you.
/PP_07Invitations, grants and feedback
Invitations, grants and feedback
The invitation code
A launch invitation is a link containing a code. This page reads it, takes it straight out of the address bar so a screenshot or a shared link cannot carry it, keeps a copy in your browser’s local storage under cr_invite_v1 so it survives a detour or a later visit without the link, and passes it to the console when you sign up — you never have to type it. Stored alongside it: the campaign the code belongs to, and when you opened the link. Nothing else, and no identifier for you. The code itself is never sent to any analytics tool; only the campaign it belongs to is.
When the code is redeemed we record which code it was, the account that used it, the ledger row that credited it, and salted one-way hashes of the IP address and user-agent string of the redeeming request. The hashes exist for one reason: a hundred redemptions from one fingerprint is the pattern a launch needs to be able to see. Neither the address nor the user-agent string is stored.
Feedback for the second grant
If you are offered a second grant in exchange for feedback, the form is hosted by Typeform, and Typeform’s own privacy terms apply to what you type into it. It carries a short-lived signed token that identifies your account to us when the answers arrive; that token is never stored. We keep the answers and the submission id in our own database — a question worth asking should not lose its answers when we stop paying for a form tool — together with the grant it earned.
/PP_08Payments
Payments
No payment has been taken on this service yet. Paid top-ups are not enabled on the deployment that is running — every balance on it is a grant, as the Terms §7 says — so nothing described in this section has happened to anyone, and Stripe holds nothing of yours. It is described anyway, because the terms you accept should already say what happens when it is switched on rather than arriving with the first invoice.
When it is switched on, payments go through Stripe and you enter your card on Stripe’s own checkout page: card numbers never reach our servers, and we could not store one if we wanted to. What we would keep is the customer reference Stripe gives us, the identifier of each checkout or charge, the amount, and — if you switch on automatic top-up — the threshold and amount you chose, so the saved card can be charged when your balance runs low. Your email address is passed to Stripe so it can create a customer and send a receipt.
Stripe processes payment data as its own controller for fraud prevention and regulatory purposes. Its privacy policy covers that part; ours covers the reference we store against your workspace.
/PP_09Sub-processors
Sub-processors
These are the third parties that see anything at all. Each row is what they do and where they hold it; a row that says “only if” means the processing does not happen unless you take that step, and a row marked not in use yet is an integration that ships with the product and is switched off on the deployment that is running — nothing of yours reaches it today. We would rather list what is coming and say it is off than quietly add a row on the day a flag flips.
| Who | What they do for us | Where |
|---|---|---|
| Plausible Insights OÜ | Landing-page analyticsCookieless and aggregate. No identifier is stored on your device and none is sent to us. | Germany |
| Microsoft Azure | Hosting for this static landing pageMarketing content only. This page has no account, no session and no prompt on it. | East US, United States |
| PostHog Inc. — EU Cloud | Product analytics for the consoleUS-incorporated, EU-hosted; events reach it from our servers, never from your browser. | Frankfurt, Germany |
| Stripe, Inc. and Stripe Payments Europe, Ltd. | Card payments and receiptsNot in use yetOnly when paid top-ups are enabled, which they are not today — see the Terms, §7. Nothing has been charged and no card has been entered. When they are, card details are entered on Stripe’s own checkout page and never reach our servers. | United States, Ireland |
| Resend, Inc. | Sign-in links and email receiptsNot in use yetOnly when a mailer is configured. The production deployment sends no email at all, so no address of yours is handed to a mail provider. A deployment may be configured with a plain SMTP relay instead, in which case that provider replaces this row. | United States |
| Typeform S.L. | The feedback form behind the second credit grantNot in use yetOnly when the feedback grant is offered, which it is not today — the form is not configured. When it is, only opening the form involves Typeform, and what you type there is also stored in our own database. | Spain |
| GitHub, Inc. and Google LLC | Optional sign-in with GitHub or GoogleNot in use yetOnly when those sign-in buttons are enabled, which they are not on the production deployment. When they are, and only if you choose one, they tell us your email, name and avatar URL; we tell them nothing about your usage. | United States |
We will change this list when the system changes, and the change will be visible in this page’s history.
/PP_10Where the data is, and transfers
Where the data is, and transfers
The console, the API and the database run inside the confidential cluster, which is hosted in the United States. This landing page is static files on a commercial cloud host — Microsoft Azure, East US — and holds nothing about you.
Operational logs are kept for 30 days and then deleted. They hold request metadata only: the sanitiser in §5 strips prompt and completion content before a line is written, so what expires after 30 days was never content in the first place.
So: all three surfaces are hosted in the United States, and Super Protocol Corp. is a US company. If you are in the EU, the EEA or the UK, your data is processed in the United States — we would rather say that than describe a European deployment we do not run. The two exceptions run the other way: Plausible keeps this page’s statistics in Germany, and PostHog’s project is on its EU Cloud in Frankfurt.
Where personal data reaches a US sub-processor — Microsoft Azure for this page today, and Stripe, Resend, GitHub or Google if and when those rows stop being dormant — the transfer rests on the European Commission’s Standard Contractual Clauses in that provider’s data processing agreement, together with its own transfer framework certification where it holds one.
/PP_11How long we keep things
How long we keep things
| What | How long | What for |
|---|---|---|
| Account record — email, name, avatar URL | While the account exists | It is the account. |
| Sign-in credentials — a password hash, or the provider account id and tokens from GitHub/Google | While the account exists | Letting you back in. |
| Sign-in links and email verification tokens | Minutes — single use, and expired the moment they are used | They are the sign-in. None is sent today: the deployment has no mailer configured. |
| Session records — session token, IP address and browser user-agent string | Until the session expires (30 days, refreshed while in use) or you sign out | Keeping you signed in, and letting you see where you are signed in. |
| API keys — a SHA-256 hash and the first 12 characters, never the key | While the key exists; a revoked key keeps its row | Authenticating requests, and keeping past usage attributable after a revocation. |
| Per-request metering — model, tokens in and out, cost, latency, status, which key, and a salted hash of the client IP | For the life of the account | It is the billing record and the Activity screen. It contains no prompt or completion text. |
| Credits ledger — grants, purchases, usage, refunds | Indefinitely, including after an account is deleted, with the account identifiers removed | Accounting. The ledger is append-only: a correction is a new row, never an edit. |
| Invitation redemption — the code, its campaign, and salted hashes of the IP and user-agent | For the life of the campaign record | One grant per account, and reviewing a campaign for abuse. |
| Feedback form answers and the submission id | Until we have no further use for them; deleted on request | They are what the second grant buys, once it is offered. The signed token the form carried is never stored. |
| Attestation evidence archived for your account | The raw bundle for as long as your Preferences say (90 days by default); the digests are kept | So you can show what a deployment published on the day it served you. |
| Plausible statistics for this page | Aggregate counts, for as long as the site runs; the daily visitor hash lives one day | Knowing whether the campaign worked. Nothing in it identifies a visitor. |
| PostHog product events, keyed by an account id | 12 months | Whether an account that took $100 of credits ever sent a token. |
| Operational logs — request metadata only | 30 days, then deleted | Running the service. Prompt and completion content is stripped before a line is written, and they are never used to build a profile of anyone. |
Two rows deserve their reason said out loud. The meter is kept for the life of the account because it is what your invoice is computed from, and it contains no content. The ledger is never deleted at all, even after an account is — with the account identifiers removed — because an accounting record that can be erased is not one.
/PP_12Your rights, and how to use them
Your rights, and how to use them
If the GDPR or a comparable law applies to you, you can ask for access to your data, a copy of it, correction of it, deletion of it, restriction of processing, or object to processing that rests on legitimate interest. One address does all of it: privacy@superprotocol.com. We answer within 30 days, and you can complain to your local data protection authority if our answer is unsatisfactory.
- Access and export. Your account, keys, usage and ledger are all visible in the console today. Ask and we will send the same thing as a file.
- Deletion. There is no self-service “delete my account” button yet — we would rather say so than imply a process that does not exist. Write to us and we delete the account, its personal workspace, its keys and its preferences, and remove the account identifiers from the metering rows and the ledger, which are kept for accounting. The same request deletes your events from PostHog.
- Objecting to analytics. Tell us and we exclude you. Note what we cannot do: Plausible holds no identifier that could be used to look you up, so there is nothing there to delete or export — the honest answer to an access request against it is that it contains no data about any individual.
- Prompts. There is no request to make. We do not have them.
/PP_13How this is protected
How this is protected
- Inference runs in CPU and GPU enclaves with encrypted memory; TLS terminates inside the enclave, not at a proxy in front of it.
- API keys are stored as SHA-256 hashes; passwords, where a deployment offers them, as scrypt hashes.
- IP addresses and user-agent strings that we compare but must not keep are stored as salted one-way hashes, salted with a deployment secret.
- Structured logs pass through a redactor that removes keys, tokens, cookies and secrets, and a sanitiser that removes request and response content.
- The credits ledger is append-only, and every write is idempotent, so a retried payment cannot double-charge.
- The deployment publishes signed attestation evidence, and anyone can check it without asking us.
No system is perfectly secure. If you find a hole, please tell us at security@superprotocol.com before you tell anyone else.
/PP_14Changes to this policy
Changes to this policy
When the system changes, this page changes with it. The date at the top is when the current version took effect, and every revision is a commit in this page’s repository, so a change is reviewable rather than announced. If a change materially affects how we process your data, we will tell account holders by email before it takes effect.