Privacy Policy
Draft, pending legal review. This is a good-faith draft written to reflect Umbra's actual alpha data flows; it has not yet been reviewed by counsel. Questions? Contact us.
Umbra's whole reason to exist is privacy. Your prompts and the model's responses are never logged, never written to disk, and never stored (not by us, and not by the machine owner running the model). This policy explains that guarantee and the limited account data we do keep to run the service.
Experimental alpha with real payments. Developers can buy prepaid inference credit through Stripe, and those card charges are real. Provider onboarding and cash-out are enabled through Stripe Connect for payout-ready Hong Kong connected accounts. Current availability is shown in the provider wallet; providers elsewhere cannot receive a payout through the current Stripe account. Promotional and purchased API credit cannot be withdrawn.
This is a draft, not legal advice. This document is a good-faith draft prepared for the operator and their counsel to review. It is not legal advice and does not create any attorney-client relationship. Bracketed placeholders are to be completed by counsel before any release.
1. Your prompts and outputs are never retained
When you send a request, it travels encrypted to a provider machine, is decrypted in memory only, used to generate a response, and then zeroized. The content is never persisted to a disk, a log, a database, or an analytics pipeline at any point.
- Our coordinator does not store prompt or response content.
- The design assumes the person who owns the provider machine is adversarial and is built to stop them reading your prompts through hardware attestation rather than a promise. See section 5: Apple hardware attestation and APNs running-code identity are live for admitted providers. Signed per-response receipts are still rolling out during alpha, so treat missing evidence as unavailable privacy proof.
- Because we never keep your prompts or outputs, we cannot produce, sell, share, or hand them over. There is nothing to produce.
2. What we do collect
To operate accounts, metering, and credit, we keep a minimal record:
- Account: your email address (and display name, if you provide one). WorkOS is our authentication provider. Google, GitHub, and hosted AuthKit credentials are processed by WorkOS. If you use the email and password form on Umbra, your password passes transiently through an Umbra same-origin Cloudflare Function over TLS and is immediately forwarded to WorkOS for verification. Umbra does not log, store, or put the password into analytics.
- API keys: we show a key's secret once at creation and store only a one-way hash of it.
- Usage metering: content-free counts only: the number of requests, input/output token counts, the model used, and the computed cost. No prompt or response text.
- Provider device metadata: if you run a provider machine, we record device facts needed to route and attest: the machine name you choose, the chip (for example the Apple Silicon model), and unified-memory size. This describes the hardware, not the work it does.
- Wallet and ledger: a balance and an append-only ledger of credits and debits (amounts, model, token counts, Stripe transaction references; again, no prompt or response content). Purchased credit and settled provider payouts represent real money; promotional credit does not and cannot be withdrawn.
- Payment and payout data: Stripe processes card details, identity-verification information, tax details, and bank-account details. Umbra stores Stripe customer or connected-account identifiers and payment status, but does not receive full card or bank-account numbers.
- Model hosting requests: if you ask us to connect a public Hugging Face model with the provider network, we keep the name and email you submit, your relationship to the model, its public repository, intended use and audience, current hosting constraint, expected demand, and our review notes. Providers can see only an operator-approved public summary, model repository, use category, access goal, and priority signal; they do not receive your name, email, or internal review notes through the opportunity feed.
- Operational metadata: request metadata such as IP address and timestamps may be processed transiently for rate-limiting and abuse prevention, and by our infrastructure providers. We do not use it to build advertising or behavioral profiles.
3. Cookies and local storage
- An Umbra-issued session token stored in a Secure, HttpOnly, same-site cookie so browser JavaScript cannot read it.
- Short-lived, Secure, HttpOnly cookies used to protect OAuth state and sealed email-verification challenges. Pending WorkOS challenge tokens are never placed in browser-readable storage.
- Interface preferences (your light/dark theme; whether you dismissed the alpha notice).
- When product analytics is enabled, PostHog's first-party anonymous id and coarse acquisition attribution are stored in local storage as described below. Umbra session credentials are not stored there.
We use no advertising and no third-party tracking cookies.
For product analytics we use PostHog in a privacy-safe configuration: first-party localStorage only (no tracking cookies), no automatic capture of form fields, and privacy-masked session replay on public marketing and documentation pages. Replay masks all text and inputs and does not capture request headers, bodies, or console logs. We do not record sign-in, signup, password reset, verification, unsubscribe, wallet, playground, or authenticated console pages. Events are limited to page views, coarse attribution (UTMs / referrer domain), and content-free product milestones such as signup, API-key creation, and first successful inference. We identify accounts with an opaque account id only — never email — and we never send prompts, model outputs, API secrets, or raw IP addresses to PostHog. Analytics does not initialize when the browser sends Global Privacy Control or Do Not Track. For anonymous visitors, PostHog may create a person profile containing only a readable traffic label, traffic classification, acquisition source, landing path, broad device/browser/OS family, environment, and sign-in state. These profiles follow the PostHog project's configured retention and deletion rules.
4. Service providers
We rely on a small set of processors, each for a specific function:
- WorkOS: authentication and sign-in.
- Cloudflare: website hosting, content delivery, and the outbound network tunnel to our backend.
- Google Cloud Platform: backend compute in a confidential virtual machine in the United States.
- Supabase: managed PostgreSQL storage for account, wallet, API-key, and payout-account records in Canada.
- Stripe: developer card payments, payment reconciliation, provider identity verification, connected accounts, and eligible Hong Kong provider payouts.
- PostHog: product analytics and privacy-masked public-page session replay, as described above. Hosted in the United States (
us.posthog.com). - Hugging Face: providers download public, open-weight model files using their own Hugging Face credentials; this does not involve your data.
5. Confidential computing and attestation
Our coordinator runs inside an AMD SEV-SNP confidential VM, and provider hardware is designed to be verified through Apple platform attestation. These are the technical mechanisms that keep your prompts private in transit and on the provider machine. You can inspect the live attestation from the console.
Accuracy note: production routing requires providers that pass Apple hardware attestation and an app-targeted running-code identity challenge. Attestation verifies the provider software and machine state; it does not warrant a model's accuracy or output.
6. Where your data is processed
Requests are processed in the United States (Google Cloud, us-central1) and via Cloudflare's global edge network. Account, wallet, API-key, and payout-account records are stored in managed PostgreSQL infrastructure in Canada. Creator model-hosting requests are stored in Cloudflare D1. Stripe processes payment, identity, tax, and bank data in the locations described by Stripe's own privacy terms. If you use Umbra from another country, your data may be transferred internationally.
7. Retention
- Prompts and outputs: not retained, ever.
- Account, wallet, and key data: retained while your account is active.
- Model hosting requests: retained while we review, prioritize, fulfill, and follow up on the request. You may ask us to delete your request and contact details.
- Umbra is in an experimental alpha; data may occasionally be reset during this period, though we aim to preserve account data.
8. Your choices and rights
You can stop using Umbra at any time and request deletion of your account data by contacting us (self-service account deletion is not yet available during the alpha). Depending on where you live, you may have rights to access, correct, export, or delete your personal data; contact us to exercise them.
9. Children
Umbra is not directed to, and may not be used by, anyone under 18. We do not knowingly collect data from children.
10. Security
We hash credentials and API keys, encrypt data in transit, and run the backend in a confidential VM. No system is perfectly secure, and Umbra is an early-stage alpha service, so please keep that in mind.
11. Changes
We may update this policy as the service evolves; the "Last updated" date above reflects the latest version. Material changes will be surfaced in the product.
12. Contact
Questions about privacy? Reach us at [email protected].