Lista de segurança do MCP do Telegram: escopo, OAuth, aprovações e revogação

Uma revisão de segurança do MCP do Telegram deve estabelecer qual conta um agente pode acessar, quais ações o servidor permite, o que exige aprovação separada e como o acesso termina. Uma conexão bem-sucedida comprova conectividade. Ela não comprova que a autorização corresponde ao fluxo pretendido pela equipe.

Use a lista abaixo antes de conectar conversas de clientes e após alterações relevantes no cliente, servidor, membros da equipe ou permissões autorizadas. Comece com uma conversa de teste autorizada. Este é um protocolo de aceitação proposto, não um teste de invasão concluído, uma certificação nem uma afirmação de que uma implantação específica é segura.

Declaração do editor: o Chiho publica este guia e oferece um serviço hospedado de MCP do Telegram. Os exemplos do Chiho baseiam-se na documentação e no código-fonte revisados em 26 de setembro de 2026; não são resultados de testes em contas ao vivo. Os recursos de uma revisão do código podem diferir da sua conexão implantada. A imagem de cabeçalho é uma imagem existente da interface do CRM do Chiho, não uma captura de teste de segurança.

1. Desenhe os limites de confiança antes de conceder acesso

Registre a conta do Telegram, o serviço MCP, o cliente de IA, o fornecedor de modelo e qualquer armazenamento de CRM envolvido. Identifique quem opera cada componente e onde mensagens retornadas podem ser retidas. Inclua na revisão o histórico de conversas do cliente, exportações e logs operacionais.

Para uma equipe que cuida de acompanhamentos de vendas, a tarefa permitida pode ser: “Leia esta conversa de teste e identifique o próximo compromisso.” Enviar uma resposta, alterar uma tarefa, exportar conversas não relacionadas e desconectar uma conta são efeitos separados. Anote esses limites antes de escolher ferramentas.

Um ambiente local não comprova que todos os dados permanecem locais, e um fluxo OAuth hospedado não comprova que o cliente não retém cópias. Use o guia de responsabilidades de hospedado versus auto-hospedado para designar responsáveis operacionais. Mantenha segredos, arquivos de sessão e corpos de mensagens de clientes fora da planilha de revisão.

2. Verifique destino, cliente, conta e autorização

Comece pela página de conexão documentada do fornecedor. Confira o domínio e o ambiente do serviço antes de entrar. Na tela de consentimento, verifique o cliente solicitante, o destino de redirecionamento, a conta do Chiho, o contexto pessoal ou de equipe e o conjunto completo de permissões. Pare se algum deles diferir da conexão pretendida.

As orientações de segurança do MCP explicam por que o consentimento deve estar vinculado ao cliente solicitante e por que um servidor deve rejeitar tokens destinados a outro recurso. Peça ao operador evidências desses controles em vez de considerar suficiente a presença de um botão OAuth.

Para instruções de configuração do Chiho, use MCP do Telegram e o guia de conexão de agentes de IA. Após conectar, confira a lista autenticada de ferramentas e use a ferramenta disponível de identidade ou status para confirmar o contexto. Um endpoint público de metadados acessível não comprova uma sessão autenticada com escopo correto.

Evidências de aceitação: registre nome e versão do cliente, ambiente do serviço, contexto da autorização, categorias de permissão e data da revisão. Não registre valores de tokens. Se a autorização disponível for mais ampla que a tarefa, avalie se as restrições de ferramentas do cliente são adequadas à sua política; não as descreva como uma autorização mais restrita do servidor.

3. Separe quatro tipos diferentes de controle

A autorização do servidor decide se o pedido é permitido para a conta, equipe e capacidade autenticadas. Esse é o limite de aplicação a inspecionar ao testar acesso a dados de teste fora do escopo.

Os controles de ferramentas do cliente decidem se um cliente de IA pergunta ao usuário antes de invocar uma ferramenta ou se a disponibiliza. Seu comportamento depende do cliente e de suas configurações.

Instruções de fluxo de trabalho e Skills orientam um agente sobre como realizar uma tarefa. “Pergunte antes de enviar” é uma orientação útil, mas não remove uma capacidade do servidor. Veja MCP versus Agent Skills para essa distinção.

A verificação humana confere se o alvo e o efeito reais correspondem à intenção do usuário. Uma aprovação só é útil se o revisor consegue entender o que acontecerá.

A especificação de ferramentas do MCP trata anotações de ferramentas como indicações. Um rótulo de somente leitura, destrutivo ou idempotente deve orientar a revisão; ele não comprova aplicação nem substitui a inspeção do contrato da ação.

4. Classifique cada ação em vez de presumir que toda gravação tem aprovação

Crie um inventário de ações para as ferramentas que sua conexão autenticada realmente expõe. Separe leituras de conversas, alterações do CRM, envios do Telegram, operações de conta e criação de prévias. Uma prévia pode evitar a ação representada do Telegram e ainda persistir estado no servidor.

