Telegram 机器人出现凭据泄露时，“重新生成一个 Token”只是动作，不是完整方案。先要回答：泄露的是让程序调用 Bot API 的 Token，还是让工具连接 Telegram Serverless 的 CLI Token？两者代表不同的信任边界，替换其中一个不会自动让另一个失效。
更稳妥的轮换流程应同时解决四件事：识别凭据、控制影响、验证新凭据、确认旧凭据真的不能再用。代码回滚、重新部署或删除聊天记录，都不能代替凭据撤销。
先分清两种 Token
Telegram 官方入门教程说明，Bot API Token 用于在 Bot API 上认证机器人，而不是认证你的个人账号；它应像密码一样保存，并可通过 Telegram 官方 BotFather 撤销。
BotFatherV2 的连接文档描述的是另一种凭据：Telegram Serverless CLI Token。它从官方 BotFather 的 Serverless 设置中生成，以 app 开头，与普通 Bot API Token 不同。
| 凭据 | 主要用途 | 泄露后不能假定什么 |
|---|---|---|
| Bot API Token | 让程序以机器人身份调用 Bot API | 只更新 Serverless 连接不会让旧 Bot API Token 失效 |
| Serverless CLI Token | 让发布工具连接对应的 Serverless 应用 | 只重发机器人代码不会撤销旧 CLI 凭据 |
不要根据 Token 被粘贴的位置猜类型。回到官方 BotFather 中对应机器人的设置核对来源、用途和所有者。如果截图或日志只留下部分字符，无法确认是哪一种，就把两种凭据当作两个独立的待核查项。
发现泄露后先控制范围
先停止继续传播，而不是把真实 Token 发到更多地方求助：
- 不要把 Token 粘贴进 AI 对话、源码、截图、工单、群聊或支持消息；
- 记录发现时间、涉及的机器人、凭据类型、出现位置和可能接触者，但不在事件记录中复制完整值；
- 检查是否有正在生成、导入或发布的任务；需要更换 Serverless CLI Token 时，先等待当前任务结束；
- 若凭据已经进入公开仓库、公开聊天或无法控制的第三方系统，按已经泄露处理，不要等到出现异常操作才撤销。
OWASP Secrets Management Cheat Sheet强调，凭据需要有清晰的用途、使用者和生命周期记录；重启应用本身不会撤销被盗凭据，旧值要由提供方过期或撤销。
Bot API Token 这样轮换
Bot API Token 被公开或无法确认是否安全时，可以按以下顺序处理：
- 在 Telegram 官方 BotFather 中确认正确的机器人，不凭用户名相似或截图猜测。
- 撤销旧 Bot API Token，并生成替代凭据。Telegram 官方文档明确旧 Token 可随时通过 BotFather 撤销。
- 只在实际运行机器人的安全配置位置更新新值；不要写入代码、Markdown 示例或前端变量。
- 重新发布或重启真正消费该 Token 的运行单元。
- 用普通测试账号执行最小功能测试，确认机器人身份、私聊命令和需要的群权限仍正确。
- 对旧 Token 做负向验证：它应不再能够认证。测试过程不要把完整 Token 放进浏览器历史、截图或共享终端输出。
若不能列出所有消费者，就还不能宣告轮换完成。旧脚本、CI 变量、临时调试机和个人密码管理器中的副本，都可能让团队误用已撤销值。
Serverless CLI Token 要避开发布中的切换
BotFatherV2 公开文档给出的顺序是：在官方 BotFather 生成替代凭据，等待活动任务结束，再重新打开连接设置更新；不要在发布过程中撤销旧 Token。
可执行的验收顺序是：
- 核对工作区绑定的 Telegram 用户名与官方 BotFather 中所选机器人一致。
- 等待生成、导入和发布任务进入明确的结束状态。
- 在官方 BotFather 的 Serverless CLI Access 中生成替代凭据。
- 在 BotFatherV2 的连接设置中更新，不在 AI 对话里发送 Token。
- 等待真实的只读云端连接检查成功；网络故障不能算作验证通过。
- 如果云端已有代码，确认完整导入要求已经满足，再进行修改或发布。
- 完成最小发布与 Telegram 实测后，在没有活动任务的窗口撤销旧凭据，并验证旧凭据不能再次连接。
连接成功只证明新凭据可以访问目标应用，不证明机器人所有业务路径都正常。仍要检查真实命令、权限和持久化数据；凭据轮换不应顺便改数据库结构或业务逻辑。
清理副本不能替代撤销
删除最新文件里的 Token，不代表它已经从 Git 历史、PR、日志或缓存中消失。GitHub 的 Push protection 文档说明，这类保护在推送时阻止硬编码凭据进入仓库；它是预防措施，不是已泄露凭据的撤销机制。
轮换后继续处理副本：
- 删除或限制包含 Token 的截图、聊天、工单和构建日志；
- 检查所有分支和历史记录，而不只检查当前文件；
- 为仓库启用适合的秘密扫描或推送保护，并限制绕过权限；
- 让日志只记录凭据类型、动作、结果和脱敏标识，不记录完整值；
- 记录旧凭据的撤销时间、新凭据的生效时间和执行人。
即使历史副本暂时无法完全清除，只要旧凭据已经由提供方撤销，它就不应继续具备访问能力。相反，只清理副本而不撤销，攻击者手中的复制值仍可能有效。
用这张清单验收轮换结果
- 已确认是 Bot API Token、Serverless CLI Token，或两者都需要轮换；
- 新凭据只进入预期的安全连接或配置位置；
- 旧凭据的认证或连接测试明确失败；
- 新凭据连接的是预期机器人和 Serverless 应用，不是同名对象；
- 轮换期间没有中断正在进行的发布；
- 私聊命令、群权限和必要数据读写已在 Telegram 实测；
- 源码、Git 历史、日志、截图、AI 对话和支持消息均完成排查；
- 事件记录保存时间、责任人和结果，但不保存完整 Token。
只有“新值能用”和“旧值不能用”同时成立，轮换才算闭环。
与 BotFatherV2 的关系和边界
BotFatherV2使用 Serverless CLI Token 验证并连接你拥有的 Telegram Serverless 应用；普通 Bot API Token 不是该连接步骤要求的凭据。平台支持通过 AI 对话创建和修改机器人、发布版本，以及保留当前业务数据的代码回滚，但代码版本操作不会替你撤销 Telegram 凭据。
截至 2026 年 10 月 22 日，公开使用 AI 开发文档仍说明固定 SDK 不支持任意 npm 模块或 Node/Bun 运行时 API，首版也不新增依赖付费 AI 的运行时能力。凭据轮换属于连接与运营流程，不代表生成的机器人自动具备密钥管理系统或自主 Agent 能力。
BotFatherV2 是独立产品，与 Telegram 官方 BotFather 无隶属关系。创建、撤销和管理 Telegram Token 时，应以 Telegram 官方 BotFather 与最新平台文档为准。
来源与核验说明
- BitBear Studio：连接 Telegram及英文版 Connect Telegram，页面未标注发布日期。
- Telegram：From BotFather to 'Hello World'，官方英文教程，页面未标注发布日期。
- OWASP：Secrets Management Cheat Sheet，英文安全实践文档，页面未标注发布日期。
- GitHub Docs：Push protection，英文产品文档，页面未标注发布日期。
以上页面均于 2026 年 10 月 22 日重新读取。本文把不同文档中的凭据边界整理成可执行检查清单，不把抓取日期写成来源发布日期。