Data in, results out, then deleted
When you send data to one of the big AI companies, you can’t see what happens to it: your prompts and results may be kept, read, or used to train future models. Otium works the other way around. We run open models ourselves, delete your data 30 days after your job finishes, train on nothing, and lock each customer’s data with its own key.
No AI company sees your data
We run open models ourselves, on cloud machines we rent and operate. Your data is never sent to another company’s AI service.
Content deleted after 30 days
Your inputs, results and every workflow step’s output are kept 30 days after the job finishes so you can collect them, then deleted. Content is never written to logs.
Never trained on
Your data is never used to train or fine-tune any model. We run open models we did not train, and have no use for your data beyond running your job.
Each customer has its own key
Each customer’s data is encrypted with its own key, kept in our own key vault and never stored next to the data. Anyone who reached another customer’s files would find only encrypted data they cannot unlock.
Each machine sees one job
A machine processing your work receives only that one job and a short-lived key that opens only that job: never another customer’s data, never the rest of yours. A compromised machine could expose at most the job it was running.
Encrypted in transit and at rest
Your data is encrypted on its way to us, while stored, and on its way to the machine that processes it. It is decrypted only on that one machine, only while your job runs.
What stays and what goes: reference data you publish for workflows to reuse (assets) is kept until you purge it, and an account with its own agreed retention window keeps to that instead of 30 days. After deletion we keep only operational metadata (job ids, token counts, cost), never the prompt or response content.
The boring parts, done on every merge
Encryption is the part everyone advertises. Most real incidents start somewhere duller: a stale dependency, a leaked deploy credential, an image nobody scanned. Every control below is enforced automatically in our pipeline, not a policy someone is supposed to remember.
Dependencies checked on every merge
A Go advisory blocks a merge when our code can actually call the vulnerable function, so the signal stays real. The JavaScript that ships to your browser is audited too, and updates are proposed automatically across Go, npm, Docker and CI.
Images scanned before they can deploy
Every container image we build is scanned for known vulnerabilities as part of the pipeline that publishes it. Nothing reaches an environment without going through that step.
No long-lived credentials in the pipeline
Deployments authenticate with short-lived identity tokens exchanged at run time, so there is no standing cloud or database credential stored in CI to steal. Encryption keys live in a self-hosted vault; workloads authenticate to it with their own identity rather than a shared secret.
A pinned, reviewable supply chain
Third-party CI steps are pinned to exact commits rather than moving tags, so an upstream account compromise cannot silently change what runs against our code. Dependency updates arrive as reviewable proposals, not surprises.
A locked-down browser surface
Our web properties ship a strict content-security policy: no inline scripts, no runtime code evaluation, and a short allowlist of origins. Public forms are bot-gated. None of it is interesting, and it stops most of the common attacks.
The same gates run on merge, not just on PRs
Build, unit and integration tests, the race detector, formatting and static analysis all have to pass before code reaches an environment. Running them only on pull requests is how a broken merge commit reaches production.
Otium is in beta, so here is the honest boundary: everything above is what runs today, not a certification. We hold no SOC 2 report, and we will say so plainly until we do. The groundwork is real, though: a control matrix mapped to the Trust Services Criteria, a risk register, and an evidence index, kept up as we build rather than reconstructed the month before an audit. We will pursue the report when a customer needs it, which is the only honest trigger for taking it on. Until then, we would rather show you the controls than a badge.
The model never holds a key
A workflow is a fixed graph, so what a model can reach is a property of the shape, not a policy. A model step’s output is data, checked against the schema the step declared and passed to the steps that read it. A step that calls your system calls one operation at one endpoint you registered in advance, in a request we sign; the sender holds a signature and never the key, and the part of the platform that holds keys never dials a customer URL. An instruction hidden in your data can change that item’s output and nothing else.
A model comes only from the organisation of the lab that trained it, is pinned to the commit it was imported at, and is loaded from our own copy as safetensors only, so a model file can never run code. We do not vet models for backdoors, because nothing can; what we offer against one is the same bound.
Your email address
Signing up keeps your address in our own database, with which page you signed up from, the referral code if a partner or a friend sent you, whether you asked for product updates, and the IP address you signed up from. We use it to send the link that creates your account, and updates only if you ticked the box. The IP address, with the ones you create your account and sign in from, is used only to prevent fraud, such as one person opening several accounts to collect referral credit. For the same reason, when you pay we keep Stripe's fingerprint of the card (an identifier Stripe gives the same card in every account, never the card number) and Stripe's fraud score of the payment.
A referral or promo link (one ending in ?ref= or ?promo=) has its code kept in the page while you browse,
so it goes with your signup if you sign up on this visit. To keep it for a later visit, we
store it in your browser's local storage: a referral code for 90 days, so the partner or
friend who sent you is credited, and a promo code for 30. In the EEA, the UK and Switzerland
(judged from your IP address by our network provider, Cloudflare) we store it only if you
choose Remember when we ask; elsewhere we store it without asking. It never leaves your
browser except with your signup, some browsers clear it sooner, and clearing site data
removes it. If you close the promo banner, the browser also remembers that you closed it, so
it stays closed.
The monthly GPU market report is sent by Brevo, our email provider, which holds that list; we keep no copy of it. You are added only after you click the confirmation link Brevo emails you, and every issue has a one-click unsubscribe.
You can read the data path
These claims are checkable. The payload-encryption code is the data path, and it is open source (the worker agent is next), so “no payload logging, scoped credentials, per-job encryption” is something you can read for yourself. That is why the data path is the part we opened first.
See what’s open →Reporting a security issue
If you find a vulnerability, email [email protected] with what you found and how to reproduce it, and please give us a chance to fix it before you make it public. The same address is in our security.txt.
AI batch work that never trains on your data.
Run your private catalogs, records and documents through AI without handing them to another company. Leave your email and we’ll send you a link to create your account.
Free to try on our demo model. No credit card, no spam: we email you a link to finish.
Otium is in beta and open to everyone. Already have an account? Sign in.