spec v0.1
ZH

安全

安全模型

六个授权层、发现过滤、人在回路、升级身份验证、同意账本和审计轨迹——MCP-first 系统的完整安全模型。

支持智能体不意味着失去控制。MCP-first 系统以机器可读的方式描述每项能力—— 同时规定谁可以调用它、在什么条件下调用，以及会留下什么痕迹。 安全不是事后添加的功能，而是能力设计的一部分。

如果智能体可以调用它，Policy 就必须能够控制它。

基本原则

六个授权层

身份验证回答：你是谁？ 授权回答：你能做什么？ MCP-first 系统需要两个问题——并在六个独立层次上回答， 这些层次共同决定有效访问权限。

第一层：用户角色（User Role）

已登录用户的角色构成最宽泛的层次。它决定基本访问类别， 而非具体工具。

admin
manager
employee
viewer
external_client

第二层：租户范围（Tenant Scope）

在多租户系统中，每次访问必须绑定到租户。即使用户角色 在技术上允许，智能体也不得跨租户读写。

tenant:abc
project:123
contact:456

第三层：工具范围（Tool Scope）

每个工具都有自己的 Scope 保护。智能体只获得其定义任务 所必需的 Scope。

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

第四层：资源范围（Resource Scope）

除工具 Scope 外，还可以对单个资源类型的访问进行限制。 这确保拥有 contacts:read 的智能体仍然无法查看每个联系人资源。

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

第五层：风险等级（Risk Level）

每个工具都标注了声明的风险等级。该等级影响确认策略和审计配置。

等级含义
Low 自主执行通常无害
Medium 在范围和上下文明确时可自主执行
High 建议确认
Critical 始终需要确认，通常需要升级身份验证
Forbidden for AI 不允许 AI 访问

第六层：确认策略（Confirmation Policy）

确认策略规定执行前需要满足哪些额外条件。它按工具配置， 由 Policy 层强制执行——而非由智能体自行决定。

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

工具可见性

工具是否存在本身就是一条安全相关信息。知道某个被禁止的工具的智能体 可以将其作为攻击面——即使后续调用会被拦截。

例如，销售助理会收到以下经过过滤的工具列表：

销售助理可见的工具
  • contacts.search
  • projects.list
  • emails.create_draft
  • reminders.create
  • calendar.create_event
  • users.delete 不可见 Forbidden for AI
  • billing.change_plan 不可见 Forbidden for AI
  • security.rotate_keys 不可见 Forbidden for AI
  • tenant.export_all_data 不可见 Forbidden for AI

人在回路（Human-in-the-loop）

MCP-first 不意味着全自动。它意味着完全可控——但受到监督。 对于敏感或高风险操作，系统会中断智能体并主动征求用户同意。

智能体根据声明的风险元数据识别操作需要人工审批， 并将控制权移交。只有在明确确认后，工具才会执行。

以下示例展示了外部批量邮件发送的典型审批对话框—— 这是最常见的关键智能体操作之一：

销售助理

emails.send_external
Critical

向所有潜在客户发送当前项目介绍的个性化邮件。

收件人
Havelblick 项目的 43 位潜在客户
主题
您的项目介绍 – Havelblick 项目
附件
无直接附件——下载链接，14 天后过期
发送时间
确认后立即发送

Grund包含项目相关信息和个人收件人数据的外部批量发送。操作不可撤销。

升级身份验证（Step-up Authentication）

对于特别敏感的操作，已有活跃会话是不够的。即使是已登录的管理员 也必须在执行关键操作前重新确认身份。

典型的升级身份验证触发条件：

  • 更改或分配管理员权限
  • 更改支付数据或订阅
  • 薪资数据或薪资导出
  • 生成或轮换 API 密钥
  • 完整数据导出
  • 删除用户或租户

可接受的升级身份验证方法（取决于系统策略）：

重新输入密码
TOTP / 身份验证器应用
Passkey
第二人的管理员审批
四眼原则

同意账本（Consent Ledger）

对智能体操作的每次同意都是一个应永久保存的事件。同意账本 使得事后可以追溯哪个操作由谁、针对什么范围、通过何种安全方法获得了批准。

同意记录中保存的字段：

consentId        — 同意的唯一 ID
userId           — 审批用户
agentId          — 执行智能体
clientId         — 连接的 MCP 客户端
toolName         — 调用的工具
inputSummary     — 输入的结构化摘要（非明文）
riskLevel        — 工具的声明风险等级
approvedAt       — 审批时间戳
expiresAt        — 审批有效期（如有时间限制）
approvalMethod   — 使用的审批方法（如 "totp"、"passkey"、"manual"）

某些审批可以有时间限制——例如针对特定发送的一次性批准。 其他的在一个会话或配置的时间段内有效。策略决定粒度。

审计轨迹（Audit Trail）

每个 MCP 操作都会生成一条审计记录。该记录是不可变的、 绑定到租户的且可机器解析的。它是合规证明、异常检测和内部审查的基础。

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

审计日志可以机器化监控异常：不寻常的执行频率、 正常工作时间之外的操作或智能体通常不使用的 Scope 访问—— 这一切都是可识别的，因为每个操作都经过清晰的类型标注和审计。

100% 可控意味着：每项能力在生效之前都经过描述、授权、确认 和审计。