风险模型与保护等级

完整的智能体能力并不意味着智能体可以做任何事情。它意味着 系统能够以结构化方式描述其所有状态和所有能力——包括 原则上对智能体禁止的能力。风险模型是划定这一边界的工具： 精确、机器可读、无例外。

敏感区域

系统的某些部分需要更高级别的保护——不仅防范外部攻击者， 也防范内部智能体。一个常见的误解是：

用户可以查看，所以 AI 也可以查看。

这是错误的。有效的 AI 访问权限由以下因素的交集决定： 用户权限、智能体权限、Client 信任级别、资源敏感度、 目的和确认状态。每个因素都是独立的屏障——而不仅仅是用户角色。

需要特别保护的敏感区域包括：

• 财务数据 — 银行账户、支付数据、账单详情
• 健康数据 — 医疗文件、病历、证明
• 薪资数据 — 工资、奖金、薪资历史、Payroll 运行
• 人事档案 — 合同、申请材料、内部评估
• 访问凭据与 API 密钥 — 密码、私钥、Access Token
• 删除与批量功能 — 删除用户、删除租户、批量导出
• 权限管理 — 授予和撤销权限、更改角色
• 安全日志 — 审计轨迹、安全事件、活跃会话
• 私人通信 — 保密备注、内部评估
• 税务数据与合同 — 涉税文件、具有法律效力的合同
• DSGVO 下的个人数据 — 所有能识别自然人的数据

六个保护等级

每个 Resource 和 Tool 被分配到六个保护等级之一。 等级决定谁可以访问、智能体是否能在 Discovery 中看到该 Tool， 以及执行前需要什么批准。

Public（公开）

无限制的公开可访问内容。无需身份验证、无特殊角色、无需确认。 适用于帮助文章、产品信息和已记录的系统能力。

help.article.read
public.product_info.read

Internal（内部）

仅限已登录用户。身份验证即可；无需特殊权限。 典型用于列表查询、搜索和自身上下文的常规工作视图。

project.list
contact.search

Confidential（机密）

仅具有明确角色和分配 Scope 才能访问。简单登录不够。 数据是内部的，但不面向所有员工。

contract.read
customer_private_note.read

Sensitive（敏感）

仅在获得额外批准或限制上下文传递的情况下才能访问。 智能体不得未经检查就将这些数据加载到其上下文中。 传递给 AI 时，范围必须严格限制，目的必须有记录。

salary.read
bank_account.read
health_document.read

Critical（关键）

AI 不得在此等级自主行动。每次执行都需要明确的用户批准， 通常需要 Step-up Authentication。这些操作会产生外部影响、 难以撤销，或直接影响第三方。

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI（禁止 AI 访问）

这一等级是硬性边界，而非 Policy 决策。此等级的 Tool 和 Resource 在智能体的 Tool Discovery 中被完全隐藏。 智能体既不能读取、调用，也不能将其作为参考。

password.read
private_key.read
full_database_export
raw_access_token.read

风险模型

风险模型将保护等级转化为每种执行场景的操作规则。 它规定是否允许自主执行、是否需要确认，以及需要何种批准。

Low（低风险）

纯读取操作或无持久外部影响的操作。智能体可以自主调用这些 Tool。

Medium（中等风险）

创建或更改数据或状态，但在严格限定的 Scope 内，无外部影响。 当 Scope 和上下文从 Workflow 中明确可见时，允许自主执行。

High（高风险）

更改相关系统状态或影响其他用户和外部资源的操作。 通常需要明确确认。

Critical（关键风险）

外部通信、支付、删除操作、权限变更。始终需要确认， 通常需要 Step-up Auth。不允许自主执行。

Forbidden（禁止）

对 AI 智能体完全禁用——既不可读也不可写。 在 Discovery 中不可见，不可调用，不可作为参考。

审批 UX

只有当用户界面也履行其职责时，技术风险模型才能完全发挥作用。 确认的质量取决于其所依据信息的质量。

在人类确认关键智能体操作之前，必须能够清楚地了解七件事：

1. 智能体想做什么？ — 具体操作，而非智能体用自己语言表述的意图。
2. 智能体为什么要这样做？ — 是什么意图或任务触发了此操作。
3. 将使用哪些数据？ — 收件人、附件、引用的实体。
4. 会产生哪些外部影响？ — 系统外部会发生什么变化：邮件被发送、支付被触发、文件被提交。
5. 谁会受到影响？ — 个人、公司、租户、外部方。
6. 操作是否可以撤销？ — 明确说明：可撤销或不可撤销。
7. 确认后会发生什么？ — 下一个系统状态的完整描述。

以下示例展示了 emails.send_external Tool 的完整审批卡：

智能体等待用户的决定。它不得预判确认结果，不得设置默认操作， 也不得基于之前批准的时间戳执行操作。