Useful intelligence.
Clear boundaries.
Our AI reads the content it processes. We show it as a reader, explain what it can access, and give you controls that change that access.
Encrypted in transit
Messages are sealed on your device, X25519 key agreement, AES-256-GCM, and an Ed25519 signature so the recipient can prove who sent it. Calls ride WebRTC with DTLS-SRTP: media is encrypted between the devices, and our relays forward it without being able to decode it. Telbox never sees plaintext in transit.
We name our own AI as a reader
Open any chat's Trust Center and the AI processor is listed there by name, next to the people, whenever AI is on for that chat. It is a list of who can read the conversation, and when AI is on, ours is on the list. You are never asked to take that on faith.
Either side can switch it off
Off for one conversation, either member can set it, and it binds the thread for both of you. Or off everywhere, for everything you send from then on. AI is on from account creation, we say so on the billboard rather than in a policy page.
The model
One architecture, two honest modes
Transport is always end-to-end encrypted. The only variable is whether our AI is one of the readers, and that is the part you control, per conversation or everywhere.
AI off, pure end-to-end
No key is sealed to our AI processor, so there is no wrapped key on our side and nothing for a worker to open. Two bounds we will state rather than let you discover: it applies to what you send from then on, messages sent while AI was on keep the keys they were sealed with, and Clear AI memory is how you deal with what it produced, and calls carry their own separate switch.
AI on, decrypted to work, contracted not to train
To transcribe a note or answer a question, our worker decrypts your content inside an isolated process and hands it to an AI provider we contract with, under terms that bar training on it. The same pipeline on Free as on Business, tiers buy usage, never privacy.
The switch
Made of encryption, not a promise
An off switch is only worth what enforces it. Ours changes who the message is encrypted to, a message with no key sealed to the AI processor is a message our servers hold and cannot open.
Off for one conversation
Either member can set it, and it binds the thread for both of you. Your app stops sealing a key to the AI processor, and if a client still names the processor as a recipient, the server refuses the message outright rather than storing something it could open.
Off everywhere
From then on the server drops the AI processor from the recipient list on everything you send, so no wrapped key is written for it. Nothing you send afterwards carries a key it can open.
Clear AI memory
The derived layer, transcripts, summaries, and the facts the AI inferred about you, is a real delete in a single transaction, and the app reports the count of what went. You can read what it inferred, and correct it, before you wipe it.
Calls carry their own switch
Post-call AI is a separate decision from the chat switch. Before you answer, the app can show exactly what would be captured, and one tap skips AI for that call. Mid-call on a one-to-one you can stop it, and what was already uploaded is pulled out of processing, nothing further is transcribed or summarised from it.
Where it stops
The limits, on our own page
Every one of these would surface eventually, in a review, a teardown, or a support thread. We'd rather you read them here, from us.
It's forward-looking, not retroactive
From the moment you flip it, nothing you send carries a key the AI can open. Messages you sent while it was on keep theirs, and the processor's own private key stays in our database either way. The switch is not a time machine, Clear AI memory is how you deal with what it already produced.
The other person's AI governs their side
Your account-wide switch governs what you send. If the person you're talking to has AI on, their side of the conversation is still processed. The lever that reaches both of you is the per-conversation switch, either of you can set it. In a direct chat we show a chip when they've turned AI off; no chip means we don't know, not that they're on.
There's no access log, yet
The Trust Center shows you who can read a conversation right now, not a history of when the AI did. That's the obvious next question once we list our own AI as a reader, and it's the top thing this position obliges us to build. We won't imply it exists before it does.
AI is on from the start
There's no screen that asks you first, so we won't call it opt-in or claim privacy by default. What you get instead is control that actually reaches: off per conversation with either side able to set it, off account-wide, and one tap to wipe what it remembers.
Built for the quantum era
Hybrid post-quantum encryption, rolling out
We've built hybrid post-quantum encryption into Telbox's core. As your devices update to support it, conversations upgrade to post-quantum automatically, no setting to flip. It is a transport-layer property: it protects data in flight and the ciphertext at rest, and it is not a substitute for the switch above.
Hybrid, not either-or
Each sealed message combines classic X25519 with ML-KEM-768, the NIST post-quantum standard (FIPS 203). An attacker has to break both, today's elliptic-curve math and the lattice cryptography a quantum computer would target.
Beats "harvest now, decrypt later"
Adversaries record encrypted traffic today, betting they'll crack it once quantum hardware arrives. Hybrid post-quantum is rolling out so a message captured now stays sealed against that future machine.
Upgrades itself
The upgrade is capability-negotiated: a conversation moves to post-quantum once both devices support it, automatically. Devices not yet updated keep the still-strong classical encryption until they are.
Post-quantum signatures
Verified-institution signatures are rolling out ML-DSA-44 (FIPS 204) alongside Ed25519, to stay resistant to tomorrow's quantum hardware.
Verified participants · preview
You can prove who's an agent
In the agents preview, each agent gets its own Ed25519 identity. Its messages are signed and verified on your device, so a "from Agent X" badge is a cryptographic proof, not a label. Revoke an agent and every message it ever sent loses its badge, retroactively.
- Per-agent signing keys, KMS-wrapped, never plaintext
- On-device verification with a tap-to-verify badge
- Retroactive revocation distinguishes compromise from rotation
Tapping the badge re-checks the signature against the agent's published identity key, right on your phone. No server in the trust path.
Defense in depth
Engineered to be boring under attack
SSRF-guarded egress
Every outbound fetch (webhooks, link previews, MCP) is DNS-pinned and blocks metadata, RFC1918, and loopback ranges.
Scoped API keys
Partner keys carry an explicit scope set. Deny-by-default: every authenticated route is consciously classified, so nothing leaks by omission.
Signed provenance
Institutional messages use canonical CBOR + Ed25519 with multi-witness audit anchoring. Tamper-evident by construction.
Prompt-injection fences
In the agents preview, anything an agent reads from a message is treated as untrusted input, and anything that leaves Telbox waits for a human tap instead of firing on its own.
Least-privilege decryption
Our AI is only permitted to decrypt the content types it actually processes. Your location is never decrypted server-side, and a test fails the build if that ever changes. Notification previews are decrypted on your phone, not on our servers.
Institutional deployment
In pilot: institutions host their own data plane and hold the signing keys in their KMS. Details →
Want the mechanics, not the marketing? How Telbox handles your data walks through the encryption, the server-side AI decryption, and the no-training terms in engineering detail, the inspectable companion to our Privacy Policy.
Read the legal source of truth: