外部 AI Agent 接觸公司資料前，平台團隊不能只準備一組連線字串；至少要先定義資料來源範圍、可用能力、workspace 隔離、credential 生命週期、正式 evidence、並行寫入規則、audit 與復原。MCP 解決「如何連線與呼叫」，不會自動替組織完成最小權限與成果驗收。
1. 先畫資料範圍，不先列所有工具
從一個具體任務反推最小資料面：哪個 workspace、哪些檔案或 database schema、是否含個資、資料新鮮度要求，以及輸出可存到哪裡。
不應用「Agent 可能以後會需要」為理由一次暴露整個資料環境。MCP 官方安全指南建議縮小 scope、以最小預設權限執行，並限制檔案系統、網路與其他資源存取。MCP Security Best Practices
可交付的 scope 卡應寫成：
任務：分析 2026 Q2 onboarding 漏斗
Workspace：growth-q2（單一）
來源：events、accounts；不含 support_notes
動作：讀取、建立分析 artifacts、正式唯讀查詢
輸出：Lantide Report；本機匯出需人工確認
到期：試點結束即撤銷
2. 把「看、分析、管理」拆成不同能力
不要只有「有權／無權」。至少分三層：
| 能力層 | 可以做什麼 | 典型用途 |
|---|---|---|
| Observe | 看 schema、artifacts 與既有結果 | 第一次評估、陪同 review |
| Execute | 建立分析 artifact，依核准範圍跑正式查詢 | 單一工作區的正式分析 |
| Admin | 再加工作區、知識、別名與本機交付管理 | 高信任環境維護 |
能力上限和分析階段是兩回事：批准某份 Plan，不應讓原本唯讀連線突然取得管理能力；反過來，Admin connection 也不代表任何分析結論已通過業務審閱。
3. Credential 要能發、能收、能過期
平台團隊至少要回答：credential 誰建立、存在哪裡、何時到期、如何 rotate／revoke，以及事件與 log 是否會遮蔽 token。MCP 2025-11-25 authorization 規格要求 HTTP 授權使用 Protected Resource Metadata，並把 token 綁定目標 resource；官方安全文件也明確反對 token passthrough。MCP Authorization Specification
本機整合仍需防止同機惡意程序存取。若是 loopback HTTP，應使用 bearer credential 或等效限制；不要把本機 config 貼進 issue、聊天室或 wiki。短期試點應設 expiry，並實際演練 Rotate 或 Revoke，而不是只在文件上寫「可撤銷」。
4. 正式數字要有 evidence contract
Agent 在聊天裡說「完成」不等於成果存在。先約定正式分析至少留下：
- 經人審閱的 Plan 與執行範圍；
- 關鍵 SQL／查詢步驟；
- 數字與 evidence 的對應；
- Report 的資料時點與 limitations；
- 執行與修改活動。
探索查詢可以存在，但不可悄悄成為對外 Report 的關鍵數字。若執行後補查資料，也要標示為 post-execution evidence，避免把計畫外結果混入原本已核准的結論。
5. 先決定 writer ownership，避免兩個 Agent 同時改
外部 Agent、內建 Agent 與人可能同時打開同一 workspace。平台要先定義：誰能持有 writer、第二個 writer 進入時是阻擋、排隊還是明確 eviction，以及衝突時能否 force overwrite。
安全預設應是 fail closed：看得見阻擋者、取得使用者同意後才切換 ownership。內容回退也應檢查目前版本是否仍等於當時的 after state；若後續有人修改，就阻擋 revert，而不是覆蓋新工作。
6. Audit 要能回答「發生什麼」，不應變成秘密倉庫
Activity 與 audit 至少要辨識 session、工具／操作、artifact、時間、結果與受影響範圍。但不要把完整聊天、token 或敏感正文無限制抄進 log。另需定義：active 與 ended session 如何辨別、保留多久、清除 Activity 是否會影響 business audit 與 artifacts。
NIST AI RMF 是自願性框架，強調把可信度考量納入 AI 系統的設計、使用與評估生命週期；平台團隊可用它檢查責任、衡量與治理是否落到實際控制，而不只停在政策文字。NIST AI RMF
7. 復原不只等於 Undo
把動作分成兩類：
- 可安全回退的內容修改：在無衝突時回復 Plan、Report 或 SQL 內容。
- 具副作用操作：連線、權限、Plan lifecycle、export、knowledge governance 等，通常需要各自補償或人工處理，不能假設一顆 Undo 全部復原。
試點前演練三件事：Agent 中斷後 session 是否失效、credential revoke 後舊 client 是否 fail closed、writer conflict 是否會阻擋而非靜默搶占。
Lantide Data 作為本機 Agent 工作面
Lantide Data 的 Agent Integration 是本機 loopback MCP Server，讓 Codex、Claude、Cursor 等支援 MCP 的外部 Agent 進入分析工作面。它提供 Quick／Persistent connection、Single／All workspaces scope，以及 Observe／Execute／Admin access mode；正式分析可在 GUI 審 Plan、按 Approve & Execute，並回看 artifacts、evidence、External MCP Activity、Save History 與 audit。完整操作見 外部 Agent Integration 指南。
這種設計的優點，是外部 Agent 可沿用既有介面，同時把 SQL-first 分析成果沉澱到 Lantide，而不是只留在外部聊天。但它有清楚邊界：本機 loopback host 不是遠端共享 API；Plan 核准不會提高 connection 的能力上限；Lantide 也不是企業 IAM、DLP 或跨公司 metadata 平台的替代品。
導入前最小檢查表
- 單一任務與資料範圍已寫清楚
- 第一次評估從 Observe 或 Single workspace + Execute 開始
- Credential 有 owner、expiry、Rotate／Revoke 流程
- 正式數字必須連回 Plan、SQL evidence 與 Report
- Writer conflict 不會靜默覆蓋
- Activity 遮蔽秘密，audit 保留規則已定義
- 中斷、撤銷與復原演練已完成
結語
先讓一個低風險、會被追問的分析走完整流程，驗收的不只是答案，而是 scope、evidence、衝突、audit 與撤銷是否真的可用。外部 Agent 能否安全採用，取決於它被放進什麼工作環境，而不只取決於模型是哪一個。