Privacy Controls

TelegramOS privacy controls: the analytics opt-out, session vault, what is encrypted at rest, who can read what, and where data is processed.

The platform gives you a small number of privacy controls. This page lists the ones that exist, what they actually do, and what is stored in plain form.

Privacy toggles

Message analytics

Settings > Privacy > Message analytics. Stored per user as analytics_enabled (default on).

• On (default): Message events from your accounts are processed into workspace analytics and AI insights. See Analytics.
• Off: The analytics API and AI insights refuse to compute or return message-derived analytics for your workspace. The check fails closed: if the preference cannot be read, nothing is shown. Event collection itself is not switched off; already-collected events are not deleted.

Session vault

Accounts > (owned account) > Vault. Re-encrypts the account's Telegram session under a passphrase you hold, so the platform cannot read it while the vault is locked. Automation runs only during an unlock window (default 1 hour, maximum 24 hours). Losing the passphrase means logging the account in again from Telegram. Not available for rented accounts. Details in Security › Vault mode.

Telegram privacy settings per account

Accounts > Edit profile shows the account's real Telegram privacy settings (who can see phone, last seen, profile photo, and so on) read live from Telegram, and lets you change them. These are Telegram's own settings applied through the account's session, not platform settings.

What is not configurable

• Login-code hiding is not a toggle. Conversations with Telegram's system account (peer 777000) are always hidden for rented accounts and always visible for owned accounts.
• Runtime isolation is not a toggle. Every active account always runs in its own worker process.

What is encrypted at rest

There is no KMS-managed key hierarchy and no scheduled key rotation. See Security › Encryption.

Secrets handling and what gets logged

The following never exist in plain form in the database:

• Plaintext passwords (bcrypt only).
• 2FA backup codes, refresh tokens and API keys (hashes only; the API key is shown once at creation).
• Payment card data. The platform does not accept cards. Crypto top-ups are processed by NowPayments and Telegram Stars by Telegram; only the resulting payment status and amount reach the platform.

The following is recorded, so you should know about it:

• Webhook deliveries: the full event payload sent to your endpoint, the HTTP status and the first 400 bytes of your endpoint's response, kept 7 days (delivered) or 30 days (failed).
• Connection audit: per Telegram connection, the proxy host and port, device model, outcome, error text and duration.
• Audit logs: team-management actions with actor, IP address and user agent; session exports; proxy lifecycle actions.
• HTTP access logs: client IP, method, path, status and user agent at the edge and in each service. Request bodies are not written to access logs.
• Message bodies: stored as ordinary rows so the inbox, search and analytics can read them. Operational log lines reference message IDs and counts rather than bodies, but this is convention, not a redaction layer.

Data access controls

Roles come from the team RBAC engine. Owners can override individual permissions per member.

A viewer can read conversations. If a member should not see message bodies, remove inbox:read for that member in Settings > Team.

Session export (the raw Telegram session string) is available only to the owning tenant for owned accounts, is refused in vault mode, and every export is written to the audit log.

Data processing location

The platform runs on a single host in Helsinki, Finland (EU). Postgres, Redis, ClickHouse, MinIO and all backups live on that host. Proxy traffic egresses from the proxy's assigned region, which may differ.

Third parties that process data on the platform's behalf:

Data retention

For deletion requests and what a deletion actually removes, see Policies & Rights.