Security & privacy

How Tacendo protects your chats

Tacendo offers models labelled Private TEE, Attested TEE or Incognito. TEE models run on confidential computing hardware with isolated, encrypted memory. NEAR’s Incognito models run at the upstream model provider, which receives your conversation. Their inference does not have the same hardware privacy guarantees.

Every connection between your browser, our server and our inference provider uses HTTPS.
The model selector shows each model’s privacy category. Incognito models are available when NEAR AI is enabled.
Saved chats are encrypted in your browser with a key only you can unlock, so our database can’t read them.
We don’t intentionally log what you write or what the model replies.
You sign in with a Solana wallet. We don’t ask for an email address or name.

Step 1Your browserConversation held in memory
Step 2Tacendo serverChecks sign-in, forwards request
Step 3Inference gatewayRoutes to your selected model
Step 4Selected modelTEE or Incognito, as labelled

Each hop uses HTTPS (TLS). TEE models protect inference in isolated hardware. Incognito models send the conversation to the model provider outside a TEE.

What we don’t claim

We want you to trust us for the right reasons, so here are the limits of what this app does today:

It is not end-to-end encrypted. Our server decrypts each request so it can check your sign-in and forward the message to our inference provider. While it does this, the message exists in the server’s memory in readable form.
Encrypted history doesn’t cover sending. Saved chats are encrypted before they’re stored, but each message you send still reaches our server and our inference provider as described above.
Your unlocked browser is trusted. Chats are decrypted in your browser, so malicious code running on the page or your device could read them while they’re unlocked.
Your browser doesn’t check attestation. Phala requests ask for verified confidential routing. NEAR’s privacy labels come from its catalog metadata. The app doesn’t retrieve or check attestation evidence for either provider, and Incognito inference has no model-level TEE attestation.
We don’t set other companies’ policies. Our inference provider’s data retention and our hosting provider’s logging are covered by their own terms.
TEEs are strong, but they have had flaws. Researchers have found side-channel attacks and firmware bugs in them before. They make it much harder to see your data, not impossible.

Encryption in transit

Your browser connects to Tacendo, which connects to the inference service over TLS. Incognito requests also pass from NEAR to the upstream model provider. TLS is the same encryption behind the padlock in your browser’s address bar.

Browser to Tacendo: your conversation and a short-lived sign-in token go to /api/chat. The server checks the token on every request.
Tacendo to the inference provider: the server forwards the conversation to our inference provider using an API key that stays on the server. Your browser never receives it.
Chat responses include Cache-Control: no-store, which tells browsers and proxies not to keep a copy.

Encryption in use: trusted execution environments

Most encryption protects data while it’s stored or sent. A model still has to read your prompt to answer it, and on an ordinary server, anyone with enough access to the machine could read it too.

A TEE fixes this with hardware. The processor and GPU encrypt the memory the model uses, so the operating system, the hypervisor and the server’s operators can’t read it. The hardware can also produce a signed attestation report that proves what software is running and that it’s on genuine confidential hardware.

Phala’s model list is filtered to TEE chat models. NEAR’s list includes both TEE and Incognito chat models, with privacy labels based on the catalog metadata.
Before sending a request, the server checks that the model you picked is still in that list.

Provider routing

Tacendo uses either Phala or NEAR AI, selected by the server configuration. Phala requests ask for verified routing, so it should only use confidential servers that pass its checks. NEAR offers its own TEE models, attested third-party TEE models, and Incognito models. With Incognito, NEAR uses its own provider account and doesn’t forward your NEAR API key. The upstream provider still receives the conversation and attachments, and executes the model outside a TEE.

If Phala reports that it can’t verify the server for the model you picked, you won’t get a reply. Instead you’ll see this message: “We couldn’t verify the selected model’s confidential server.” You can then retry or choose another model.

Your chat history

By default, your chats are saved only in this browser. You can turn on sync to open new chats on your other devices; synced chats are encrypted in your browser first, and our database only stores ciphertext it can’t read.

