Skip to content
Privacy & security

Data in, results out, nothing kept

The frontier APIs are a black box you send your data into, where prompts and outputs may be retained, inspected, and used to train future models. Otium is built the other way around. Open models, no retention past delivery, no training, and per-customer encryption is a combination a frontier vendor cannot offer while its model stays proprietary.

Open models on compute we control

No proprietary model vendor sees your data. The model is one we run on infrastructure we operate — not one we rent through someone else’s API black box.

No content retention beyond delivery

Inputs and outputs live in object storage only as long as needed to deliver your result, then expire on a TTL. We keep operational metadata — job ids, token counts, cost — never the prompt or response content, and content is never written to logs.

Never trained on

Your data is never used to train or fine-tune any model. Not retaining data is cheaper than retaining it, so this costs us nothing to promise and nothing to keep.

Cryptographic tenant isolation

Each customer’s data is encrypted under its own key (a tenant KEK in self-hosted Vault, with per-job envelope encryption). If anyone reaches another tenant’s objects, they get ciphertext wrapped under a key they cannot access — isolation survives even an access-control failure.

Data minimization on every worker

A worker receives only its one job’s input and the scoped, short-lived key material to decrypt that single job — never other tenants’ keys, never the rest of your corpus. A compromised worker exposes at most its own in-flight job.

Encrypted end to end

TLS everywhere in transit (mTLS as the target for the worker boundary), object storage and database encrypted at rest, and model artifacts integrity-checked on load.

Platform security

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

Go advisories are gated on reachability — a CVE is blocking if our code can actually call it, so the signal stays real instead of becoming noise people learn to ignore. The JavaScript that ships to your browser is audited separately, and updates are proposed automatically across Go, npm, Docker and our CI actions.

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 closed alpha, 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.

You can read the data path

These claims are checkable. The payload-encryption code — the data path — 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 →

Batch inference that doesn’t keep your data.

Send proprietary catalogs, records, and documents through batch inference without sending them into a black box. Leave your email and we’ll invite you to the alpha.

No credit card, no spam — one email when your invite is ready.

Closed alpha — onboarding is gated while we calibrate. Already invited? Sign in.