In this article
Adding a bot to a community feels like installing a feature. It is closer to giving somebody a key, because a bot is not software running in your group — it is software running on somebody else's computer, holding a credential that lets it act in your room.
Step 058 established the permissions rule: never grant a bot the right to add administrators. This step is the part underneath that — who is actually on the other end, what the credential is, and what to do on the day it goes wrong.
What you will be able to do after this step
- check_circle Explain what a bot can read, by default and as an administrator.
- check_circle Evaluate a bot before adding it, using things you can actually check.
- check_circle Say what the token is and why it is the whole of the bot.
- check_circle Cut a bot off immediately, from both ends.
smart_toy Where a bot actually lives
The bot in your group has no code inside Telegram. Somewhere there is a server that holds a credential — the token — and uses it to receive messages and to act. The account you see is a face for that server.
Three consequences follow, and all of them are invisible from the group.
Whoever holds the token is the bot. Not the person who built it, not the person who recommended it — whoever has that string. If it is committed to a public repository, or sits in a configuration file on a machine somebody else can read, the bot has quietly changed hands with no visible difference.
What it does can change at any moment. The operator can alter the behaviour between one message and the next. There is no version, no update you approve, and no notification. A bot that has behaved perfectly for a year is evidence about the past.
Everything it receives leaves the platform. Whatever a bot can see is transmitted to that server and handled under whatever rules apply there, which you cannot inspect.
You add an ordinary bot to your group. What does it receive?
The default is narrow and it is a genuinely good default. But it is a default rather than a guarantee: the bot's owner controls that setting from their side, and making the bot an administrator changes the picture entirely. So the accurate thing to tell your members is not "bots cannot read the group" — it is "this one receives what is addressed to it, and it is run by these people." The first sentence is a promise you are not in a position to make.
What changes when you make that bot an administrator?
This is the largest single concession in community management and it happens in two taps. A moderation bot cannot filter what it cannot see, so the capability is inherent rather than excessive — but it means the entire conversation now flows to somebody else's server continuously. That is a reasonable trade for a tool you have evaluated and a poor one for a bot somebody recommended in a comment. The decision belongs at the moment of promotion, not at the moment of adding.
How do you find out what a bot has actually been doing in your group?
A bot with administrative rights appears in the log from Step 059 exactly like a person, with every deletion, restriction and setting change attributed to it. That is the only independent account you have of its behaviour, and it is why the habit from that step matters most here: read the log the day after adding any automation, and once a month afterwards. A bot removing three messages an hour that you would not have removed is invisible in every other way.
You decide a bot has to go. What actually cuts it off?
Removing it from the group ends its access to that room immediately, which is the action to take first and quickly. Taking away its rights while leaving it in place is the half-measure people reach for, and it leaves a member that still receives whatever its settings allow. Blocking it from your own account does nothing for the group at all. If the bot is one you run and the concern is a leaked credential, the token has to be revoked too — otherwise whoever holds it still controls the bot everywhere else it has been added.
task_alt
fact_check Evaluating a bot with things you can check
There is no review process, no publisher verification and no permissions screen at install time. What you have are a few observable signals, and they are better than nothing.
Is there a person behind it? A bot that links to a channel, a site or an account belonging to somebody identifiable has staked a reputation you can damage. One with no attribution anywhere has staked nothing and can be replaced tomorrow.
Does what it asks for match what it does? A bot that posts a daily digest does not need to restrict members. A welcome bot does not need to change group information. Anything requesting more than its function requires is the single clearest warning available.
Is it open, and does anybody run it themselves? Published source does not prove the server is running that code, but it makes the behaviour inspectable and means somebody other than the author has read it.
How does it behave in its first week? Add it with the minimum permissions, watch the log, and grant more only when you can name the thing it could not do.
And the rule that survives all of this: a bot that wants the right to add administrators is finished as a candidate, whatever its explanation. There is no legitimate moderation function that requires the ability to create administrators, and the consequence of granting it is that whoever controls the bot can create a person who removes you.
touch_app Try it now — five minutes
Four steps, and the first will surprise most people who run a community of any age.
- List every bot in every room you administer They appear in the administrators list alongside people. Most communities find one nobody remembers adding and one that has not done anything for a year.
- Check the permission that matters Whether any of them can add administrators. If so, remove it now — before finishing this page.
- Read yesterday's log entries for the bots that remain Step 059's screen, filtered to each bot. You are looking for actions you would not have taken.
- Remove the ones that are not earning their access A bot nobody uses is a standing permission with no benefit attached, which is the easiest kind of risk to retire.
cell_tower A bot in a channel is a different arrangement
Everything above assumes a group. A channel changes two things worth knowing before adding automation to one.
First, a bot cannot post to a channel at all without administrative rights, so there is no low-privilege starting position — the decision is made immediately rather than gradually. Second, and more significant: what it posts appears as the channel, under your name and picture, indistinguishable from anything you wrote yourself.
Subscribers have no way to tell which posts came from a person and which from a script. That is convenient for scheduled publishing and it means a misbehaving or compromised bot does not look like a bot misbehaving — it looks like your channel saying something. Reading Step 059's log, and keeping the posting rights separate from everything else on the permissions screen, is the whole of the defence.
help Common questions at this stage
Can members tell what a bot can see?
Not from the group. A bot appears as a member and, if promoted, in the administrators list — but the setting that determines how much of the conversation it receives belongs to its owner and is not displayed. Since members will ask, the honest answer is the one from the quiz: describe who runs it and what it is for, rather than making a claim about what it cannot see.
Is a bot with a verification mark safe?
A mark is a statement about identity, not about conduct — the same point Step 063 makes about impersonation. It tells you the account is who it claims to be, which is genuinely useful against copies, and says nothing about what the code does with your conversation. Treat it as one signal in the evaluation above rather than as an approval.
What happens to my group if the bot's server goes down?
Whatever it was doing stops, silently. There is no error message in the group and no notification — welcome messages simply stop appearing, the filter stops filtering, the digest does not arrive. This is the most common bot failure by a distance, and it is a reason not to build anything load-bearing on automation you do not control. Check occasionally that it is still working rather than assuming.
Can a bot read my private messages to other people?
No. A bot receives only what happens in its own chat with you and, subject to the settings above, in groups it has been added to. It has no visibility into your other conversations, your contacts or your account. The exposure is bounded by where you have put it — which is why the list from the steps above is worth keeping short.
Should I write my own instead of using somebody else's?
For anything simple it is more achievable than people assume, and Step 086 onwards is the path. The honest trade is that you take on the token, the server and the outage. For a community that depends on the automation it is worth it; for a welcome message it is not, and the better answer is usually to need less automation rather than to run more of it.
Is there a way to limit a bot to one topic?
In a forum group, yes in practical terms — a bot can be pointed at a specific topic for its output, which is the arrangement Step 057 recommends for automated messages. That is about where it writes rather than what it can read, so it tidies the room without reducing the access. The access is still governed by the permissions you granted.
At a glance
- 1What a bot reads
By default only messages meant for it; as an admin, everything.
- 2Check before adding
Who runs it, what it stores and why it needs each right.
- 3Cut it off
Remove it from the group, and if it is yours, revoke the token.
Updated
