LZLZL/AI toolchain/Always-on · Messaging
FREEMedium · Practice C · Always-onsecurity

Telegram: lock down who,
then discuss what

2026-08-21 · Anyone who can message you can command it

Having the agent reach you on your phone is the best part of running one. It also opens an entrance anyone can type into, and the thing behind that entrance runs commands. So the order here is: lock down who, then discuss what.

In this pagethe authorisation model, tiers, session isolation, running it persistently. Not in this pagemy bot, allow-list or deployment. All example IDs are placeholders.

1State the threat first

people who can message it + it can run commands = the whole risk

That is a deduction, not alarmism. And it has two layers, the second of which people rarely picture:

LayerThreatBlocked by
1A stranger issuing it commands directlyAuthorisation: who may speak (§2)
2Content you forward or paste in that contains instructionsPermissions: what it can do (§5)

The typical layer-two scenario: you paste in a web page, an email, an issue body for summarising, and inside that text is "ignore your previous instructions and do X". To the agent, that looks exactly like something you typed.

2Authorisation: two routes, both deny-by-default

The line to remember: the gateway denies every user who is not on an allow-list or paired via DM. That is the correct default — a tool that defaults to open is the one to worry about.

RouteHowSuits
Allow-listComma-separated user IDs in TELEGRAM_ALLOWED_USERSJust you, or a fixed handful
DM pairingAn unknown user messaging the bot receives a one-time code; you approve with hermes pairing approve telegram <code>Adding someone temporarily without editing config and restarting

Three properties of the pairing code are worth knowing: expires after 1 hour · rate-limited · generated with cryptographic randomness. Together that means it cannot be brute-forced and does not linger.

There is also hermes pairing list (who has paired) and hermes pairing revoke. Use the second one periodically — temporary approvals are easy to forget.

3Tiers: allowed to speak is not allowed to do everything

Can
AdminsAll slash commands
Ordinary usersOnly the ones you explicitly enable, e.g. /status, /model

Two settings: allow_admin_from (who is an admin) and user_allowed_commands (what ordinary users may run).

⚠ Decide by worst case, not by usefulness

The question for enabling a command is not "is this useful" but "in the worst case, what could a hostile person do with it".

Read-only, affecting only their own session: fine. Changes config, triggers actions, or exposes other people's content: no.

4Session isolation

The gateway keeps a per-chat session store, so conversations do not bleed into each other. User-side commands:

CommandDoes
/new · /resetStart a clean conversation
/sessionsList and resume earlier sessions

Sessions persist until you reset them or context compression kicks in. That is also where the cost comes from — a long un-reset session pays for its entire history on every reply (page 9). Getting into the habit of /new is both cheaper and more accurate.

5Blocking layer two: permissions, not prompts

"I told it in the prompt to ignore strangers' instructions" is not enough

A prompt constraint is a tendency, not a gate. What actually holds is: it could not do that thing in the first place.

So before connecting a messaging gateway, trim the tool surface (next page is entirely about this): an agent that can read but cannot delete, cannot move money and cannot send messages outward does limited damage even when fooled.

One more practical rule: split "processing outside content" and "operating my systems" into two separate entrances — anything that acts happens on a trusted channel, while the messaging gateway reads and answers.

6Making it persistent

CommandDoes
hermes gateway setupInteractive configuration of the platforms
hermes gateway installInstall as a user service (systemd on Linux, launchd on macOS)
sudo hermes gateway install --systemSystem service, starts at boot
hermes gateway start / stop / statusStart, stop, check
⚠ A trap the docs call out by name

The official documentation warns explicitly: do not add a systemd drop-in such as ExecStopPost=/bin/kill -9 — it causes an infinite restart loop.

The general lesson: do not wrap your own process management around a service that already has some. Two layers fighting produces the symptom "it keeps restarting and the logs never say why". General service setup is on page 21.

Authorisation The gateway denies by default any user not allow-listed or DM-paired; allow-list via TELEGRAM_ALLOWED_USERS (comma-separated IDs); DM pairing approved with hermes pairing approve telegram <code>, with the official note that codes "expire after 1 hour, are rate-limited, and use cryptographic randomness"; also hermes pairing list / hermes pairing revoke.
Tiers allow_admin_from designates admins; user_allowed_commands lists what ordinary users may run (official example: status, model).
Sessions A per-chat session store; user commands /new, /reset, /sessions; sessions persist until reset or context compression.
Persistence hermes gateway setup / install / start / stop / status; --system for a boot-start system service; launchd plist on macOS. Official docs warn against adding ExecStopPost=/bin/kill -9-style drop-ins (infinite restarts). All per official documentation, checked 2026-08-21.
Deliberately absent The steps for obtaining a bot token from BotFather — that is Telegram's own flow; this page does not restate UI steps that will expire.
Not in this page My bot, allow-list, admin IDs or deployment. All example IDs are placeholders.

RelatedRead next

C · Always-on
MCP and the tool surface: what not to install
C · Always-on
Hermes Agent: where OpenClaw leads next
D · Cloud
Run it as a service, so it restarts itself
B · Access
Where the tokens actually go
An educational and engineering record — not a review or endorsement of any third-party product. Commands, config keys, prices and terms are per each vendor's official docs; this page states when it was checked and all of them can change without notice — verify before you copy anything. Self-hosting is your own responsibility: keys, accounts and data are on you.