For Personal
For BusinessFour of our claims, running in this tab.
Everywhere else on this site we tell you what we can and cannot see. Four of those claims are mechanisms, and a mechanism can be run instead of believed.
These four run in your browser, on what you type, using the same rules and formats Archie uses on your computer. Two of them print a command you can paste into your own terminal to get the same answer without us.
The record says when a line in it has been changed.
Archie writes down the things that decide what your agent can reach: a key saved, a service connected or disconnected, someone allowed to message an agent or stopped from doing so. It is not a transcript, and it stays on your computer. Each line carries a fingerprint taken over the line before it, so the lines hang together in a chain.
A fingerprint here is a SHA-256 hash: a number worked out from the exact text of the line. Change one character and the number changes completely, and there is no way to work backwards from the number to a line that would produce it. The five below are real, and so is every one that appears while you type.
Nothing has been changed. Five lines, chain checked, and the last fingerprint is the one this computer left off on.
- A key was saved on this computer.
- A Google account was connected.
- Someone was approved to message an agent.
- An outside service was disconnected: Todoist.
- Someone’s access to an agent was taken away.
Where this computer left off, kept in the keychain: 6a5f…f1f2 Last fingerprint in the record: 6a5f…f1f2
Change any value above and the fingerprint on that line stops matching the one stored with it, which is what Archie reports when it opens. Then work the switch: rewriting every fingerprint underneath makes the record hang together again.
The record still does not match where this computer left off, because that last fingerprint is written into the keychain rather than into the record. Both verdicts are worked out from the real numbers, and the switch decides neither.
The exact line hashed for line 3
{"action":"access.approved","actor":"user","id":"aud_63b8f5029ce7481ab0d2947e15c8a3df","metadata_json":{"display":"Dana","sender_id":"tg_48213907"},"prev_hash":"dad7781de8adfc3c996bee263b53337253b0c776ac525ebdf77aa6b094f37f6c","subject_id":"agent_7a2f5c18d9b34e07a1c6be82d4930f56","subject_type":"agent","ts":1757934118000}
Run this anywhere and get the same answer
printf '%s' '{"action":"access.approved","actor":"user","id":"aud_63b8f5029ce7481ab0d2947e15c8a3df","metadata_json":{"display":"Dana","sender_id":"tg_48213907"},"prev_hash":"dad7781de8adfc3c996bee263b53337253b0c776ac525ebdf77aa6b094f37f6c","subject_id":"agent_7a2f5c18d9b34e07a1c6be82d4930f56","subject_type":"agent","ts":1757934118000}' | shasum -a 256
64b31a1a73f882ece6c5ff886cf3487403b55723b58f680ccb396075b2ba1f3b
That command is the whole argument for this section. Paste it into Terminal on a Mac, or into any Linux shell with sha256sum in place of shasum -a 256, and your computer prints the number this page prints. We have no way to reach into that, which is what makes it worth more than our saying so.
The rule being followed is in crates/archie-domain/src/audit.rs: the fields sorted by name, no spaces, and the previous line’s fingerprint carried inside the next one.
Two things this does not do. It shows tampering, and it cannot stop somebody destroying the record: whoever deletes the whole record and the keychain note together leaves nothing to check. Nothing to check is different from nothing having happened.
It is also evidence for you about your own computer, and we cannot vouch for it, because we never see it. If you ever want us to prove what your agent did, we cannot, for the same reason as everywhere else: we do not have it.
The mailbox for your phone is sealed before we hold it.
Turn on phone access and your computer starts leaving messages for your phone in a mailbox on our servers. Each one is sealed with a key your computer makes and gives to your phone by scanning a code. The key never passes through us, so what we hold is a pile of ciphertext with no way to open it. It is off unless you turn it on, per computer.
What our servers hold
The sealed message, as it sits in the mailbox. c is the message, sealed. n is a number used once, made fresh for this message and never reused. Both are written in base64, which is how a run of raw bytes gets written down as letters.
{
"v": 1,
"n": "NPoK22FejvyxV/gB",
"c": "Xj6K8l89vl0XHPUBJ0qIKM0dUyqaYcJzNGMZgr1/2qGwCUjJSKD42OXPq1FIzjXJviFxyyIHEFqOnpBwnQPf5Osf39yCzjOUMKsTse30jdrBL8L0omM="
}
What we can see without a key
Three fields stay in the clear, because a rule and a query need them: when it was written, which app version wrote it, and whether it has been picked up.
{
"status": "pending",
"updated_at": "2026-09-16T14:02:41.000Z",
"app_version": "0.3.0",
"payload": { "v": 1, "n": "NPoK22…", "c": "Xj6K8l89vl…" }
}
Nothing has been sent anywhere: the sealing happens in this tab.
The key for this demonstration was made in your browser a moment ago and starts waiting for your browser. The two functions doing the work are in js/proof.js. The sealing is AES-256-GCM, which is built into your browser and into the app, with a fresh number used once for every message.
The same pair exists in Rust in crates/archie-core/src/phone.rs and in the Archie Mobile app. A test in each opens a message sealed by this same browser code, which holds both to the format this page uses.
Say what this leaves open. We hold the mailbox, and holding a sealed row means we can see that a phone is managing a computer and roughly when. That is why the three clear fields are on screen above rather than under a heading further down.
The seal protects the message, and it cannot protect the phone: whoever is holding the phone is holding the key, and that is what unpairing and rotating the key are for. And your computer is one end of this, so anyone sitting at it, past its password, has everything, as they always did.
This page asked for these, and nothing else.
Below is your own browser’s record of every request this page made while it loaded, read out of the browser rather than out of a list we keep. Open your Network tab and reload: it shows the same thing.
Reading your browser’s record of this page load.
otianai.comThis site: the page, its stylesheet, its drawings, this script.the page itselffonts.googleapis.comGoogle Fonts: the stylesheet naming the typeface.1 requestfonts.gstatic.comGoogle Fonts: the font files themselves.the font fileswww.gstatic.comFirebase’s sign-in code, which the account menu in the top bar runs.the sign-in code
The entries on that list that are not ours are Google’s, and they see your address the way any host sees the address of whoever asks it for a file. One serves the typeface. The others are sign-in: the code the account menu in the top bar runs, and, if you are signed in, the check on your plan.
This site is served by GitHub Pages, so GitHub sees the request for the page itself for the same reason. What is not in that list, anywhere on this site, is an analytics script, a tag manager, a session recorder or an ad pixel. We have never had one.
What this page is allowed to ask for
The list above is what happened once. This is the rule underneath it: a content security policy, written into the page and enforced by your browser rather than by us. The line to read is connect-src, because it is every place this page is allowed to send anything at all.
default-src'self'connect-src'self' https://*.googleapis.com https://*.firebasestorage.app https://archie-4f35.onrender.com https://formspree.io
Those four are sign-in and your plan check, add-on pictures, the billing service that answers whether you have a current plan, and the form handler that carries a message from the contact page. A script that tried to send anything anywhere else would be stopped by your browser before it left. The policy is written into every page on this site by scripts/gen-csp.py rather than by hand.
What this proves and what it does not. This is the website, and the app is a separate thing: a page can only show you what a page does. What Archie does on your computer is a separate question, and the honest way to settle it is the ten-minute check at the bottom of this page.
The pairing key sits in the part of a link a browser keeps.
Pairing a phone hands it the key by QR code. The key rides in the part of the address after the #, which browsers do not send to the server. That is the whole reason the key can travel in a link at all, and it is held in place by a test in the Archie repo rather than by anyone remembering.
The pairing link, with a real key
32 random bytes, the same length as a real pairing key, made fresh by your browser when this page loaded: bbYKukrGbq-uRt4tHb3Gg8FprAIAa_o7zrKzHXAIlKQ
https://otianai.com/app/#a1.bbYKukrGbq-uRt4tHb3Gg8FprAIAa_o7zrKzHXAIlKQ.<one-time ticket>
What our server is asked for
The request line and the host. There is nowhere in it for the part after the # to go.
GET /app/ HTTP/1.1 Host: otianai.com
Your browser’s own record of the request it made: press the button above
Press the button and compare what comes back with the key above.
This one is the weakest of the four, so here is where it stops. It shows what your browser recorded, and a browser’s own record is not quite the same question as what went down the wire. The Network tab in your browser settles that properly, and a network monitor settles it for the desktop app as well.
What we can point at on our side is a test in the Archie code, the_pairing_key_rides_in_the_fragment_never_the_query. It fails the build if the key is ever moved into the part of a link that does get sent.
Four checks are not an audit.
Those four show the mechanisms: real hashing, real sealing, and your browser’s own record of its own requests. What none of it shows is how Archie behaves on your computer, which is the bigger question.
The way to settle that one is a network monitor and about ten minutes: install one, use Archie properly, and compare what it shows with the list of hostnames we publish. Then, on an AI account of your own, block us at the firewall and watch your agent carry on thinking. It is the same shape as everything here, moved to the only place the answer can be found.
And the standing gap, which we have written down elsewhere and will not leave out of a page called proof: nobody outside this company has audited any of it.
The real answer to “why should I believe you” is an open-source client, so that none of this rests on our word. We are not there yet, and we are not going to describe a plan as though it were a fact.
If one of the four above fails in your browser, that is worth telling us. Every one computes its verdict from the real result, so a red line here means either a browser we have not seen behaving differently or a mistake of ours, and we want to know which.