← Blog

Telegram bots aren't end-to-end encrypted. Your agent's chats aren't either.

“Telegram is encrypted” is true and also, for bots, almost entirely beside the point. This is a common enough misunderstanding that it’s worth walking through the actual architecture once, plainly, with sources — because if your AI agent talks to you through a Telegram bot, this is the exact path your messages travel.

If you’re here because you want your agent’s messages actually end-to-end encrypted, the short version is at Quickstart. The rest of this page is the “why.”

How the Bot API actually works

Telegram has two different transports, and they are not interchangeable:

  1. Secret Chats — genuinely end-to-end encrypted, device-to-device, using Telegram’s own MTProto encryption scheme. This is the mode most people mean when they say “Telegram is encrypted.”
  2. The Bot API — a plain HTTPS API. A bot’s messages, in regular chats or groups, are transported and stored on Telegram’s servers, not end-to-end encrypted device-to-device.

Telegram’s own Bot FAQ is direct about this: bots cannot participate in Secret Chats using the current API. That’s not a bug or an oversight — it’s a structural consequence of how bots work. A Secret Chat’s keys live only on the two participating devices; a bot has no “device,” it’s a server process reacting to webhooks or long-polling Telegram’s servers for updates. There is nowhere on a bot’s side for a device-bound decryption key to live.

So when your agent sends you a message through a Telegram bot, the actual path is: your agent → the bot’s backend process → Telegram’s Bot API servers (plaintext at this hop) → your Telegram client. The message content is visible in plaintext to whoever operates that bot’s backend — which, if you built the bot yourself or you’re running a personal-agent framework’s Telegram channel, means it’s visible to a process running on your own machine or server. That’s not necessarily alarming for you personally — but it means “end-to-end encrypted” is not an accurate description of what’s happening, and it means anyone else with access to that backend (a shared server, a compromised host, a cloud provider’s own visibility) can read it too.

The token problem

Bots authenticate to the Bot API with a single long-lived token — a string handed out once, at creation, by BotFather. That token is the bot, as far as Telegram’s servers are concerned: whoever holds it can send messages as the bot, read its updates, and reconfigure its webhook. There’s no per-device pairing, no additional factor, no way to scope it down. If a bot token leaks — checked into a public repo, logged somewhere it shouldn’t be, exfiltrated from a compromised machine — that’s not a partial compromise. It’s full takeover of the bot’s identity until the token is revoked.

Two paths, side by side

Telegram bot path versus an end-to-end encrypted path Top row: agent to bot backend to Telegram Bot API servers in plaintext, then to the human's Telegram app — plaintext is visible at the bot backend and at Telegram's servers. Bottom row: agent encrypts locally, sends ciphertext through a relay that only ever sees ciphertext, decrypted only on the human's phone.

TELEGRAM BOT PATH

Your agent

plaintext

Bot backend (reads everything — token = full control)

plaintext

Telegram Bot API servers (not a Secret Chat)

plaintext

You, in Telegram

END-TO-END ENCRYPTED PATH (CHIME)

Your agent

encrypted on-device

Chime relay (ciphertext only — self-hostable)

still ciphertext

Your phone (decrypts only here)

read on device

You, in Chime

Red hops: plaintext, readable at that hop. Green hops: ciphertext only — nothing in between can read it.

The difference isn’t “Telegram is insecure” — Telegram’s transport is TLS either way, so nothing is exposed in transit on the wire between hops. The difference is where plaintext exists at all: in the bot path, it exists in full at the bot’s backend and passes through Telegram’s servers unencrypted relative to any third party (device-to-device); in the E2EE path, plaintext exists only on the two endpoints — your agent’s machine and your phone.

What this means for agent chats specifically

This matters more for agents than it does for most bots, for a simple reason: agent messages are unusually information-dense. A human-run customer-support bot might send “your order shipped” — mildly sensitive at worst. An AI agent wired into your Telegram bot is plausibly sending build statuses with internal repo paths, approval requests describing exactly what a deploy will do, error messages with stack traces, and — if it’s a personal agent — genuinely private context about your calendar, your purchases, your home. All of that transits and rests in plaintext at the bot’s backend and at Telegram’s Bot API servers. And per the token problem above, if the bot’s token ever leaks, someone else can not only read that history-in-flight but impersonate the bot going forward.

The honest caveat: Telegram bots are fine for a lot of things

None of this means Telegram bots are bad, categorically. For a public status bot, a low-stakes reminder bot, or anything where the content isn’t sensitive and impersonation risk is low, the Bot API is simple, free, and extremely well documented — that simplicity is exactly why so many personal-agent projects reach for it first. The point of this page isn’t “never use a Telegram bot.” It’s narrower: don’t describe that setup as end-to-end encrypted, and think twice before routing anything genuinely sensitive — build internals, approval decisions, personal context — through a channel where the plaintext sits on a server you may not even control.

If you want the same “agent messages me” convenience without that trade-off, that’s the specific gap Chime is built to close — see why a personal agent shouldn’t live in a Meta app for the WhatsApp side of the same argument, or jump straight to Quickstart to pair your phone.

Free forever — chatting with your agents will never cost money, and self-hosting everything stays free.

Next

telegrame2eesecurityexplainer