设计有边界的 AI 助理：工具、权限与上下文限制

有边界的 AI 助理是由系统执行的服务合约，不是提示中的禁令。若发送工具和有效凭证仍在执行路径内，模型即使被告知不要发送，实际权限也没有收窄。按用户可见能力分别授权，才能看清资料、工具、停止点和负责人。

助理究竟可以做什么？

团队应先写一句服务章程：“对于［合资格用户］，助理可使用［获准资料范围］完成［允许任务］，产生［准许结果］，但不得［非目标或重大决定］。”同时注明部署场景、知识限制、人工监督、风险负责人和禁止结果。NIST AI RMF 涵盖这些设计资料；单句格式和按能力划界则是编辑综合，并非 NIST 或 OWASP 的规定。

“协助客户”或“管理个案”太宽，无法据此配置权限。把它改写成查找个案、总结资料、建议下一步、起草回复、更新指定栏位、发送获批信息、删除记录或批准决定，团队才能逐项询问需要什么资料、工具、行动身份和审批。OWASP 建议只提供最低所需的工具功能，并在狭窄操作足够时避免开放式扩展；这会缩小可能受影响的范围，却不会自动消除提示注入、资料泄漏或错误行动序列。

• 确认合资格用户、成功结果、资料范围、行动上限、监督方式及负责人。

每项能力可以使用哪些资料？

上下文限制是资料信封，不只是模型容量。每项能力须注明获准系统、记录和分类、对象与日期筛选、新鲜度、用户原有访问权及禁止资料。NIST 的 Map 成果涵盖知识限制、应用范围和输出用途；较大窗口不会扩大权限或令无依据资料可靠。证据不可访问、过时或不存在时，助理应限定答案或拒绝。

外部信息、附件、检索文件和 API 回应都可能夹带看似指令的文字，必须作为不可信内容处理，并与服务指令分隔。会话记录和持久记忆也要分开设计：哪些内容只在当前会话有效，哪些内容可写入长期记忆，写入前如何验证，用户与会话怎样隔离，何时失效或删除，以及哪些敏感资料永不保存。OWASP 涵盖这些记忆控制，但没有一套适合所有公司的容量或期限；实际数值应按业务用途、隐私、安全和档案要求决定。

• 资料信封须涵盖资格、证据质量、信任边界，以及记忆的验证、隔离、期限和删除规则。

身份、工具和权限怎样真正执行边界？

认证、授权和批准必须分开决定，并由工具网关和下游系统执行资源及操作限制。认证回答“这个用户、客户端或工作负载是谁”；授权回答“这个身份可对哪项受保护资源执行什么操作”；批准回答“负责人是否接受眼前这个具体行动”。模型可以理解请求，却不应自行授予权限。对于每项能力，团队还须明确采用用户委托权限，还是受控的工作负载身份，绝不能在没有说明的情况下继承管理员或高权限操作员账户。

工具应暴露“读取合资格个案摘要”等窄操作，而非整套邮箱、数据库、浏览器或命令环境。执行路径须验证动作、资源、对象、栏位、目的地、凭证期限和令牌受众，并按服务设定速率、重试、批量、花费、重复执行、回滚和断路条件。MCP 支持最小权限范围和资源绑定，但只适用于受保护的 MCP 整合，并非所有工具架构的统一处方。

• 确认行动身份，以最小范围授权，并由下游系统逐次检查权限和服务限制。

对话可以连贯，权限却应拆成小而独立、逐项强制执行的能力。

一项能力最多可以行动到什么程度？

每项能力都须设行动上限，越接近改变外部状态，独立控制越要加强。编辑阶梯包括回答或总结、建议、草稿、有界可逆写入、重大外部行动及禁止决定。草稿与发送、栏位更新与删除必须分开；支付、访问权、破坏性操作、生产变更、重大承诺及高风险专业判断仍由合资格人员和确定性政策控制。