On this device: chats are stored in your browser, encrypted with a key your browser creates and keeps next to them. That keeps readable text out of the stored files, but it doesn’t protect against someone with access to your device or browser profile. They stay after you sign out, don’t appear on other devices, and are deleted if you clear this site’s data. Some browsers, like Safari, may delete them after a week without a visit.
Synced: turning on sync creates a passkey for your chats. Your browser asks it for a secret (through the WebAuthn PRF extension) that never leaves your device. It’s separate from your wallet and isn’t used to sign in. Only chats you start after turning on sync, while it’s unlocked, are synced; chats already on this device stay there unless you choose Sync chat from a chat’s menu, which encrypts it the same way and moves it into your synced chats. Unsync chat does the reverse: it saves the chat on this device and deletes the synced copy, so it’s removed from your other devices and our backend. To keep a new chat off your other devices, check Keep this chat on this device only before sending its first message.
For synced chats, your browser creates a random key for your history and a separate key for each chat. Messages and titles are encrypted with AES-256-GCM, and each one is tied to your account, its chat and its position, so it can’t be moved or swapped without failing to decrypt.
Attachments: images and text files you attach are saved with their chat and encrypted the same way as its messages, on this device or synced. Synced attachments are stored as encrypted files; our backend can see their sizes but not their contents. Images are resized and re-encoded in your browser before they’re sent or saved, which removes metadata such as location.
Your synced history key is stored locked with each of your passkeys and, separately, with a recovery key shown once during setup. Signing in with your wallet alone can’t unlock synced chats.
Your passkey provider (such as iCloud Keychain, Google Password Manager or a password manager) syncs it to your other devices. On a device without it, unlock with your recovery key and add a passkey there, or continue with that device’s chats only.
If you lose access to all your passkeys and your recovery key, we can’t recover your synced chats.
Once you unlock, this browser remembers your synced history key so reloading doesn’t ask for your passkey again. It’s kept in your browser’s storage in a form the site can use but can’t read out, much like the key for chats on this device, so anyone with access to this browser profile can open your synced chats until you lock them. Locking or signing out removes it. Decrypted synced chats are kept in memory only.
The model needs context, so each message you send includes the conversation so far, including its attachments. The server passes it to our inference provider, streams back the reply and keeps nothing. The saved copy is separate.

Logging

The app doesn’t intentionally log your prompts, the replies or your sign-in token.

We turn off the AI SDK’s error logging, because error details from the model provider can include parts of your request.
You only see short, general error messages. We never pass on the provider’s raw error text.
Our hosting provider and our inference provider may keep their own records, such as IP addresses and request times, under their own policies.

Your account

You sign in with a Solana wallet you already have, through our authentication service. We don’t create wallets for you or ask for an email address. Your chat passkey only unlocks your chats in your browser; it isn’t used to sign in.

Your account record only holds what we need to confirm it’s you:

Your wallet address and authentication identifier
Whether your account is active
When the record was last updated

Your encrypted chats are linked to your account, and only your account can read or change them. For every message, the server checks that your sign-in token is valid and that your account is active. If either check fails, nothing is sent to our inference provider.

Who you’re trusting

No system can remove trust entirely. What we can do is be clear about who is involved and what each of them can see:

Our inference provider and the hardware vendors: For TEE models, the provider and hardware vendors supply isolation and attestation. For Incognito models, NEAR forwards the conversation to the upstream model provider, which can process its contents under its own policies.
Tacendo (us): Our server sees each message while it forwards it. You are trusting that we run the code this page describes.
Our hosting provider: Runs our server and may record request details such as IP addresses and timing.
Our authentication service: Handles wallet sign-in and sessions. Chat content is not sent to it for authentication.
Our database service: Stores account and billing records, preferences, and encrypted chat history. It can’t read saved messages or chat titles, but can see account ownership, record counts, sizes and when they were saved.

Our Privacy policy lists the providers involved and the information they handle.

Verify it yourself

You don’t have to take our word for some of this. You can check it in your browser:

Open your browser’s developer tools and go to the Network tab. When you chat, you should see requests to /api/chat and connections to our database service. Synced chat titles, messages and attachments are sent to the database service as encrypted data; account and billing metadata remain readable.
Look under Application → Storage. Device-only history and its local encryption key are stored in your browser, with chat content encrypted. While synced chats are unlocked, their history key is stored there too, as a key that can’t be exported. Decrypted synced chats are held in memory.
Lock your chats from the sidebar and confirm the conversation disappears, and stays locked after a reload, until you unlock again.