Insights
Why your IT team blocks Telegram
And what to ask any vendor before you put an AI assistant on a work laptop.
We build AI assistants that run on messaging channels — our PraxisOS personal assistant, built on Anthropic's Claude, talks to its owner on Telegram or WhatsApp. We ran into this ourselves at a client site, went looking for the reason, and found the objection was better founded than we expected. This is what we learned. We would rather publish it than have customers discover it during a security review.
The policy is not arbitrary
Many corporate networks block the Telegram Bot API. Not the app on someone's phone, the programmatic interface. The reason is that it has become one of the most common routes for malicious software to move stolen data off a company machine.
The pattern is well documented by security vendors. Malware carries a bot credential, uses the interface to receive instructions, and pushes files out through the same channel. Two things make it attractive to attackers: the destination is a legitimate service that cannot be taken offline the way a malicious domain can, and the traffic looks like ordinary use of a popular product.
That last point is the one that matters to you. At the network level, a legitimate integration and an exfiltration tool can look the same. Standard guidance is therefore to block the interface wherever it is not explicitly needed. If your security team has done that, they are following mainstream advice, and asking them to make an exception is a bigger request than it first appears.
Why this lands on AI assistants
An assistant you control from your phone works by receiving instructions over a messaging channel and acting on them on a machine. Described plainly, that is remote instruction of a corporate device through a third-party service.
That is an accurate description of a useful product and of a category of malware. The difference is not in the shape of the traffic. It is in whether a human authorises each action, whether some actions are refused outright, and whether there is a record nobody can quietly edit.
So the question to put to a vendor is not “is your traffic safe”. It is what constrains the capability, and what can you check yourself.
The likelier failure is the lookalike
Before comparing channels, it is worth naming the most probable way this category actually hurts a business: not a vendor's assistant being breached, but installing something that was never the vendor's tool. The AI-assistant wave is a lure. Cloned repositories, fake desktop apps, and poisoned packages riding that wave are a documented, active pattern — and what they carry is exactly the kind of malware the Telegram block exists to catch.
Our position on distribution is simple. PraxisOS is not something you find and download: no app-store listing, no marketplace, no public installer. In the default deployment there is nothing to install at all, and where an on-device setup is explicitly arranged, a Better Execute specialist performs it with you, from sources named in the engagement. If you have found a PraxisOS download anywhere else, it is not ours — and we would genuinely like to hear about it.
It also gives you a clean question for any vendor in this category: how does their software reach your machines, and how do you verify that what arrived is what they shipped?
Is WhatsApp safer?
Differently exposed, rather than safer, and it is worth being precise about why.
A Telegram bot can be created anonymously in about a minute. WhatsApp's business interface requires a registered business, a verified phone number and identity checks with the provider. That friction is unattractive to an anonymous attacker, which is a large part of why the same blanket blocks tend not to apply.
An honesty note about our own product before we lean on that: PraxisOS's WhatsApp channel pairs with the owner's own phone number rather than going through that verified-business onboarding. The identity friction above is a fact about the ecosystem your IT team is weighing, not a vetting badge we get to wear — which is one more reason we keep pointing you at the controls in the tool rather than the choice of channel.
It is a real difference, and it is about accountability of the sender rather than security of the transport. Both channels move your data through a third party. WhatsApp routes through Meta, which your team may weigh differently again. One caution on marketing language while you are here: “end-to-end encrypted” means different things on different paths. A Telegram bot conversation is not end-to-end encrypted at all. A WhatsApp business-API integration terminates encryption at the provider's infrastructure. A paired WhatsApp deployment — the kind we run — genuinely is end-to-end encrypted, but the linked endpoint is the vendor's workspace, so the plaintext still lands with the tool and its downstream processors. Whatever the pipe, the endpoint that matters is the tool. The controls that actually protect you sit there, not in the transport, and they should work the same whichever channel you choose.
Five questions worth asking
These apply to any vendor in this category, including us. If a vendor cannot answer them plainly, that is the answer. Ours are in the next section, so you can judge whether we pass our own test.
Does a human approve actions, and what happens when it cannot ask?
Approval that quietly passes when the prompt fails to send is not approval. The honest answer is that it refuses. Ask what happens on a timeout, on a network failure, and when no approval channel is configured at all.
What data leaves the machine, to where, and who can read it?
You want a diagram, not an assurance. If the vendor cannot produce one in a week, they have not thought about it as carefully as you need them to.
Can the software rewrite its own audit log?
"We keep logs" is close to meaningless when the thing writing them could also edit them. Ask whether entries are chained or otherwise tamper-evident, and ask to see the verifier.
What permissions does it request, and can we verify that ourselves?
Read-only mail access should be visible in your own identity console, revocable by you, without the vendor's involvement. If verification requires trusting a PDF, it is not verification.
Which outbound domains does it use?
A short, fixed list your firewall can enforce turns a promise into a control you operate. An open-ended one means you are trusting the vendor's future decisions as well as their current ones.
How we answer them
For PraxisOS, our personal assistant. One of these answers is an admission, and we have left it in.
1. Approval
Every action that leaves the assistant — an email sent, a calendar change — waits for its owner's explicit approval. If the approval prompt cannot be delivered, because of a timeout, a network failure, or because no approved channel is configured, the action does not happen. The assistant proposes; silence is a no.
2. Data flow
The diagram is below. PraxisOS runs on the user's own machine, not a Better Execute server. Mail and calendar are reached through scoped OAuth to the user's provider. Two third parties process the content it works on, and both are worth weighing: Anthropic's API runs the model over it, and the messaging provider carries whatever briefings and drafts the user asks to see in chat. One human path we name ourselves: with the standard support option, our staff can reach the machine over a dedicated support tailnet to fix faults — only when the user asks for help, revocable, working from logs and service configuration rather than mailbox content, though service config can include credentials, so treat it as vendor access. If standing access is a line for you, say so at setup — support then works from logs shared manually, with a scrubbed self-serve diagnostics bundle being built to replace that; details are in the IT brief. Working memory and access tokens stay on the machine, and sensitive mail categories — HR, legal, personal — are excluded before anything is ingested at all.
3. Audit log
Honestly: no. Our action log is written by the workspace it describes, and we will not pretend that answers the question. Your identity provider's logs can bound the picture — when the grant existed, what tokens were issued — but they record authentication, not the propose-approve-act sequence, and chat history is no substitute because bot-channel messages can be edited or deleted by either side, ours included. An independently tamper-evident action trail does not exist in PraxisOS today. Building one is on our engineering list, and we would rather tell you that here than imply otherwise in a PDF.
4. Permissions
First-phase access is read-only — read mail, read calendar — granted through a standard OAuth consent that appears in your own Microsoft 365 or Google Workspace admin console and can be revoked there, by you, without involving us. No send-as, no domain-wide access, one mailbox. Write scopes are a separate later approval with the same visibility, requested only after working rules are agreed.
5. Outbound domains
Short and fixed: the user's mail provider API and sign-in endpoints, Anthropic's API, and the chosen messaging channel. The services are tabled in the IT brief linked at the end of this page, and we supply the exact enforceable allowlist for the user's tenant and channel as part of setup. Because PraxisOS runs on the user's machine, those connections originate there — so the allowlist is something the user's own firewall can enforce directly.
What a scoped approval looks like
PraxisOS installs and runs on the user's own machine, so the review is a real one and we would rather set it out plainly than pretend it is nothing. Two parts: the software on the device, and the outbound connections it makes. Both are bounded, both are enforceable by the user's own controls, and neither requires opening the network inward.
Where the data flows
Owner's phone
Telegram or WhatsApp app the owner already has. Conversation and approval requests only.
Messaging provider
Telegram or Meta relays the conversation — including briefings and drafts built from mail content. Never holds the mailbox connection or its tokens.
PraxisOS on the user's machine
Runs locally, not on a Better Execute server. Assistant, working memory and approval gate all stay on the device. The content being processed is sent to Anthropic's API to run the model, then returned.
Your mail & calendar
Microsoft 365 or Google Workspace, reached with scoped OAuth you can see and revoke in your own console.
On the device, not on a vendor server. The assistant, its working memory and its access tokens stay on the user's machine. The estate is touched at two points the user controls: the OAuth consent to the mailbox, visible and revocable in the admin console, and outbound HTTPS to a fixed, enforceable domain list.
In the path, and worth naming: the content being processed reaches two third parties — Anthropic, which runs the model, and the messaging provider, which carries any briefing or draft the user asks to see in chat. The sensitive-category exclusion and read-only scope bound what that can include; if either party's retention terms matter to your review, ask us before the consent, not after.
So the actual ask to the IT team is:
- Standard developer tooling installed on the user's machine — the runtime, the assistant, and the tools it drives. No admin agent, no management backdoor.
- Outbound HTTPS to a short, fixed domain list the user's own firewall can enforce. No inbound ports anywhere.
- One OAuth consent for one mailbox, read-only in the first phase, visible and revocable in the admin console without our involvement.
- The user talks to the assistant from their phone, on an app they already have.
That is a real network and endpoint conversation rather than nothing, and it is the honest shape of running software on your own hardware: the controls that bound it are ones you hold and can audit, not assurances you have to take on trust.
What we changed
Our own approval step used to run over Telegram. In an environment that blocks Telegram, that is circular: the control meant to reassure you depends on the thing being distrusted. We rebuilt it to run over whichever channel a customer approves, and to refuse to operate rather than quietly fall back to one they have not.
We also stopped assuming a channel. Deployments now default to whichever channel a customer's environment already trusts — WhatsApp where Telegram is blocked, Telegram where IT is comfortable with it — and because the hosted architecture keeps that traffic off the corporate network, the choice rarely needs to be a network debate at all. A control that has to be argued for at every new site is not much of a control; meeting an environment costs less than debating it.
Send this to your IT team
The one-page IT brief has the version they will actually want: what runs where, the exact scopes and domains, and how to revoke access. If they raise something neither page covers, we would rather answer it directly than route it through a sales conversation. The questions worth asking are usually the ones a vendor page has quietly left out.