# cf telegram bot 改善項目 20260807 我這輪只讀檢查後，最需要先處理的是： 1. **憑證外洩風險** - `src/features/network.js:20` 有硬編碼第三方 API token。 - `src/features/voice.js:22` 會把 ASR、Groq、OpenAI key 的完整值與前後綴寫入 Worker logs。 - `wrangler.toml` 雖被忽略、不進 Git，但其中多數 key 以一般 vars 部署，不是 Cloudflare Secret；範本與 README 也有疑似真實憑證。 建議：先輪替這批 key，移至 wrangler secret，並移除 key debug log。 這是 P0。 2. **公開的管理入口** - `src/index.js:213` 現在雖然保留「人按 Submit 才更新」流程，但任何人都能 POST 表單，因為沒有驗證。 - `src/index.js:337` 程式自己也註明尚未做 authentication；外人可藉此消耗你的模型額度。 不必改掉 /init 的 UI 流程。加 Cloudflare Access，或加一個只有你知道的 `INIT_SECRET` 驗證即可。 3. **LLM 目前可以直接觸發寫入型工具** - `src/agent/llm.js:175` 解析模型回覆中的 `[CALL:...]` 後，能直接新增 Google Calendar、寫入記帳或委派 A2A。這是 prompt injection 的高風險面，尤其 `/soul ` 可載入外部內容。 建議改為：模型只能「提出工具呼叫」→ Telegram 顯示確認按鈕 → 人按下後，後端再次檢查權限與參數 schema 才執行。 架構上，現在的 LLM Profile 已是正確方向，但下一步應把舊 `AI_PROVIDER`、獨立 `model/base` 設定逐步遷移為純相容層；四個環境裡重複的 `LLM_PROFILES` 則應由單一設定來源產生，避免模型清單漂移。測試目前只有 16 項，對約 13k 行程式來說偏少，至少要補 webhook 驗證、/init 授權、A2A 驗證、工具確認與 profile migration。 至於 sandbox：純 Worker 本身不能提供給模型任意 shell、Linux process 或持久檔案系統，所以「只靠目前這個 Worker」不適合安全執行 LLM 產生的程式。但 Cloudflare 現在有 Sandbox SDK：Worker 作協調，背後以 Containers + Durable Objects 提供隔離 Linux sandbox，可執行 Python/Node、管理檔案與程序；它是付費方案，部署時也要有 Docker。這不是把現有 Telegram Worker 硬塞一個 eval，而是新增一個受控工具層。 [Cloudflare Sandbox SDK](https://developers.cloudflare.com/sandbox/) 我會建議未來採這個形狀： ``` Telegram Worker → LLM 判斷是否需要「執行程式」 → 人類確認 → Sandbox Worker / Container → 僅回傳 stdout、檔案或圖片 ``` Sandbox 用「每次任務一個短生命週期」較安全；若要長工作階段，才以 chat/user ID 對應 sandbox，並把真正需保留的檔案放 R2。Sandbox 閒置預設會休眠，容器記憶體狀態不該當資料庫。 [Sandbox lifecycle](https://developers.cloudflare.com/sandbox/concepts/sandboxes/)