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

To end one AI client's future access to Telegram through Chiho, revoke its connection in AI Agent Access, then verify a new authenticated request using that same grant is rejected. Revocation does not erase messages already returned, undo completed actions, or sign every Telegram device out.

Chiho supplies authorized existing Telegram account conversations to Codex, Claude, and ChatGPT. A Telegram bot or channel that carries instructions to an agent serves a different purpose; it does not by itself establish access to a personal conversation archive. Account identity, applicable Business permissions, documented tools and actual history coverage decide access. See the architecture guide.

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. Inventory the connection before revoking it

In Chiho, open your profile's AI Agent Access page and locate Connected AI agents. The reviewed interface shows the client name, origin when supplied, personal or team scope, granted permission categories, connection date and last use. Page through additional connections if offered. Similar client names are not proof that two rows represent the same grant.

Privately match the intended client, environment and scope before selecting a row. Keep the MCP resource endpoint in your review record when available: credentials for one resource or environment are not interchangeable with another. Record an opaque test label rather than copying tokens or customer identifiers. A failed connection-list load means the inventory is unknown, not empty.

For example, fictional grants DEMO-REVOKE-A and DEMO-REVOKE-B may both belong to the same AI application. Revoking A is not evidence that B, a separate personal access token, or a self-hosted runtime has stopped. Inventory and handle those credentials separately.

7. Revoke one grant and verify a fresh request

The reviewed interface uses Disconnect, followed by Confirm disconnect. Verify the selected row before confirming. Chiho's source marks that OAuth grant revoked and revokes its stored access tokens, refresh tokens and authorization codes. The documented reconnection path requires a new browser consent flow. This describes the implementation and documentation reviewed on 19 October 2026, not an observed production revocation.

Use this acceptance protocol only with an authorized disposable connection and non-production fixtures:

1. Establish a baseline with auth_status, then account_whoami and one bounded chat_read of an agreed synthetic conversation. Privately retain enough connection context to identify grant A. A transport health check or tool listing alone does not establish account-message access.
2. Revoke grant A in Chiho and record the time, selected scope and operation outcome without credentials. If the operation fails or its result is uncertain, record unverified and inspect the connection state before retrying.
3. Make a fresh authenticated request through that same old grant, with automatic reconnection disabled where the client allows it. Expect an authorization rejection before protected data is returned. A cached answer is not a new read; an empty message result or network timeout is not proof of revocation.
4. Verify that the client cannot silently regain access through that grant's old refresh credentials. Use only an approved test harness that keeps credentials private; if your client cannot expose this check safely, mark refresh behavior untested. Do not paste tokens into a chat, article or support ticket.
5. If access is wanted again, deliberately reconnect through browser consent, inspect the grant, verify identity, and perform a new bounded read. Separate that new grant from the rejected old one in the record.

The OAuth token revocation standard allows a successful revocation response even for an invalid token. Therefore an acknowledgement alone does not prove that a particular formerly working credential now fails. If a fresh protected read still succeeds, stop the exercise and investigate which grant and endpoint were actually used. Use the troubleshooting guide to separate authorization, transport and Telegram connection failures.

8. Keep grant revocation, Telegram logout and deletion separate

Removing an MCP server from a client's configuration is a local configuration change. Verify provider-side revocation separately. Chiho OAuth connections and separately issued personal access tokens have different management entries; ending one does not demonstrate that all credentials are gone.

session_logout is a different, state-changing operation. The reviewed Chiho implementation removes the selected account's stored Telegram session and cleans up its account client; team-scoped grants cannot invoke that path. Do not use it as a read-only revocation check or claim it signs out every Telegram device. It can execute after client controls without a separate Chiho preview approval. Review the exact account and intended effect before requesting it.

Revocation cannot retract messages already supplied to an AI client, erase exports or undo completed sends and CRM changes. Do not assume it cancels an already-running request or previously queued job; inspect each action's available status and cancellation controls separately. Resolve client history, model-provider retention, CRM storage and deletion requirements with their respective operators. Chiho's privacy policy and terms do not establish a universal deletion guarantee across those systems.

9. Record a boundary, not a security certification

For the fictional DEMO-REVOKE exercise, keep: test owner, environment, client version, grant label, account/scope label, resource endpoint, baseline read time, revocation outcome, fresh-request outcome, refresh-check outcome and any intentional new consent. Add a separate retained-copy owner. Use passed with evidence, failed or untested for each step. This article supplies a protocol; no revocation experiment or customer result was produced for it.

A useful result is narrow: “A new protected request through the tested old grant was rejected at the recorded time.” It does not establish resistance to every attack, deletion of returned data, or revocation of other grants.

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.