Last updated: September 2026
Privacy claims are cheap to write. This page sorts every one SistineGPT makes into three piles: what you can check yourself with tools that have nothing to do with us, what rests on a contract or on our word, and what is not true yet. The commands are at the bottom. If something here does not match what you see, tell us at support@sistine.ai.
| What we say | Why you do not have to believe us |
|---|---|
| Conversations with a model on your Mac never reach our servers. | Run a packet filter while you chat with the local model: no AI request leaves the Mac at all. Other features still make their own connections, and the privacy policy names each one. Recipe 1. |
| Your screen text, memory notes and attached images go only to a model on your Mac or your network, on every plan and in either mode. | Ask SistineGPT about your screen with the filter running and watch for an AI request that never comes. The rule is enforced in one place in the app, and the request is also given a network policy that refuses any address off your Mac or your local network, so a mistake fails instead of leaking. Recipe 1. |
| A Private cloud turn carries the text of the chat alone (your message, recent messages, the text of a document you attached and your Instructions): no tool runs on it, no memory note rides with it, and no image reaches it. | Pick Private cloud, ask the assistant to search the web, and watch the filter: the only request is the sealed one to ai.sistine.ai, and no search request appears. Attach an image and the reply comes from the model on your Mac instead. Recipe 1. |
| What SistineGPT saves on your Mac is encrypted, and Delete All Local Data destroys the key. | Open the database with sqlite3 -readonly and search it with strings: your words are not in it. After a delete, the key is gone from the Keychain, so any encrypted copy left in a backup stays unreadable. Recipe 3. |
| A Ghost chat is written to no file unless you keep it. | Note the size and modification time of the database, its -wal and -shm sidecars and the memory file, turn Ghost mode on, hold a whole conversation with an attachment, and look again: nothing changed. Turn Ghost mode off and choose Save This Chat, which keeps the chat, and now it did. Recipe 3. |
| Each service knows this install by a different random number, and you can replace them. | Capture the requests: the token our relay sees is not the token search sees. Press Replace Identifiers in Settings and capture again. Nothing SistineGPT sends is derived from your hardware; an install that paid before September 2026 sends the old hardware-derived id once, to retire it, and never again. Recipe 1. |
| The app contacts only the hosts the privacy policy names, and only when the policy says. | A packet filter names every host. Settings → Privacy → Network Ledger names the feature behind each one, which the filter cannot, so run them side by side. Recipe 1. |
| Web searches leave only after you approve the words. | The card shows the query before it goes. Watch the search request appear when you approve and not before. Recipe 1. |
| Updates cannot be replaced with something we did not sign. | Every update carries an EdDSA signature the app checks against a key built into it before installing. |
| In Private cloud mode, on the Private Cloud plan: your message leaves as ciphertext, and before a word goes out your Mac checks that the server is genuine sealed hardware. It does not check every program the server's operator runs. | A traffic capture shows message contents as hex and nothing else. Settings → Privacy → Proof exports the hardware proof, the random number your Mac sent and the measurements it matched, so you can re-run the check with tools that are not ours. Recipes 1 and 2. The app takes this path only while our relay reports that it carries sealed conversations; until it does, a paid plan answers on your Mac and Settings → AI says "Not sealed yet". Whichever state you are in, no message goes to our relay in the clear: there is no plaintext cloud path left in the app. |
| A bad proof sends nothing. | Block ai.sistine.ai in the filter while the hardware proof is fetched, or let mitmproxy change one byte of the proof, and send a Private cloud message: no chat request leaves, Private cloud switches itself off with a notice, and the reply comes from your Mac. Recipe 1. |
Nothing below is checkable from your Mac. They are here because pretending otherwise is how a privacy claim becomes a lie.
| What we say | What it actually rests on |
|---|---|
| Our relay does not store what you send or what comes back. | Our word, and code you cannot see running. A capture proves what left your Mac, never what a server did with it afterwards. On the sealed path the relay holds ciphertext it has no key to open, which is a fact about the key, not about our conduct. |
| Request logging is off on the servers that carry your requests. | Our configuration and our word. You can see that a request was made; you cannot see whether it was written down. |
| We do not train AI models on your content. | Our word. A sealed turn reaches us as ciphertext, so there is nothing of yours on our side to train on. |
| A Private cloud turn is encrypted to a key held on the sealed server your Mac checked, and on the rest of that operator's fleet. | Your Mac encrypts to a key tied to hardware it checked, which is the part you can re-check. That key is the operator's APPLICATION key, the same on every machine in its fleet, and the fleet hands each request to whichever machine is free, so the machine that opens your message is often not the one whose proof your Mac checked. What your Mac verifies is that a machine with settings on the list holds the key. What it checks is the hardware and the base system image the server started from. It does not check every program the server's operator runs. Keeping that key on the server is up to the operator's programs, which your Mac does not check, and so is what happens to the plaintext while the reply is written: both rest on the operator, not on a check of ours, and a capture cannot show either. What Venice keeps of the metadata around it (our account, the time, the model, the token counts) is not something Sistine checks; we do not repeat Venice's own statements here. |
| Search queries you approve are handled by Brave under its API terms, which describe a 90-day query log. | Brave's published terms. We do not store queries; what Brave does with one is Brave's policy, not ours. |
| The Network Ledger and the Proof panel are complete. | Our word. They are the app reporting on itself: code that skipped them would be missing from them. That is exactly why every recipe below uses a tool that is not SistineGPT. |
The blunt version takes five minutes. Install LuLu (free) or Little Snitch and let it alert on outgoing connections. Open SistineGPT, then use one feature at a time: send a chat message on the local model, ask about your screen, approve a web search. Compare what the filter shows with Settings → Privacy → Network Ledger, which names the feature behind each connection. Every host the filter shows for SistineGPT should appear there, for the feature you used, with one exception the ledger cannot see: updates.sistine.ai, which the updater contacts on its own schedule, roughly every six hours. Nothing else should appear at all. In Terminal, nettop -p Sistine -J bytes_in,bytes_out (the program file is still named Sistine, which is what these tools match on) lists the same connections live.
To read the requests themselves, install mitmproxy (free), trust its certificate for your user, and run mitmproxy --mode local:Sistine, which captures only this app and asks for your admin password once to install its redirector. Now the bodies are visible: a search request carries the words you approved and nothing else, an AI request on the local model does not exist, and a sealed request to ai.sistine.ai carries hex where the message would be.
First, the limit in plain words: this proof covers the server's hardware and the base system image it started from, and it does not cover every program the server's operator runs. The rest of this recipe uses the precise terms.
Send a message in Private cloud mode, then open Settings → Privacy → Proof, press Export, and open the JSON. Each Private cloud turn carries intelTdxQuoteHex, the Intel TDX quote your Mac verified, and clientNonceHex, the 32 random bytes it generated seconds earlier. Decode the quote and confirm that the last 32 bytes of its REPORTDATA field are that nonce, which is what makes the proof about your session rather than a recording, and that the first 20 are signingAddressHex, which is what binds the encryption key to the hardware's statement. Then run the quote through dstack-verifier or Phala's Trust Center to check its signature chain up to Intel's root, and compare mrtdHex, the base system image, with the measurement published for the stack named in the file. The quote's MRCONFIGID field is the byte 01, the SHA-256 of the configuration text of the operator's deploy manager, then zeros; the export carries that hash as composeHashHex. The operator's text names the machine it runs on, so the hash is different on every machine, and the app does not keep a list of hashes. It takes the configuration text the operator publishes beside the quote (info.tcb_info.app_compose in the same response), requires its SHA-256 to be the one inside MRCONFIGID, and requires the text to equal, byte for byte, a configuration on the list the app accepts, with only the machine's name allowed to differ: the value of INSTANCE_LABEL, lowercase letters, digits and hyphens, 32 at most. A changed image, command, port, volume or variable, an added service, a reordered or re-encoded text is a different text, and the app answers on your Mac instead. It also recomputes RTMR3 (rtmr3Hex) from the boot events dstack records: the application id, that configuration hash, the machine's instance id, the key service, the OS image hash, and nothing after boot; it has to equal the quote's. That configuration is the deploy manager, not the model server that manager starts afterward, and the app does not verify that later step. While the capture from Recipe 1 is running, the message contents in the same request are hex: no prompt, no notes, no tool names.
Where "the list the app accepts" comes from. Some entries are built into the app. The rest are in a list Sistine signs and publishes at https://ai.sistine.ai/v1/measurements, with its signature at /v1/measurements.sig, so that a new server release does not have to wait for an app update. You can fetch both files yourself: the list is JSON, and the signature is Ed25519 over its exact bytes. Your Mac checks that signature against a public key built into the app before it reads a word of the list, and it fetches the list only in Private cloud mode on a paid plan, at most every six hours, plus once right after it refuses a server it does not know. It refuses a list whose version is lower than one it has already accepted, a list past its notAfter date, and a list that carries any field this version of the app does not know; a refused list changes nothing and the last good one stays. A list can add exact entries of the kind described above and can withdraw entries, including built-in ones. It cannot change the rule: the machine's name is still the only part of a configuration text allowed to differ, and proof from every graphics chip is still required. When a list expires, what it added stops counting and what it withdrew stays withdrawn. The export names the list that was in force for each Private cloud turn as acceptedServersList, and the Proof panel shows the same line. The relay that serves the list does not hold the signing key, so it can withhold the list and cannot write one. The limit, plainly: the list is our word about which servers to accept. Whoever holds our signing key could add an entry, and that server would still have to pass every hardware check above.
The database is at ~/Library/Application Support/Sistine/Sistine.store. Run sqlite3 -readonly on it and read the message rows: they are ciphertext. strings over the file, its -wal and -shm sidecars finds no message text. The memory file (memory.md) and your Instructions (instructions.txt) are in ~/Library/Application Support/ai.sistine.macos/, sealed with the same key, which lives in your Keychain and never leaves the Mac. For Ghost mode, run ls -l on both folders before and after a whole conversation with the ghost button on: the sizes and modification times do not change, because nothing was written. Run Settings → Privacy → Delete All Local Data, then look again: the files are gone and the key is gone from the Keychain.
Sistine is a small company asking you to type confidential work into its app. "Trust us" is not an answer, and neither is a claim no one can test. The rule we hold ourselves to is that every privacy sentence on this site maps to a row above: proven, promised, or not yet true. When one of them changes, this page changes with it.