What can a Telegram bot read? An admin's access and data checklist
Understand group privacy mode, private bot chats, guest access and bot-to-bot messages. Check processors, moderator logs and deletion before trusting a service with community data.
A Telegram moderation bot with administrator access can receive ordinary messages in its group. That access does not automatically open every member's other conversations. It also does not tell you what the bot operator keeps, who else processes the text or what happens to stored records after you remove the bot.
Before adding a service, answer two separate questions: what can reach the bot, and what happens after it arrives? This guide is a practical review for group administrators. It is not a privacy certification or a substitute for an organization's legal review.
Identify the actual access route
“The bot is in Telegram” is too vague to describe its access. A group moderator, a guest assistant and an automation connected to a personal account can receive information through different routes.
Private messages to that bot
If you send a bot a message, the bot receives it. Group Privacy Mode does not protect a private conversation with the bot. Treat files and text sent for support as information you are giving that service. The Bots FAQ also describes service-message and channel delivery; its older blanket exclusion of other bots' messages needs the update below.
A group member with Privacy Mode enabled
The bot receives relevant commands, certain replies and messages sent through it, rather than the ordinary conversation stream. A command addressed to the bot is a clearer test than mentioning its display name. Service messages remain a separate input. Telegram's Privacy Mode reference explains the delivery conditions.
A group administrator, or a bot with Privacy Mode disabled
Ordinary group-message access is broader. Promoting a bot to administrator changes this boundary even if you intended to grant only one moderation capability. Review administrator permissions for the actions it can perform, and review message access separately. A bot that stays silent may still receive updates.
A guest bot invoked in a conversation
Since Telegram's May 2026 update, a supported bot can be invoked without joining the chat. The bot receives the invocation, not general access to the conversation or member list. Later messages reach it only through a new mention or a direct reply to the bot, as the guest interaction reference specifies. That still makes each invocation a data-sharing choice.
The guest-mode specification also includes referenced context, such as a message you reply to when invoking the bot. Review that context as part of the request. Guest mode is unavailable in secret chats and in groups with content protection enabled.
Do not paste a confidential exchange into a guest request because the bot is absent from the member list. A narrow input can still contain information the group did not intend to send elsewhere.
Automation separately connected to an account
Account-connected chat automation has its own selected chats and permissions. Audit that connection separately from group membership. The same May 2026 release describes choosing which chats an automation may access. Removing a bot from one group does not establish that a separately authorized account connection has been revoked.
These are Telegram capabilities. They do not establish that Defendy offers guest mode, account automation or bot-to-bot workflows.
Update the old rule about messages from other bots
“Bots never see other bots” is no longer a safe blanket statement. Current bot-to-bot documentation permits group command mentions or direct replies when at least one participating bot has the mode enabled. Private bot-to-bot messages require both bots to enable it.
For ordinary group bot messages, the receiving bot must have Bot-to-Bot Communication Mode enabled and either administrator access or disabled Group Privacy Mode, as the Bot Features reference specifies. Ask the operator which modes are enabled; a bot's marketing category does not answer that.
The practical implication is modest: do not put information into another bot's group message on the assumption that all neighboring bots are technically excluded from receiving it. You still need to examine the actual enabled connections and delivery conditions.
Separate access from a searchable history
An incoming-message permission is not evidence of a complete historical archive. Ask whether the service processes only arriving updates, stores earlier observations, accepts imports or uses a separate account connection. A newly shared quotation, forward or file can bring older information into a current interaction.
Similarly, “the message was deleted from Telegram” is not a verified answer about copies already received by an operator, a model service or a moderator's logging destination. Deletion in one place and deletion from every downstream system need separate evidence.
Telegram's privacy policy explains that bots can receive public profile information and interaction data, and that third-party bot operators are independent of Telegram. A familiar Telegram interface is not a substitute for checking the service behind it.
Follow one message through your proposed setup
Take an invented example: “Can I post a used-camera listing here?” Map the routes before testing with actual member content.
- Telegram delivery: under which role or invocation would the bot receive it?
- Service processing: which enabled function reads the text, caption or identifiers, and for what purpose?
- Optional external processing: does that function send content to a model provider or another service?
- Moderator records: does an incident create a record in another chat, and who can see that destination?
- Persistence: what is stored at each step, for how long, and how is a deletion request handled?
This is a review model, not a claim that every bot uses all five steps. Fill only the routes supported by the operator's answers. Leave missing answers visibly unresolved.
Defendy: the distinctions that matter
In Defendy's reviewed implementation, automatic AI verification is an optional stage of text anti-spam. Eligible checks send up to the first 300 characters of the message and the group title to the configured model endpoint. This is not a statement that every received message is sent to AI.
The manual /spam check is a separate path for a selected message. Its reviewed model request includes the selected text; do not apply the automatic path's 300-character boundary to it. A shorter input also should not be described as anonymous: identifying information may occur within the text itself.
The moderation log is another destination for selected events. Check the chosen chat, enabled categories and people with access. A staff log can widen the audience even when the original group is private.
Start with the site's privacy information and /privacy in a private chat with @defendy_bot. The website policy remains a draft and leaves the provider list and retention periods for operator confirmation. Ask for a current, consistent answer covering the enabled AI path and logging. This article cannot establish a deployed provider, a no-training promise, an encryption guarantee or a service-wide deletion deadline from implementation details alone.
Use a vendor worksheet that preserves unknowns
For each row, record answer, source or support reply, date checked, and any unresolved point. A helpful answer identifies the relevant product and feature; “we take privacy seriously” does not fill a technical blank.
| Ask the operator | Evidence to keep | If the answer is missing |
|---|---|---|
| Who runs the service and handles data requests? | Named operator, current policy and working contact route | Do not describe the operator as verified. |
| Which inputs does each enabled function receive? | Text, media, identifiers and connection scope | Keep real private material out of the trial. |
| Which external services receive data? | Processor list, purpose, fields and relevant settings | Do not promise processing stays within Telegram. |
| How long are records and copies retained? | Separate terms for content, logs, backups and other records | Mark retention unknown; a cache timeout is insufficient. |
| Can data be used to train models? | Terms for the actual provider and service configuration | Do not infer an answer from the model name. |
| Who can inspect content and moderation records? | Service-side access explanation and your log audience | Resolve access before introducing sensitive workflows. |
| What does removal or a deletion request do? | Procedure, scope, timeframe and stated exceptions | Distinguish revoked access from confirmed deletion. |
For an ordinary public-interest group, you may decide that an unresolved optional feature should stay off while a narrowly scoped trial proceeds. For a group that routinely handles private cases or documents, the same missing answer can be a reason not to connect the service yet. Make that choice based on the material actually shared, without labeling members or guessing their circumstances.
Tell members what you can verify
Build a short notice from the completed worksheet. Include the bot and purpose, which message access it has, any enabled onward processing, who can see moderation records, and the policy and contact route. Keep it close to the group rules, where newcomers can find it before posting.
Do not publish a template with guessed retention days or an unverified “nothing leaves Telegram” sentence. If an important answer is outstanding, say what is outstanding and keep the dependent feature disabled until you can make an informed decision. Revisit the notice when access or processing changes.
Offboard in two passes
First, revoke the access you actually granted. Remove the bot from the group, review its role in any separate log destination, and disconnect any separately authorized account automation you no longer need. Check the resulting membership and connection state. Do not use the absence of a bot reply as your only evidence.
Then, handle existing data. Use the operator's verified request route, specify the relevant account or group with the minimum necessary identifiers, and ask what will be deleted, what remains and why. Review your own moderator-log copies and authorized access too. Keep the request and response until the stated process is complete; do not call a submitted request a completed deletion.
The endpoint is an accurate record: access revoked where intended, existing copies handled under a confirmed process, and remaining unknowns plainly stated. A bot disappearing from the member list answers only part of the question.
Platform references were reviewed for this article on 6 October 2026. Product behavior above was checked in implementation; no live data-flow audit or deletion test was performed.
