不安全，也不一定危險；關鍵在連線之外的控制。MCP 標準化 Agent 與資料、工具之間的交換方式，卻不會自動限制資料範圍、移除工具副作用或代替人類核准。安全導入至少要同時守住 host 與 credential、workspace scope、capability、human approval、activity 與 recovery。
「可以連」與「可以做」是兩個問題
一個 MCP server 能列出資料表、接受查詢，代表 transport 與 protocol 能運作；它不代表這條連線只有唯讀權限，也不代表模型選到的工具、參數與資料範圍符合使用者意圖。
MCP 正式規格 將 tool 視為可能通往任意資料存取或程式執行的能力，要求明確的使用者同意、資料保護與工具安全。同一頁也說明，這些原則不能全由 protocol layer 強制；host 與整合實作者必須建立授權、UI 與 access control。
因此，安全檢查的單位不該只是「這個 server 是否可信」，而是完整路徑：
使用者 → Agent host → MCP client → credential → MCP server → 工具／資料 → 結果與副作用
路徑中任何一層範圍過大，都可能讓前一層的同意失去意義。
五層防線：從連線到可回看的證據
第一層：Host 邊界與 credential
先確認 endpoint 暴露在哪裡。只供本機使用的 server 應避免直接綁到公開網路；遠端 server 則需要傳輸加密、身份驗證與清楚的 trust boundary。Token 不應出現在聊天、issue、截圖、一般 activity log 或模型 context 中。
MCP Security Best Practices 特別提醒 token passthrough、token theft、confused deputy 等風險。對採 OAuth 的 HTTP 連線，應檢查 token audience、PKCE、短效 token、refresh rotation 與安全儲存；對本機 bearer credential，至少要能 rotate、revoke、設定 expiry，且只交給預期的本機 client。
驗收問題：
- endpoint 是否只暴露在必要網路範圍？
- token 在哪裡產生、顯示、儲存與遮蔽？
- 能否 expire、rotate、revoke？撤銷後既有 session 如何結束？
第二層：Workspace 與資料 scope
資料最小權限不能只用「唯讀」概括。即使所有工具都只讀，Agent 若能看所有客戶、所有 workspace 或所有 schema，仍然超出任務需求。
把 scope 分成三個問題：
- 來源 scope：只開需要的資料庫、schema、資料夾或物化表。
- 工作 scope：連線固定單一 workspace，還是可跨 workspace 選擇？
- 輸出 scope：結果能回到哪個 client、能否匯出到外部位置？
第一次導入應使用測試資料或單一 workspace。若確實要跨 workspace，要求每次 session 明確選擇，不要暗中沿用上次 context。
第三層：Capability 與 access mode
同一份資料可以配上不同能力：讀 schema、執行 SELECT、建立分析 artifact、匯出結果、修改知識或管理 connection。安全設計要讓能力上限在模型之外被強制，而不是只寫一句「請勿修改」。
可用三級思考：
| 等級 | 能力 | 適合情境 |
|---|---|---|
| Observe | 只讀環境與 artifacts | 盤點、低信任試用、陪同審閱 |
| Execute | 建立分析 artifacts，依正式流程執行 | 單一 workspace 的受控分析 |
| Admin | Execute 加上高信任設定與組織操作 | 已驗證 Agent、明確授權的管理工作 |
這裡的核心是「能力上限」：Agent 不能靠 prompt、Plan 狀態或自我判斷提升權限。OWASP Excessive Agency 也建議以最少 extensions、最少功能與最少權限降低 Agent 因誤判或被操縱而造成的損害。
第四層：Human approval 與正式 evidence
Human-in-the-loop 不是每個 SELECT 都彈出按鈕。過多、含糊的確認會讓人機械式點擊；過少則讓高影響操作直接發生。應按風險設計核准點：
- 低風險 schema 探索可在既定 scope 內進行。
- 會進報告的正式取數，先核准 Plan 的問題、分母、時間窗與 checkpoints。
- 管理設定、對外匯出或不可逆操作，使用獨立且顯示目的地／參數的確認。
核准也不能只剩一句「允許 Agent 繼續」。審閱者要看得到即將執行的範圍，執行後則要能把關鍵數字連回 SQL 或其他 evidence。Plan approval 是任務授權，不是 connection 權限提升。
第五層：Activity、audit 與 recovery
日誌若只有「Agent 已完成」，無法調查錯誤。最低可觀測性應包含：哪個 connection、在哪個 workspace、何時呼叫哪個工具、政策或核准結果、影響哪些 artifacts，以及是否成功。
但 audit 也不能變成資料外洩副本。Credential、敏感正文與完整結果需要遮蔽或分開保存。Recovery 則要區分：
- 純文字 artifact 修改可在內容 hash 未衝突時安全回退。
- 查詢、匯出、權限或 lifecycle 等有副作用事件，不能假裝用「Undo」就全部還原。
- 發現異常時要能終止 session、unexpose endpoint 或 revoke credential。
用一張表做上線前 threat review
| 檢查面 | 最低要求 | 常見誤區 |
|---|---|---|
| Host | endpoint 範圍明確 | 本機測試 server 意外公開 |
| Credential | expiry、rotate、revoke、遮蔽 | token 貼進 prompt 或 issue |
| Scope | 單一任務所需資料 | 唯讀就開放所有 workspace |
| Capability | 模型外強制最小能力 | 用 system prompt 代替權限 |
| Approval | 高風險動作有清楚核准內容 | 每次都按「Allow」但看不到參數 |
| Evidence | 正式結果可追溯 | 只保存 Agent 摘要 |
| Audit | 工具、政策、artifact 有紀錄 | 把完整敏感資料寫進 log |
| Recovery | 終止、撤銷、有限回退 | 宣稱所有副作用都可 Undo |
只要其中一列沒有 owner，就先不要接正式資料。這張表也應在 server、client 或資料 scope 變更後重跑，而不是只在採購時檢查一次。
Lantide Data 如何實作這些邊界
Lantide Data 作為本機 MCP Server 時只綁定 127.0.0.1。Quick connection 的 credential 在 Expose 時產生，離開畫面後不再顯示；若遺失，需 Unexpose 後重新 Expose 取得新設定。Persistent connection 則提供 expiry、Expose／Unexpose、Rotate 與 Revoke。連線可限制為單一 workspace；access mode 是 Observe／Execute／Admin 的硬性能力上限。
在 Execute 流程中，外部 Agent 建立或修訂 Plan，使用者在 GUI 按 Approve & Execute 後，Agent 才取得該 Plan 的正式執行範圍。這個核准不會把 Observe 升成 Execute，也不會把 Execute 升成 Admin。External MCP Activity 則記錄工具、policy／review 結果與 artifact 變更；支援的內容回退會先比對 after hash，若後續已有修改就阻擋，不強制覆蓋。詳細限制見 外部 Agent 整合指南 與 USER_GUIDE §13。
邊界同樣重要：Lantide 的 server 是本機分析工作面，不是遠端多人共享 API；Admin 仍是高信任模式，不能因有 Activity 就隨意開放。連線、recovery 與 client compatibility 需依實際版本驗證。若連接外部模型、MCP server 或資料庫，對方的資料處理與 credential 政策仍需另外審查。
結語：先用 Observe 證明必要性，再增加能力
第一次接 MCP，不妨從單一 workspace、測試資料、短效 credential 與 Observe 開始。確認 Agent 真正需要哪些 tools、審閱者看得懂哪些 approval、audit 能否還原事件後，再升到 Execute。最小權限不是一次選完的設定，而是一條「先證明需要，再逐步開放」的營運流程。