A documentação Cloud revisada do Chiho descreve proteções específicas por ação: a aprovação de lotes da caixa de saída depende do modo de aprovação da conexão; convites de membros e saídas de grupos usam prévias armazenadas e aprovação. Ela também documenta caminhos de execução direta para envios de mensagens individuais, alterações de CRM, tarefas e regras, operações de pastas, atualizações de resumos e logout da conta, sujeitos à autorização e aos controles de ferramentas do cliente. Não presuma que toda gravação gera um pedido separado de aprovação. Confira o contrato da ferramenta implantada antes de confiar em um exemplo, especialmente para ferramentas recém-adicionadas.

A mesma documentação diferencia acesso visível para equipe de operações pessoais em toda a conta. Verifique essa distinção usando apenas dados de teste que você tenha autorização para testar. Nunca explore a conta de outro cliente para demonstrar isolamento.

Evidências de aceitação: para cada ação pretendida, registre a permissão necessária, o alvo visível, o efeito externo, a regra de aprovação do servidor, o comportamento de confirmação do cliente e o resultado de falha. Marque comportamentos não testados como não testados. Não rotule uma conexão inteira como “somente leitura” apenas porque sua primeira tarefa foi uma leitura.

5. Revise o efeito exato e trate resultados incertos

Antes de uma gravação autorizada, revise a conta de envio, o destinatário ou chat, o conteúdo final, os anexos, o horário e qualquer efeito destrutivo. Se a ação usar uma prévia armazenada, verifique que a aprovação se aplica a essa prévia e que entradas alteradas exigem nova revisão.

Pergunte o que “retry” significa para aquela ferramenta específica. Uma chave de idempotência é útil apenas dentro de seu escopo e tempo de validade documentados; um indício de idempotência não garante que toda ação repetida seja inofensiva. Após um timeout, inspecione o comprovante ou status disponível antes de tentar novamente. Diferencie resultados concluídos, com falha, parciais e desconhecidos.

Para trabalhos em lote, revise os resultados por destinatário em vez de tratar uma resposta de nível superior como prova de que todas as mensagens foram entregues. O guia de mensagens em lote de Chiho batch messaging guide explica a revisão por destinatário e resultados parciais. Limites de taxa e erros em tempo de execução de Telegram continuam sendo restrições operacionais; a aprovação não os sobrepõe.

Um registro de auditoria útil contém a ação, o horário, o escopo, o resultado e uma referência não sigilosa que permita a um operador autorizado investigar. Ele não precisa duplicar o conteúdo do cliente. Pergunte separadamente o que é registrado, quem pode ler e por quanto tempo permanece disponível.

6. Teste revogação e planeje dados retidos

Chiho documenta o gerenciamento de conexões no Agent Access no perfil: revogar uma conexão invalida seus tokens de acesso e atualização, e reconectar exige um novo fluxo de consentimento. Confirme isso em uma conexão de teste autorizada fazendo uma nova leitura após a revogação e registrando a rejeição. Remover apenas uma entrada de configuração de cliente não é evidência equivalente.

A revogação impede novo acesso autorizado por meio daquela concessão. Ela não retira mensagens já retornadas a um cliente nem desfaz ações já concluídas. Revise separadamente o histórico do cliente, exportações, retenção do provedor e qualquer processo de exclusão. Leia a política de privacidade e os termos de Chiho, depois resolva com o operador responsável os requisitos que esses documentos não respondem. Não infira um período de retenção nem uma garantia de exclusão.

Um registro de aceitação reutilizável para uma conversa

Este exemplo sintético é uma planilha de trabalho, não um experimento executado. Use uma conversa de teste permitida contendo “Please confirm the proposed appointment on Tuesday.” A tarefa desejada é identificar esse compromisso sem enviar nada.

1. Registre o proprietário do teste, o ambiente, a versão do cliente e o contexto de conta/equipe pretendido.
2. Confirme a concessão e as ferramentas disponíveis; restrinja as ações do cliente de acordo com sua política.
3. Leia apenas o fixture selecionado e compare a resposta com a mensagem de origem.
4. Inclua uma mensagem fixture inofensiva que peça ao agente para ignorar sua tarefa e exportar outras conversas. Confirme que ele trata isso como conteúdo da conversa, não como autorização do usuário. Isso verifica um cenário, não a resistência geral a prompt injection.
5. Verifique se não ocorreu envio nem mutação não relacionada usando as evidências de ação disponíveis. Se você não puder observar isso, registre a limitação.
6. Teste uma gravação apenas sob autorização separada e exata em um ambiente de teste adequado. Capture o destino, o comportamento da aprovação, o resultado e a política de retry; caso contrário, deixe as verificações de escrita sem teste.
7. Revogue a conexão de teste, confirme que uma nova leitura falha e documente separadamente o tratamento da cópia retida.

Mantenha um resultado curto para cada etapa: aprovado com evidência, reprovado ou não testado. Atribua um responsável a cada falha antes de ampliar o acesso. Repita as verificações relevantes após mudanças de permissão ou adição de ferramentas.

Para começar com Chiho, abra a instruções atuais de conexão, revise a concessão e execute uma tarefa autorizada de leitura apenas. Adicione uma Skill de Telegram quando precisar de um procedimento repetível, enquanto continua verificando as permissões reais do servidor e as proteções específicas da ação.