No account, so no profile
There is nothing to sign up for. Sandhi never asks for an email, a phone number or a password in order to run, and there is no login anywhere in the product. Devices are introduced to each other directly by scanning a QR code, not by looking each other up in a directory we keep, so no server knows which devices are yours — no such list is ever assembled.
Paying is the one exception, and it is set out in full further down: a purchase gives us your email address, because a licence key has to be sent somewhere.
No telemetry, no analytics, no crash reporting
The desktop app writes logs to a file on your own machine and sends them nowhere. Those logs record only metadata — how many steps a task took, which kind of action ran, what sort of error occurred — never the contents of your messages, your screenshots, or your keys. Neither app carries a third-party SDK whose job is to watch you use it.
The link between your devices is end-to-end encrypted
Devices agree on keys with an X25519 Diffie–Hellman handshake that mixes both ephemeral and long-term keys, derives session keys with HKDF-SHA256, and encrypts every frame with ChaCha20-Poly1305. Each device's long-term key is pinned the first time you pair, so an impostor presenting a different key later is rejected rather than silently accepted.
Pairing is gated by a password you set on the desktop. A device that completes the handshake but cannot prove it knows that password is unpaired immediately.
Off your Wi-Fi, the relay is blind
When your devices are not on the same network, traffic is routed through a relay. The relay holds no Sandhi key and can decrypt nothing: the encryption runs end-to-end through it, so every data frame it handles is opaque ciphertext. Payloads are forwarded byte for byte and are never parsed, written to disk, or logged.
The room two devices meet in is derived from a secret only those two devices share, so the relay sees an opaque identifier rather than an identity. Its logging is deliberately minimal: no room ids, no addresses, no payloads. You can also run the relay yourself — it is in the repository, and pointing the app at your own removes us from the path entirely.
You choose the model — and it can be one that never leaves the house
Sandhi has no model of its own and no inference service behind it. Point it at a local model through Ollama and nothing about your task leaves your machines at all. Point it at a cloud provider and the screenshots and on-screen text each step needs go to that provider, under your own API key, on your own account — never through us.
This is the most consequential privacy decision in the product, and it is yours rather than ours.
What the agent sees is not kept
To act on a screen the agent has to look at it. Screenshots and accessibility trees are held in memory for the step that needs them and dropped afterwards. They are not accumulated into a history, not written to disk as a record, and not sent anywhere except to the model provider you chose, when a step requires it. The task history below records that a step happened, never what was on the screen when it did.
The task history is a local log, and only a log
The desktop keeps a record of every task it has run — typed there, sent from a paired device, or fired on a schedule — so you can answer "what did it do on Tuesday, and did it work?" without taking anyone's word for it. It lists what was asked, which device asked, which device carried it out, whether it succeeded, how many steps it took and how long.
It is a file in your own app-data folder on the machine that ran the task. It is not sent anywhere, there is no copy on any server of ours, and you can erase it whenever you like.
What it deliberately does not contain is the part that would matter: no screenshots, no accessibility trees, no page text, no per-step observations. Those are held in memory for the step that needs them and dropped, as described above — a history that quietly kept them would turn that guarantee into a lie. What is kept is the instruction you typed and the result that came back.
The mobile app refuses to type your password
The executor on the mobile device — not the model — refuses any tap, long-press, or typing action while a field Android itself marks as a password field is focused. The model cannot talk its way past this, because the model is not consulted: the check happens after a decision is made and before it is carried out. Credential entry is handed back to you.
Sandhi also steps out of the way of banking and UPI apps. When one comes to the foreground it switches its own accessibility service off, so those apps behave exactly as they would if Sandhi were not installed.
Keys live in the operating system's vault
Secrets are stored in the OS keychain — Windows Credential Manager — rather than in a file beside the app. The keychain wrapper never logs a secret value; it records only whether an operation used the keychain, so a debug log cannot become a key leak.
Buying a licence does identify you — using it does not
This is the one place Sandhi collects something, so it is worth being exact rather than reassuring.
At the checkout. Payment is handled by Paddle, who are the merchant of record. They ask for your email, billing country and postcode, and your card or UPI details, and their terms govern what they do with it. We never see your card. If you are buying for a company you will also be entering company details for the invoice.
What reaches us. Your email address, the plan you bought, and the dates. We need the email to send you the key, and we keep a ledger of issued licences so we can reissue one if you lose it and honour a refund. That ledger is a list of customers — the only record of people we hold anywhere. Your licence key itself contains that email, which is why the app shows "Licensed to …" beside your plan.
What it is not linked to. Nothing about what you actually do with Sandhi. We hold no record of your tasks, your devices, your prompts or your usage, because none of that ever reaches us — so the ledger says that someone bought Pro, and nothing at all about what they did with it.
After the purchase. Activation is entirely offline. Your key is an Ed25519 signature your own machine checks against a public key compiled into the app; it contacts nothing, needs no account, and keeps working if our servers are down or this company no longer exists. The single-use code the app hands to the checkout is only how the key finds its way back to the machine that paid — known to that machine, expired within the hour, and destroyed on collection.
An offline licence can be copied, and we accept that. The alternative is a licence server that has to know who and where you are every time you use the product, rather than once when you buy it.
Even the update check is anonymous
Checking for updates is a plain download of the same signed file everyone gets. The request carries no device id, no install id, no account, no cookie — and deliberately not even your version number, which together with an IP address would be enough to follow one machine over time. The comparison happens on your computer, after the file arrives.
Updates are signed, and a file failing signature verification is refused rather than installed. Nothing installs itself without you saying so.
What this does not protect you from
Being straight about the edges is part of the claim. If you point Sandhi at a cloud model, that provider sees what you send it — read their terms, not ours. Anyone with physical access to an unlocked, paired device can use Sandhi on it, exactly as they could use any other app. And an agent that can operate your apps can make mistakes in them, which is why consequential actions ask first and why autopilot stays off until you turn it on.
Every mechanism above is in the source. If this page and the code ever disagree, the code is the truth and the page is a bug — tell us.