Feature request: Per-chat read/write allowlists with web-based configuration UI

[F0rzend]

Problem

I use Telegram as my primary corporate messenger and want to give an AI agent access to specific chats only. Currently, telegram-mcp operates on an "all or nothing" basis — once a session is authorized, the agent has full access to every chat in the account. There is no way to restrict which chats the agent can read from or write to.

For a corporate environment, this is a significant security concern. I need granular control:

• Read allowlist — a list of chat IDs/usernames the agent is permitted to read messages from
• Write allowlist — a separate list of chat IDs/usernames the agent is permitted to send messages to

Any tool call targeting a chat not on the respective allowlist should be rejected by the server before reaching the Telegram API.

Proposed Solution

1. Per-chat access control via environment variables or config file:

   • TELEGRAM_ALLOWED_READ_CHATS — comma-separated list of chat IDs/usernames for read access
   • TELEGRAM_ALLOWED_WRITE_CHATS — comma-separated list of chat IDs/usernames for write access
   • When set, all tools decorated with @with_account(readonly=True) should validate chat_id against the read allowlist, and tools with readonly=False should validate against the write allowlist.
   • If the lists are empty or not set, current behavior (full access) is preserved for backward compatibility.

2. Web-based configuration UI (like Serena):
   To make managing these allowlists practical (especially when dealing with many chats and multiple accounts), I propose adding a lightweight built-in web interface for configuration — similar to how Serena provides a web UI for its MCP server settings. This UI would allow users to:

   • Browse available chats and toggle read/write access per chat
   • Manage per-account allowlists visually
   • Preview the effective permissions before applying

Alternatives Considered

• Dedicated bot account — works but loses access to private chats and chat history prior to bot joining
• Forking and patching — not sustainable long-term
• MCP client-side filtering — not all clients support this, and it's less secure (the server still exposes all tools)

Additional Context

The existing File Path Security system with allowed roots is a great precedent for this feature — it already demonstrates the pattern of "disabled by default, enabled only for explicitly allowed targets." The same philosophy could be applied to chat access.