Personal AI agents are starting to take a major leap forward. Projects like OpenClaw show that we are no longer talking only about assistants capable of answering questions, but about systems that can access tools, consult information on your computer, execute actions, and even act on our behalf.
But the more power we give them, the more important one issue becomes an issue that is often pushed into the background: security.
Imagine that we have built our local agent, connected tools to it, and now want to interact with it from anywhere using our mobile phone. Telegram seems like an ideal option: it is reliable, available on virtually any device, and offers a free, very mature API.
However, there is a problem that is rarely addressed in enough depth.
The most natural way to connect any agent to Telegram forces you, as a user, to make an uncomfortable decision: open a port on your computer or leave the bot token exposed on your local machine. Either option creates an attack surface that, in an agent with access to your tools, you simply cannot afford.
In this article, we will see how we solved this problem in AzulClaw through an architecture based on Azure Bot Service, Azure Functions, and Azure Service Bus, completely eliminating the need to expose the local machine to the Internet.
Telegram offers two main mechanisms for receiving messages from a bot.
Long Polling:
With this approach, the application makes periodic requests to Telegram to check whether there are new messages. The advantage is that there is no need to expose any port or have a public URL; we are the ones contacting Telegram.
However, it has several limitations when we work with AI agents.
If the agent needs several seconds to reason through a response using a language model, the reading process can become blocked. Messages start to accumulate, and handling errors, restarts, or process crashes ends up depending entirely on our code.
As the agent becomes more complex, this approach becomes harder to maintain.
Webhooks
The second option is to register a public URL so Telegram can send messages directly in real time. From an operational point of view, it is a more elegant and efficient solution. The problem appears when the agent runs on our own machine.
To receive those messages, we must expose an endpoint accessible from the Internet. In many projects, this involves configurations similar to:
{ "channels": { "telegram": { "webhookUrl": "https://mi-dominio.com/telegram-webhook", "webhookHost": "0.0.0.0" } }}
That value means the application will listen on all available network interfaces.
It is not a bad practice in itself. In fact, it is the approach used by many open-source projects and is perfectly valid for many scenarios. But when the agent has access to personal files, corporate tools, private APIs, or execution capabilities, the situation changes considerably.
The key is to question an assumption we usually take for granted.
What if the agent did not have to communicate directly with Telegram?
Instead, we can introduce an intermediate cloud layer responsible for receiving messages, validating them, and securely transporting them to our local agent.
In this way, Telegram never interacts directly with the machine where the agent is running.
This is how the architecture we implemented in AzulClaw works:
Each component has its role:
AzulClaw running locally reads from the queue, processes the message, and puts the response back. Everything is outbound traffic. Never inbound.
Removing public exposure of the agent is a major step, but it is not enough.
We must also protect the endpoint that receives messages in Azure.
For that reason, the relay implements three complementary security mechanisms.
From the user’s point of view, the integration is extremely simple. The local runtime includes a worker that:
The only required dependency is a Service Bus connection string.
There is no need to open ports.
There are no TLS certificates to maintain.
It does not matter whether the agent is behind a corporate VPN, a home network, or NAT.
In addition, if the agent restarts or remains temporarily disconnected, messages continue to be stored in the queue until it can process them.
The architecture naturally provides resilience.
Although the example uses Telegram, the real value of this pattern goes far beyond one specific platform.
The core idea is to completely decouple external channels from the agent we run locally.
Telegram is only one of those channels.
The same approach can be applied to mobile applications, enterprise services, messaging platforms, or any system that needs to communicate with a private agent.
In addition to improving security, we gain further advantages:
As AI agents move from experimental projects into corporate environments, the standards change. In an enterprise network, opening ports or relying on vulnerable local configurations is not acceptable.
To solve this at the root, at AzulClaw we chose to fully isolate execution. When you delegate critical actions to a system that acts on your behalf, the architecture must be secure by default.
If you want to implement this model, the full code — the Azure Function, the Terraform module, and the integration with the local runtime — is available in [AzulClaw]. The official Telegram skill includes everything needed to deploy this in any Azure subscription.
How to Securely Connect Your AI Agent to Telegram with Azure was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.