3 min read

How I Locked Down a Hermes AI Agent in Telegram With Permissions and Guardrails

How I Locked Down a Hermes AI Agent in Telegram With Permissions and Guardrails

The first bad command

I was testing our Hermes agent in a Telegram support channel. It had a shell tool enabled because I wanted it to check service status and read logs for the ops team. During a routine test I asked it to restart the API after a config change. It picked the production service and ran the restart without asking.

Background

At 1it.pro I run small infrastructure setups. The agent was meant to help with support triage, reminders, and simple checks. We installed it with AgentForge, configured it in the web UI, and connected it to Telegram. The setup took an afternoon. The permissions took less thought than they should have.

I gave the agent broad access because it was convenient. It could read most project files, run shell commands, and send messages in the support chat. It felt like a helpful teammate. It also had more power than any teammate needs for the task.

The problem was not the prompt

The problem was the permission model. The agent did what I asked, but my request was ambiguous. Restart the API does not say which API. The agent looked at the environment, found a service name, and executed the command. There was no approval step and no allowlist.

That incident was small. It still showed the real risk. A slightly different prompt could have touched a database, read a .env file, or sent a message to the wrong Telegram chat. The agent was useful. The boundaries were missing.

Why this matters

An AI agent with broad permissions turns every vague instruction into an infrastructure change. In support and internal ops, that is not acceptable. The cost is not just downtime. It is the loss of trust from the team that has to review the bot's work.

Doing nothing creates a false choice. Either you let the agent do useful work with too much access, or you disable it and lose the value. Both options fail. The agent needs enough access to be useful and hard limits around anything destructive.

The goal is not to make the agent harmless. The goal is to make its useful actions explicit and its dangerous actions impossible without approval.

What I changed

I rebuilt the agent's permissions around the actual job. The agent in Telegram now has three roles: answer support questions from approved docs, create reminders, and run read-only status checks. Everything else needs a human approval or is blocked.

In AgentForge I split the tools by risk. The shell tool is no longer a general shell. It accepts a small allowlist of commands like check-service and uptime. File access is limited to a read-only directory with runbooks. Secrets are mounted outside the agent's reach.

I also changed the Telegram workflow. The agent answers in the support chat, but any action that changes state goes to a private approval chat. A human taps approve or reject. The agent logs the request, the command, and the result. If the log entry is missing, the action does not run.

  • 🔒 Separate bot token for support triage and internal ops
  • ✅ Command allowlist instead of open shell access
  • 📁 Read-only mounts for docs and logs
  • 🛂 Approval step for restart, write, delete, and send-to-new-chat actions
  • 🧾 Audit log for every tool call

I did this with Docker Compose so the boundaries survive restarts. The agent container runs as a non-root user. It has its own network. It cannot reach the Docker socket. That one change removed the most dangerous path because the agent can no longer control other containers.

The result

After the change the agent stayed in the support chat. It answers runbook questions, creates reminders, and runs read-only checks. It cannot restart a service, edit a file, or read .env. If someone needs a restart, the agent prepares the request and waits for approval.

The support team can use it without watching every move. The difference is not that the agent does more. It does less, and the team trusts it more.

AgentForge

AI agents for real work. If you want to see how this works in practice, visit our product site and blog.

Share
Serhii

Serhii