对于重大行动，界面应先展示可检查的预览，再把批准绑定至行动者、工具、目标资源、标准化参数、时间和失效点，并在执行前重新验证。收件人、内容、金额、对象或目的地一旦改变，旧批准便不应沿用。批准只表示负责人接受一个具体提案；它不会补足行动身份缺少的授权，不会扩大常驻权限，也不能把服务明文禁止的决定变成准许事项。OWASP 同时建议人工批准和下游系统调解，正说明这两道控制缺一不可。

• 行动上限依次为回答或总结、建议、草稿、有界可逆写入和重大外部行动；禁止决定应移除能力、由下游拒绝并转交另行治理。

助理触及边界时应怎样处理？

拒绝、安全的局部协助、人工转交和安全升级，应被设计成正式服务结果，并具备真正停止执行的条件。常见原因可包括任务超出范围、资料不合资格、授权不足、需要批准、证据缺失或陈旧、需要专业判断、依赖服务不可用、达到运营限制，或侦测到安全信号。助理应以清楚语言说明边界，但不泄露敏感政策细节；工具调用、资料检查、批准或写入没有成功时，也绝不能声称已经完成。

拒绝后仍可提供不发送的草稿、检查清单或合资格资料请求。转交包须包含目标、非敏感上下文、尝试的能力、原因、证据状态、下一步和追踪编号。用户转交、业务批准及安全事故升级须交给不同负责人；出现权限提升、资料外泄、记忆投毒、绕过批准或递归工具滥用信号时应停止执行，行动改变后重新验证。

• 说明边界且不虚构成功，只提供安全协助，并携证据状态转交；处理期间停止执行。

团队怎样把边界变成可运营的设计？

团队应为每项用户可见操作填写一行能力设计画布，并把每一行接到可执行控制、证据、测试、运营指标和负责人。至少记录合资格行动者与认证、资料信封、会话和记忆规则、窄工具操作、行动身份与资源范围、行动上限、批准、运营限制、拒绝方式、证据记录、评估情境、指标及升级负责人。“助理可访问客户系统”不是合格的一行；“读取员工本来可见的指定个案摘要”才足够具体。

内部支援助理可在同一界面保留三套权限：个案摘要用员工原有的委托读取权，回复草稿只进入非最终工作区，获批发送则用独立工具。记录须重建请求、能力、政策版本、来源、工具、授权、批准和结果，并遮盖秘密。NIST 也涵盖明确职责、人工与 AI 分工、持续监测和定期检讨。

上线和持续运营需要哪些证据？

上线证据须证明允许服务和预期拒绝都能在近似部署条件下工作。除常规请求，也要测试跨账户访问、未授权工具、陈旧或投毒证据、禁止资料、绕过批准、参数改变、重复重试、依赖失效、资料外泄及失控调用链。NIST 涵盖安全失败和生产监测；NCSC 建议上线前评估安全，并说明已知限制和失败模式。

运营记录须重建请求者、能力、政策、资料来源、工具、授权、批准、行动结果及版本，但不可无限保留秘密或完整敏感上下文。团队可按能力监测异常工具使用、重复拒绝、授权失败、批准变动、异常序列、漂移、延迟、资源使用和依赖故障，并分别指定服务、访问权、业务转交及安全事故负责人；负责人须有权暂停、修改或退役能力。

模型、提示、检索、记忆、工具、权限、政策、资料、供应商或运营环境重大改变后，应重开受影响的测试和上线证据。NCSC 指出资料、模型和提示会改变系统行为；重评深度可按受影响能力和风险调整。应先推出最小有用能力，确认成功、拒绝和升级可观察，再经检讨扩大权限。敏感资料、持久记忆、特权访问、外部承诺、破坏性行动或事故响应须由相关安全、身份、隐私、档案、风险及服务负责人参与。

• 测试正常与拒绝情境，保留可重建记录，按能力监测，并在重大变更后重评。