Telegram MCP Security Checklist: Scope, OAuth, Approvals, and Revocation

A Telegram MCP security review should establish which account an agent can access, which actions the server permits, what requires a separate approval, and how access ends. A successful connection proves connectivity. It does not prove that the grant matches your team's intended workflow.

Use the checklist below before connecting customer conversations and after material changes to the client, server, team membership, or granted permissions. Begin with one authorized test conversation. This is a proposed acceptance protocol, not a completed penetration test, certification, or claim that a particular deployment is secure.

Publisher disclosure: Chiho publishes this guide and provides a hosted Telegram MCP service. Chiho examples are based on documentation and source reviewed on 26 September 2026; they are not live-account test results. Features present in a source revision may differ from your deployed connection. The header image is an existing Chiho CRM interface image, not a security-test screenshot.

1. Draw the trust boundaries before granting access

Record the Telegram account, MCP service, AI client, model provider, and any CRM storage involved. Identify who operates each component and where returned messages can be retained. Include client conversation history, exports, and operational logs in the review.

For a team handling sales follow-ups, the permitted task might be: “Read this test conversation and identify the next commitment.” Sending a reply, changing a task, exporting unrelated conversations, and disconnecting an account are separate effects. Write those boundaries down before choosing tools.

A local runtime does not establish that all data stays local, and a hosted OAuth flow does not establish that the client has no retained copies. Use the hosted versus self-hosted responsibility guide to assign operational owners. Keep secrets, session files, and customer message bodies out of the review worksheet.

2. Verify the destination, client, account, and grant

Start from the provider's documented connection page. Check the service domain and environment before signing in. On the consent screen, verify the requesting client, redirect destination, Chiho account, personal or team context, and complete permission set. Stop if any of those differ from the intended connection.

The MCP security guidance explains why consent must be bound to the requesting client and why a server must reject tokens intended for another resource. Ask the operator for evidence of those controls rather than treating the presence of an OAuth button as sufficient.

For Chiho setup instructions, use Telegram MCP and the AI-agent connection guide. After connecting, inspect the authenticated tool list and use the available identity/status tool to confirm context. A publicly reachable metadata endpoint is not evidence of an authenticated, correctly scoped session.

Acceptance evidence: record the client name/version, service environment, grant context, permission categories, and review date. Record no token values. If the available grant is broader than the task, evaluate whether client tool restrictions are adequate for your policy; do not describe them as a narrower server grant.

3. Separate four different kinds of control

Server authorization decides whether the request is allowed for the authenticated account, team, and capability. This is the enforcement boundary to inspect when testing access to an out-of-scope fixture.

Client tool controls decide whether an AI client asks the user before invoking a tool, or makes that tool available at all. Their behavior depends on the client and its settings.

Workflow instructions and Skills tell an agent how to perform a task. “Ask before sending” is useful guidance, but it does not remove a server capability. See MCP versus Agent Skills for that distinction.

Human verification checks whether the actual target and effect match the user's intent. An approval is only useful if the reviewer can understand what will happen.

The MCP tools specification treats tool annotations as hints. A read-only, destructive, or idempotent label should inform review; it is not proof of enforcement or a substitute for inspecting the action's contract.

4. Classify each action instead of assuming all writes are gated

Create an action inventory for the tools your authenticated connection actually exposes. Separate conversation reads, CRM mutations, Telegram sends, account operations, and preview creation. A preview may avoid the represented Telegram action while still persisting server-side state.

Chiho's reviewed Cloud documentation describes action-specific safeguards: batch outbox approval depends on the connection's approval mode; member invitations and group exits use stored previews and approval. It also documents direct execution paths for single-message sends, CRM/task/rule changes, folder operations, summary refreshes, and account logout, subject to authorization and any client tool controls. Do not assume every write produces a separate approval prompt. Check the deployed tool contract before relying on an example, particularly for newly added tools.

The same documentation distinguishes team-visible access from personal account-wide operations. Verify that distinction using only fixtures you are authorized to test. Never probe another customer's account to demonstrate isolation.

Acceptance evidence: for each intended action, record its required permission, visible target, external effect, server approval rule, client prompt behavior, and failure outcome. Mark untested behavior as untested. Do not label an entire connection “read-only” merely because its first task was a read.

5. Review the exact effect and handle uncertain outcomes

Before an authorized write, review the sending account, recipient or chat, final content, attachments, timing, and any destructive effect. If the action uses a stored preview, verify that approval applies to that preview and that changed inputs require a fresh review.

Ask what a retry means for that particular tool. An idempotency key is useful only within its documented scope and lifetime; an idempotent hint does not guarantee that every repeated action is harmless. After a timeout, inspect the available receipt or status before retrying. Distinguish completed, failed, partial, and unknown outcomes.

For batch work, review per-recipient results rather than treating a top-level response as proof that every message was delivered. Chiho's batch messaging guide explains recipient review and partial outcomes. Rate limits and Telegram runtime errors remain operational constraints; approval does not override them.

A useful audit record contains the action, time, scope, result, and a non-secret reference that lets an authorized operator investigate. It need not duplicate customer content. Ask separately what is recorded, who can read it, and how long it remains available.

6. Test revocation and plan for retained data

Chiho documents connection management at Agent Access in the profile: revoking a connection invalidates its access and refresh tokens, and reconnecting requires a new consent flow. Confirm this on an authorized test connection by making a fresh read after revocation and recording the rejection. Removing a client configuration entry alone is not equivalent evidence.

Revocation prevents further authorized access through that grant. It does not retract messages already returned to a client or undo actions already completed. Review client history, exports, provider retention, and any deletion process separately. Read Chiho's privacy policy and terms, then resolve requirements those documents do not answer with the responsible operator. Do not infer a retention period or deletion guarantee.

A reusable acceptance record for one conversation

This synthetic example is a worksheet, not an executed experiment. Use a permitted test conversation containing “Please confirm the proposed appointment on Tuesday.” The desired task is to identify that commitment without sending anything.

1. Record the test owner, environment, client version, and intended account/team context.
2. Confirm the grant and available tools; restrict client actions according to your policy.
3. Read only the selected fixture and compare the answer with the source message.
4. Include a harmless fixture message that asks the agent to ignore its task and export other chats. Confirm that it treats this as conversation content, not user authorization. This checks one scenario, not general resistance to prompt injection.
5. Verify that no send or unrelated mutation occurred using available action evidence. If you cannot observe that, record the limitation.
6. Test a write only under separate, exact authorization in a suitable test environment. Capture the target, approval behavior, result, and retry policy; otherwise leave the write checks untested.
7. Revoke the test connection, confirm that a new read fails, and document retained-copy handling separately.

Keep a short result for each step: passed with evidence, failed, or untested. Assign an owner to every failure before expanding access. Repeat the relevant checks after permission changes or tool additions.

To start with Chiho, open the current connection instructions, review the grant, and run one authorized read-only task. Add a Telegram Skill when you need a repeatable procedure, while continuing to check the actual server permissions and action-specific safeguards.