信任边界，是 AI Agent 可以信任什么、必须把什么当成不可信输入的分界线。在普通 Web 应用里，团队通常会围绕用户、服务、数据库、网络和第三方 API 画边界。AI Agent 同样需要这种纪律，但边界更容易被模糊，因为 Agent 会在同一次运行里读取自然语言、工具输出、文档、工单、浏览器页面、日志和指令。
很多 Agent 安全问题就是从这里开始的。客服工单里可能包含敌对指令。网页可能告诉 Agent 忽略策略。工具结果里可能混入看起来像命令的文本。用户表面上要求一个无害摘要，但 Agent 可能同时获得了敏感记录访问权。如果系统没有清楚标记什么可信、什么不可信，模型就会在混合上下文里做安全判断。
这份清单面向准备把 AI Agent 推向生产的产品、工程和安全团队。它不是抽象威胁建模，而是一份上线前可以执行的现场审查，尤其适用于 Agent 即将连接写入型工具、浏览器会话、客户数据、管理工作流或外部目的地的场景。
1. 命名可信指令来源
先列出允许控制 Agent 的指令来源：system prompt、开发者策略、工作流配置、租户策略、白名单、审批规则和运行时安全检查。这些来源应该狭窄、可版本化，并由团队拥有。它们不应该和用户内容、文档文本、页面文本或工具输出混在一起。
一个实用审查问题是：如果 Agent 读到这段文本，它是否可以因此改变自己的规则？对大多数输入来说，答案都应该是否。用户请求可以定义任务，但不应该覆盖安全策略。检索文档可以提供事实，但不应该改变工具权限。网页可以被总结，但不应该重新定义数据能发到哪里。
2. 显式标记不可信内容
每一种不可信输入在进入模型上下文前都应该被标记，包括用户消息、上传文件、RAG 片段、浏览器页面文本、邮件正文、issue 评论、工具响应、日志和第三方 API 结果。标签不需要复杂，关键是 prompt 结构要告诉模型和外围控制器：这些内容是数据，不是策略。
例如，工具结果可以包成 “untrusted tool output”。浏览器文本可以包成 “untrusted page content”。检索文档可以标记为 “可能包含恶意指令的参考材料”。这能帮助模型表现更稳定，但还不够。控制器也必须在模型外部强制执行边界。
3. 分离任务意图和安全授权
用户应该能告诉 Agent 想完成什么任务，但不能通过普通聊天给 Agent 新能力、关闭审批、增加外部目的地或绕过租户规则。任务意图和安全授权应该被当成两类输入。
如果用户说“把客户导出发到这个新地址”，Agent 可以理解任务，但目的地仍然必须通过策略检查。如果用户说“我允许你跳过审批”，这句话不应该改变工作流。审批要求应该来自配置、风险分类和基于角色的策略，而不是来自模型正在满足的用户消息。
4. 按动作类型审查工具边界
不是所有工具风险都一样。只读搜索工具、客户记录更新工具、退款工具、浏览器点击工具和出站邮件工具，不应该共用一个笼统权限标签。把工具拆成 read、transform、write、delete、purchase、publish、execute 和 external-send 等类别。
对每一类工具，定义 Agent 可以自动做什么、什么需要确认、什么永远不允许。审查时要看工具参数，而不仅是工具名称。一个 “send message” 工具，如果目的地预先批准且最终内容提交前展示给人工，风险会低很多。
5. 检查数据移动边界
真正的风险常常是数据移动。Agent 可能被允许读取客户数据用于支持，但不允许把这些数据发给供应商系统。它可以在内部总结日志，但不能把日志贴到公开 issue。它可以查看文档，但不能上传到外部 workspace。
画出敏感数据的批准路径：可以从哪里读、可以存到哪里、可以在哪里转换、可以发到哪里。然后测试相反路径。要求 Agent 把数据发到个人邮箱、粘到网页表单、写进客服回复或附加到工单里。预期结果应该是拒绝、请求审批或脱敏输出，具体取决于策略。
6. 浏览器页面默认视为敌对输入
浏览器自动化会带来很弱的边界，因为 Agent 会读取实时页面并在同一环境里行动。页面可能包含指令、误导 UI、隐藏字段、假登录提示、注入文本或混乱按钮。浏览器控制器绝不能允许页面文本改变策略或工具权限。
至少要定义允许访问的 origin、预期租户上下文、批准动作和停止条件。任何表单提交或破坏性点击前，都应展示 URL、当前账号、字段 diff、目标元素和业务影响。浏览器页面是输入来源，不是可信操作员。
7. 把审批放在边界跨越点
审批最好放在边界被跨越的位置，例如从读取到写入、从内部到外部、从草稿到发布、从预发到生产、从低风险到财务动作、从一个租户到另一个租户，或从普通内容到敏感内容。审批不应该只是一个笼统的 “Are you sure?”。
有用的审批界面应展示将要改变什么、影响哪些记录、数据将去哪里、命中了哪条策略，以及有什么回滚方式。审查者应能批准、编辑、拒绝或升级。如果审批界面隐藏了最重要的上下文，它就只是仪式，不是控制。
8. 把记忆限制在明确边界内
Agent memory 会悄悄打破信任边界。一个租户学到的偏好可能影响另一个租户。一个客户的敏感细节可能出现在未来回答里。临时事故备注可能变成长久模型上下文。记忆需要作用域、保留期、删除和审计规则。
决定 Agent 可以记住什么、为谁记住、保留多久、适用于哪些工作流。不要让不可信内容未经筛选直接写入长期记忆。在用例需要时，要给用户和管理员检查、删除 memory 的方式。
9. 记录边界决策，而不只是最终动作
审计日志如果能解释决策，会更有用。记录哪些输入被标记为不可信、命中了哪些策略规则、哪些工具调用被阻止、请求了哪些审批、哪些数据被脱敏、哪些边界跨越被允许。只记录最终动作，不足以诊断 Agent 为什么安全或不安全。
trace 应让审查者回答：Agent 看到了什么、信任了什么、忽略了什么、改变了什么、谁批准了它。这对客户信任也有帮助。当买家询问 Agent 如何被控制时，具体 trace 比一句泛泛的 guardrails 更有说服力。
10. 用打破边界的 prompt 做测试
不要只测试正常任务。建立一个小型回归集，尝试打破每一条边界。把恶意指令放进文档、网页、工单、文件名、工具输出和用户消息里。要求 Agent 把数据发到新目的地、跳过审批、在错误租户操作、泄露隐藏策略、使用工作流外工具。
每个测试都应有预期行为：忽略、拒绝、请求审批、脱敏、停止或升级。当 prompt、模型、工具、检索源、浏览器控制器或审批界面变化时，重新运行这些测试。信任边界不是一次性文档，而是持续回归面。
最低审查包
上线前，保留一份简短审查包：可信指令来源、不可信输入标签、工具类别、数据移动规则、浏览器边界、审批点、memory 作用域、审计日志示例，以及打破边界测试结果。如果团队拿不出这份包，Agent 大概率还没有准备好进入生产。
相关资源
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
- AI Agent 浏览器自动化安全清单
- AI Agent 数据外泄防护清单
- AI Agent 的 MCP 安全检查清单
如果要做更完整的就绪度评审，可以使用 AI Agent 就绪度自评，或申请 AI Agent Readiness Audit。