不安全，也不一定危险；关键在连线之外的控制。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。最小权限不是一次选完的设定，而是一条「先证明需要，再逐步开放」的营运流程。