外部 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 能否安全采用，取决于它被放进什么工作环境，而不只取决于模型是哪一个。