All articles

Privacy2 min read

Anonymized today, Sealed next

Every model on Moth is labelled with what it hides. Anonymized keeps who you are private on every model today, and Sealed, coming next, will keep what you send private as well.

01

Two requests, two kinds of secret

Think of two requests. The first asks a model to tidy a cover letter for a job you haven't told your employer about. The question is ordinary, and the sensitive part is who is asking it.

The second pastes in a draft agreement that nobody outside the room has seen. Here the content itself is the secret, and hiding the sender is not enough.

The Mothpoint handles every request in one of two modes, one for each kind of secret, and every model is labelled with its mode in the catalog, in the API's model list and in the badge at the top of each chat in Moth Chat.

02

Anonymized, live on every model

Anonymized is the mode every model in the catalog runs in today. Your wallet, IP address, device details and key come off at the Mothpoint, and the call goes on under one pooled key, as Identity stops at the Mothpoint walks through.

The frontier models run with their makers or partners, who can read the prompt and the reply under their own policy. They see the request arrive from Moth with no way to tell who sent it, which is exactly what the cover letter needs.

Anonymized hides who is asking, and Sealed will hide what is asked as well.

03

Sealed, coming next

Sealed is for the draft agreement. A few open-weight models will run in attested hardware, and your client will check that hardware's attestation and encrypt the request to it before sending a word. Moth relays the encrypted request without being able to read it, and so does the host.

Fig. 01Who can read what, in each modethe content can be read heresealed, unreadable

Your device

Mothpoint

Model host or attested hardware

Anonymizedlive on every model

readableyour prompt, as you wrote it

wallet, IP address, device

readablepasses through, no copy kept

removed here

readablereadable under its policy

a pooled key

Sealedcoming next

sealedencrypted in your browser

wallet, IP address, device

sealedpassed through unread

removed here

readablereadable inside the hardware only

a pooled key

Both modes take who you are off at the Mothpoint. Sealed also keeps the content unreadable until it reaches attested hardware.
  • The attestation is checked first, and a route that fails the check gets nothing.
  • There is no fallback, so if no route passes, the request fails rather than going to an unsealed model.
  • Billing never reads the content. It uses the usage the hardware reports, and only settings such as max_tokens and stream stay readable, since the hold is sized from them.
Fig. 02A Sealed request, step by stepencrypted to the hardwarechecked first

Your browser

Moth

Attested hardware

01
Fetch and check the attestation
02
Request, encrypted to the hardwarepassed through unread
03
Reply, encrypted, with the evidencepassed through unread
04

A failed check stops here, with no fallback

  • Proof firstYour browser fetches the hardware's attestation and checks it against the measurement we pinned.
  • Then encryptionThe browser encrypts the request to a key only that hardware holds, and we pass it through unread.
  • Then the answerThe reply comes back encrypted the same way, with the evidence attached.
  • Never a fallbackIf the check fails, the request fails rather than going to an unsealed route.
Sealed comes next. The content will be readable only inside the attested hardware, and a failed check means nothing is sent.

04

What neither mode does

  • Neither can hide what a prompt gives away by itself, such as a name or an address written into it.
  • We add no content filter of our own, and in Anonymized mode the host's own policies still apply.
  • Moth keeps no copy of a prompt or a reply in either mode.

Read further