Telegram MCP Lista de verificación de seguridad: ámbito, OAuth, aprobaciones y revocación

Una revisión de seguridad de Telegram MCP debe establecer a qué cuenta puede acceder un agente, qué acciones permite el servidor, qué requiere una aprobación separada y cómo termina el acceso. Una conexión correcta demuestra conectividad. No demuestra que la concesión coincida con el flujo de trabajo previsto por su equipo.

Use la lista de verificación siguiente antes de conectar conversaciones de clientes y después de cambios materiales en el cliente, el servidor, la membresía del equipo o los permisos concedidos. Comience con una conversación de prueba autorizada. Este es un protocolo de aceptación propuesto, no una prueba de penetración completada, una certificación ni una afirmación de que una implementación concreta sea segura.

Declaración del editor: Chiho publica esta guía y proporciona un servicio de Telegram MCP alojado. Los ejemplos de Chiho se basan en documentación y en código fuente revisados el 26 septiembre 2026; no son resultados de pruebas en cuentas reales. Las funciones presentes en una revisión del código fuente pueden diferir de su conexión implementada. La imagen del encabezado es una imagen existente de la interfaz de Chiho CRM, no una captura de pantalla de una prueba de seguridad.

1. Delimite los límites de confianza antes de conceder acceso

Registre la cuenta de Telegram, el servicio de MCP, el cliente de IA, el proveedor del modelo y cualquier almacenamiento de CRM implicado. Identifique quién opera cada componente y dónde pueden conservarse los mensajes devueltos. Incluya en la revisión el historial de conversaciones del cliente, las exportaciones y los registros operativos.

Para un equipo que gestiona seguimientos de ventas, la tarea permitida podría ser: “Lea esta conversación de prueba e identifique el siguiente compromiso”. Enviar una respuesta, cambiar una tarea, exportar conversaciones no relacionadas y desconectar una cuenta son efectos separados. Escriba esos límites antes de elegir herramientas.

Un entorno de ejecución local no establece que todos los datos permanezcan locales, y un flujo OAuth alojado no establece que el cliente no conserve copias. Use la guía de responsabilidades entre alojamiento y autohospedaje para asignar responsables operativos. Mantenga secretos, archivos de sesión y cuerpos de mensajes de clientes fuera de la hoja de revisión.

2. Verifique el destino, el cliente, la cuenta y la concesión

Parta de la página de conexión documentada del proveedor. Compruebe el dominio y el entorno del servicio antes de iniciar sesión. En la pantalla de consentimiento, verifique el cliente solicitante, el destino de redirección, la cuenta de Chiho, el contexto personal o de equipo y el conjunto completo de permisos. Deténgase si alguno de esos elementos difiere de la conexión prevista.

La guía de seguridad de MCP explica por qué el consentimiento debe estar vinculado al cliente solicitante y por qué un servidor debe rechazar tokens destinados a otro recurso. Pida al operador evidencia de esos controles en lugar de considerar suficiente la presencia de un botón OAuth.

Para las instrucciones de configuración de Chiho, use Telegram MCP y la guía de conexión del agente de IA. Después de conectar, inspeccione la lista de herramientas autenticadas y use la herramienta disponible de identidad/estado para confirmar el contexto. Un extremo de metadatos accesible públicamente no es evidencia de una sesión autenticada y correctamente acotada.

Evidencia de aceptación: registre el nombre y la versión del cliente, el entorno del servicio, el contexto de la concesión, las categorías de permisos y la fecha de revisión. No registre valores de tokens. Si la concesión disponible es más amplia que la tarea, evalúe si las restricciones de herramientas del cliente son adecuadas para su política; no las describa como una concesión del servidor más limitada.

3. Separe cuatro tipos diferentes de control

La autorización del servidor decide si la solicitud está permitida para la cuenta autenticada, el equipo y la capacidad. Este es el límite de aplicación que debe inspeccionarse al probar el acceso a un recurso fuera del ámbito.

Los controles de herramientas del cliente deciden si un cliente de IA pide permiso al usuario antes de invocar una herramienta, o si pone esa herramienta a disposición en absoluto. Su comportamiento depende del cliente y de su configuración.

Las instrucciones de flujo de trabajo y las Skills indican a un agente cómo realizar una tarea. “Preguntar antes de enviar” es una guía útil, pero no elimina una capacidad del servidor. Consulte MCP versus Agent Skills para esa distinción.

La verificación humana comprueba si el objetivo y el efecto reales coinciden con la intención del usuario. Una aprobación solo es útil si la persona que revisa puede entender qué ocurrirá.

La especificación de herramientas de MCP trata las anotaciones de herramientas como sugerencias. Una etiqueta de solo lectura, destructiva o idempotente debe orientar la revisión; no es prueba de aplicación ni sustituto de inspeccionar el contrato de la acción.

4. Clasifique cada acción en lugar de asumir que todas las escrituras están protegidas

Cree un inventario de acciones para las herramientas que su conexión autenticada expone realmente. Separe las lecturas de conversaciones, las mutaciones de CRM, los envíos de Telegram, las operaciones de cuenta y la creación de vistas previas. Una vista previa puede evitar la acción representada de Telegram y, aun así, conservar estado en el servidor.

