The Telegram Front Door
Module 5 put your agent on a server that does not close. It is still only reachable by SSH from a laptop. This session moves the interface to your phone, and spends half the hour on who is allowed through the door.
You need the server from Module 5, running your agent with the vault cloned onto it. The Module 5 page rebuilds it if yours is down. Bring Telegram on your phone, signed in, and your SSH access already tested.
The ideas that carry the session
Deny is the default, and that is the whole design
With nothing configured the gateway answers nobody. The one line that changes that is the one line worth getting right, and there are two flags that turn the system off entirely.
The lock is a Telegram account
Your agent can run commands on a server. The thing standing between a stranger and that shell is a number identifying your Telegram account. It is a good lock. It is the only one.
Adding an interface did not open a port
Long polling means the agent reaches out, so the firewall stays exactly as Module 5 left it. Most people expect the opposite, which is why the firewall gets checked on camera.
Unanswered means denied
Walking away from your desk never approves anything. The system fails closed, and that is only reassuring once you have watched a prompt time out and refuse itself.
Silence is a feature
A job that reports every healthy run is noise you will learn to ignore, and an ignored monitor is not a monitor. The quiet marker is what keeps the alert worth reading.
Not everything that messages you needs a model
When the text is already decided, send it. Asking an agent to relay a sentence you wrote costs tokens and adds a dependency on the gateway being healthy.
The 60-minute session
Part one gets the bot answering. Part two is about making it safe and useful, and the approval flow is protected: a prompt you deny from your phone is the deliverable.
Open with the payoff
A phone mirrored on screen. The agent reads a note off the server and replies. Then it asks permission to delete something, and the prompt gets denied on camera.
The token and your user ID
BotFather returns a token, which is a credential and gets cropped on stream. Then your numeric user ID, because a username can be changed by whoever holds the account.
The allowlist, and deny by default
Six checks, and the bottom one is deny. With nothing configured the bot answers nobody. Ask the agent to edit .env and watch it refuse, then edit it by hand.
Restart, and the first message
One restart, one message, and a firewall check proving no inbound port was opened. Long polling means the agent reaches out, which is the opposite of what people expect.
The approval prompt
Approve one, deny one, then walk away from the phone and let one time out. Unanswered means denied, and that is only reassuring once you have watched it happen.
Tiers and pairing
Admin commands split from user commands, then a volunteer paired in as a non admin, blocked from a command they do not have, and revoked.
Scheduled results in your pocket
A morning digest that stays silent on the mornings nothing happened. A monitor that reports every healthy run is noise you will learn to ignore.
Scripts, with no agent involved
When the text is already decided, send it. No model, no gateway, no tokens spent. Wire it into the sync job from Module 5, then break it on purpose.
The build, step by step
Every command and every copy-pasteable brief is in the student guide.
What it costs
- Telegram
- Free
- The server
- Already running from Module 5
- Model usage
- Only what your scheduled jobs spend
This module costs nothing. The entire cost is the risk you take by opening a door, which is why half the hour is spent on who is allowed through it.
The honest part
If your bot token leaks, whoever holds it controls your bot until you revoke it. If your Telegram account is taken over, the person holding it is already on the allowlist and the approval prompts go to them. Manual approvals and a one person allowlist make this a reasonable setup for your own server. They do not make it a vault, and anyone putting client data behind it should know the difference before they do.
Knowledge check
Five quick questions to check your understanding, then four to answer in your own words for peer review.
1.You install the gateway, add your bot token, and configure no allowlist at all. Who can talk to your bot?
2.Adding Telegram to your server means opening which inbound port?
3.An approval prompt arrives on your phone and you never answer it. What happens?
4.Your morning cron job messages you every single day, including days you did nothing. What is missing?
5.You ask your agent to add the bot token to ~/.hermes/.env and it refuses. Why?
Explain in your own words
Answer these in your own words. Explaining a concept is the best test that you understand it. You can check your results now; sign in when you save to keep them in your account.
Where this sits in the course
Each module is a standalone hands-on session, though the later ones build on what the earlier ones left running.
Join us live
Register on Luma to get the student guide and the livestream link. Read the guide before you arrive; the session moves at the speed of someone who already has the accounts open.