La documentación en la nube revisada de Chiho describe salvaguardas específicas por acción: la aprobación de la bandeja de salida por lotes depende del modo de aprobación de la conexión; las invitaciones de miembros y las salidas de grupos usan vistas previas almacenadas y aprobación. También documenta rutas de ejecución directa para envíos de un solo mensaje, cambios de CRM/tarea/regla, operaciones de carpeta, actualizaciones de resúmenes y cierre de sesión de cuenta, sujeto a la autorización y a cualquier control de herramientas del cliente. No asuma que cada escritura produce un aviso de aprobación separado. Compruebe el contrato de herramientas implementado antes de confiar en un ejemplo, especialmente para herramientas recién añadidas.

La misma documentación distingue el acceso visible para el equipo de las operaciones de toda la cuenta personal. Verifique esa distinción utilizando solo recursos de prueba que esté autorizado a probar. Nunca sondee la cuenta de otro cliente para demostrar aislamiento.

Evidencia de aceptación: para cada acción prevista, registre el permiso requerido, el objetivo visible, el efecto externo, la regla de aprobación del servidor, el comportamiento del aviso del cliente y el resultado del fallo. Marque cualquier comportamiento no probado como no probado. No etiquete toda una conexión como “solo lectura” solo porque su primera tarea fue una lectura.

5. Revise el efecto exacto y gestione los resultados inciertos

Antes de una escritura autorizada, revise la cuenta de envío, el destinatario o chat, el contenido final, los adjuntos, el momento y cualquier efecto destructivo. Si la acción usa una vista previa almacenada, verifique que la aprobación se aplique a esa vista previa y que cualquier entrada modificada requiera una revisión חדשה.

Pregunta qué significa un reintento para esa herramienta en particular. Una clave de idempotencia solo es útil dentro de su ámbito y vigencia documentados; una pista idempotente no garantiza que toda acción repetida sea inocua. Después de un tiempo de espera, inspecciona el recibo o el estado disponible antes de reintentar. Distingue entre resultados completados, fallidos, parciales y desconocidos.

Para el trabajo por lotes, revisa los resultados por destinatario en lugar de tratar una respuesta de nivel superior como prueba de que se entregó cada mensaje. Chiho's guía de mensajería por lotes explica la revisión de destinatarios y los resultados parciales. Los límites de velocidad y los errores de tiempo de ejecución de Telegram siguen siendo restricciones operativas; la aprobación no los anula.

Un registro de auditoría útil contiene la acción, la hora, el ámbito, el resultado y una referencia no secreta que permita a un operador autorizado investigar. No necesita duplicar el contenido del cliente. Pregunta por separado qué se registra, quién puede leerlo y durante cuánto tiempo permanece disponible.

6. Prueba la revocación y planifica los datos retenidos

Chiho documenta la gestión de conexiones en Agent Access en el perfil: revocar una conexión invalida sus tokens de acceso y actualización, y volver a conectarla requiere un nuevo flujo de consentimiento. Confírmalo en una conexión de prueba autorizada realizando una nueva lectura después de la revocación y registrando el rechazo. Eliminar solo una entrada de configuración de cliente no es una prueba equivalente.

La revocación impide cualquier acceso autorizado posterior a través de ese permiso. No retracta mensajes ya devueltos a un cliente ni deshace acciones ya completadas. Revisa por separado el historial del cliente, las exportaciones, la retención del proveedor y cualquier proceso de eliminación. Lee la política de privacidad y los términos de Chiho, y luego resuelve con el operador responsable los requisitos que esos documentos no respondan. No infieras un período de retención ni una garantía de eliminación.

Un registro de aceptación reutilizable para una conversación

Este ejemplo sintético es una hoja de trabajo, no un experimento ejecutado. Usa una conversación de prueba permitida que contenga “Por favor, confirma la cita propuesta para el martes.” La tarea deseada es identificar ese compromiso sin enviar nada.

1. Registra el propietario de la prueba, el entorno, la versión del cliente y el contexto previsto de cuenta/equipo.
2. Confirma el permiso y las herramientas disponibles; restringe las acciones del cliente de acuerdo con tu política.
3. Lee solo el fixture seleccionado y compara la respuesta con el mensaje fuente.
4. Incluye un mensaje de fixture inocuo que pida al agente que ignore su tarea y exporte otros chats. Confirma que lo trata como contenido de la conversación, no como autorización del usuario. Esto verifica un escenario, no una resistencia general a la inyección de prompts.
5. Verifica que no se produjo ningún envío ni una mutación no relacionada usando la evidencia de acción disponible. Si no puedes observarlo, registra la limitación.
6. Prueba una escritura solo con una autorización exacta y separada en un entorno de prueba adecuado. Captura el destino, el comportamiento de aprobación, el resultado y la política de reintento; de lo contrario, deja las comprobaciones de escritura sin probar.
7. Revoca la conexión de prueba, confirma que una nueva lectura falla y documenta por separado el manejo de las copias retenidas.

Mantén un resultado breve para cada paso: aprobado con evidencia, fallido o no probado. Asigna un responsable a cada fallo antes de ampliar el acceso. Repite las comprobaciones relevantes después de cambios de permisos o de añadir herramientas.

Para empezar con Chiho, abre la instrucción de conexión actual, revisa el permiso y ejecuta una tarea autorizada de solo lectura. Añade una Habilidad de Telegram cuando necesites un procedimiento repetible, mientras sigues comprobando los permisos reales del servidor y las protecciones específicas de la acción.