如何设计有边界的 AI 助手：工具、权限与上下文控制

有边界的 AI 助手，首先是一份能被系统执行的服务契约，而不是系统提示词里的一串“不得做什么”。即使提示词要求助手不要发送消息，只要它仍持有可发送的工具、凭据和宽泛权限，真正的动作通道就没有关闭。企业应把检索、总结、起草、更新和发送逐项拆开，为每项能力分别限定信息、身份、工具、权限、动作、审批与停止条件。

AI 助手究竟可以做什么？

团队应先写出一句服务章程，再讨论模型或连接工具。可采用这样的句式：“面向某类合资格用户，助手可以使用经批准的信息范围处理某类任务并产生某种结果，但不得完成列明的非目标或后果重大决定。”章程还要写明部署场景、知识局限、人工监督和风险负责人。NIST AI RMF 提出的相关结果要求可为这些问题提供依据，但这一句式及能力级方法属于实务性的编辑综合，并非 NIST 的强制模板。

“帮助客服”或“管理工单”不能直接成为授权对象，因为这类宽泛表述混合了权限完全不同的动作。应把它们拆成查找已授权工单、总结事实、建议下一步、创建回复草稿、修改指定字段、发送消息和删除记录。OWASP 的最小工具功能原则支持这种拆分：能用窄操作完成任务，就不暴露开放式邮箱、数据库、浏览器或命令执行能力。每项能力还应列出明确非目标，例如不得承诺补偿、改变客户权益或作出专业判断。

• 谁可以使用该能力，以及身份如何建立。
• 哪一种用户请求和业务结果属于范围内。
• 允许读取哪些信息，允许产生哪类输出或状态变化。
• 哪些结果只能建议、只能起草、必须审批或完全禁止。
• 谁负责服务行为、访问授权、业务交接和安全事件。

每项能力可以使用哪些信息？

上下文限制应被定义为“信息信封”，而不只是模型一次能容纳多少文本。每项能力都要说明可访问的业务系统、记录类型、数据分类、对象筛选条件、时间范围、新鲜度要求和用户本身的查看资格，同时列出绝不能进入上下文的数据。若用户无权查看某个账户，助手不能因为检索系统能够找到它就使用它；若关键证据缺失、过期或不可访问，回答应明确限定或拒绝，而不是用更大的上下文窗口填补空白。

检索到的文档、外部消息、附件和接口响应应被视为不可信内容，不能悄悄变成服务指令。系统需要在结构上区分控制指令与业务材料，并在材料进入上下文前实施来源、格式和范围校验。会话历史与持久记忆也要分开设计：哪些内容仅在当前会话可用，哪些内容通过验证后才可保存，如何隔离用户和会话，何时过期、删除，以及哪些敏感数据永不进入记忆。具体容量和期限应按服务确定，不宜套用统一数字。

• 数据资格：来源、记录、分类、对象和用户权益是否匹配。
• 证据状态：资料是否足够、新鲜且能追溯到获准来源。
• 信任边界：检索材料只能作为数据，不能覆盖系统规则。
• 记忆规则：保存资格、隔离、完整性、到期和删除责任是否明确。

身份、工具和权限如何真正执行边界？

认证、授权和审批必须分别处理，并由工具网关及下游系统执行资源和操作限制。认证回答“用户、客户端或工作负载是谁”；授权回答“该身份能否对这个受保护资源执行这一操作”；审批回答“负责人是否接受眼前这一项具体动作”。MCP 授权规范中的客户端、受保护资源服务器和授权服务器体现了这种职责分离，但其协议要求只适用于相应的受保护 MCP 集成，不能照搬为所有工具架构的通用规定。

每项能力应明确选择委托用户身份或受控工作负载身份，绝不能默认继承高权限运维账号。工具接口只暴露必要动词和经过校验的参数；执行路径还要限制资源、对象、字段、目标地址、凭据有效期和令牌受众。OWASP 建议保留用户授权上下文、采用最小下游权限，并让下游系统完整校验每次请求。提示词和自然语言护栏可以帮助模型遵循流程，却不能成为授权控制。速率、重试、批量、链深、时间、成本、幂等和熔断限制则应按具体服务配置。

对话可以连续，权限必须拆成能够独立执行和审查的小能力。

ModelFold 编辑部

每项能力最多可以采取多大的动作？

每项能力都需要明确的动作上限；越接近改变外部状态，就越需要独立于模型的强制控制。一个实用阶梯是：回答或总结、建议或提出方案、创建草稿、执行有边界且可逆的写入、产生后果重大的外部动作，以及遇到禁止作出的决定。这一阶梯是依据 NIST、OWASP 与 NCSC 控制原则整理的实务方法，不是任何机构规定的统一风险分级。草稿必须与发送分离，可逆字段更新必须与删除分离，建议也不能伪装成负责人的最终决定。

对发送、发布、删除、付款、授权访问、生产变更或其他重大外部动作，界面应先展示可检查的动作预览。审批记录要绑定执行者、工具、目标资源、标准化参数、时间和有效期，并在执行前重新校验；收件人、内容或目标一旦改变，旧审批就不能继续使用。人工审批只接受一项已经具备权限的提案，不会扩大常设权限，也不能把禁止决定变成允许决定。高风险专业判断和重大承诺应交给具备相应资格与责任的人员，并进入独立治理流程。

1. 只回答或总结获准信息，不改变外部状态。
2. 提出建议或生成可检查的动作方案，但不执行。
3. 在非最终区域创建可编辑草稿，并指定审核人。
4. 通过窄接口写入获准字段，同时具备校验、幂等或回退措施。
5. 重大外部动作须同时满足授权、参数绑定审批和确定性执行策略。
6. 禁止决定不提供对应能力，并由下游系统拒绝。

助手触及边界时应如何拒绝和升级？

拒绝、安全的部分帮助、人工交接和安全升级都应被设计成正式服务结果，并设置真正停止执行的条件。可使用稳定的原因类别：任务超出范围、信息不合资格、授权不足、需要审批、证据缺失或过期、需要专业判断、依赖不可用、达到运行限制或检测到安全信号。助手应以普通语言说明边界，但不泄露敏感策略细节，也绝不能声称未完成的检索、审批、工具调用或写入已经成功。

边界之外仍可提供安全部分，例如创建不含承诺的草稿、列出待补信息或生成供负责人检查的清单。交接包应包含原始目标、非敏感上下文、尝试的能力、原因类别、已有或缺失证据、建议下一步和追踪标识。普通用户转人工、业务审批和安全事件升级必须进入不同责任路径：前两者解决服务或决策问题，后者可能需要暂停能力、撤销凭据和启动事件响应。待处理期间执行保持停止；提案发生变化后，必须重新验证。

• 发现越权工具请求、审批绕过或权限提升迹象时，停止相应执行路径。
• 发现数据外传、记忆污染或递归工具滥用迹象时，转入安全事件流程。
• 仅因材料不足或依赖故障无法完成任务时，保留安全部分并交给服务负责人。
• 所有拒绝都记录适用策略、原因、结果和负责接收的目的地。

怎样把这些边界变成可运行的能力设计？

团队应为每项用户可见操作填写一行能力设计画布，并把每一行接到真实控制、证据、测试、运行指标和责任人，而不是止于文档。字段至少包括合资格参与者与认证方式、信息信封、会话与记忆、窄工具操作、执行身份与资源范围、动作上限、审批、运行限制、拒绝方式、日志证据、评估场景、指标和升级责任。NIST 的治理结果强调清晰角色、沟通路径、人与 AI 的责任区别、持续监测和定期复审；画布则是落实这些原则的一种实务组织方式。

以内部客服助手为例，“查找并总结工单”“创建回复草稿”“发送已审批回复”可以共用聊天界面，却不能共用全部数据、工具和授权。读取能力只继承员工本来可见的工单；草稿能力只写入非最终工作区；发送能力使用独立窄接口，并重新校验收件人、内容引用、授权、审批有效期和防重复状态。日志应能重建能力、策略、来源、工具、授权、审批和结果，同时对敏感内容做必要脱敏，保留范围则遵循组织的隐私与档案规则。

上线并持续运行需要哪些证据？

上线需要同时证明允许的服务能够完成，以及预期的拒绝、停止和升级能在接近真实部署的条件下生效。测试集除了正常任务，还应覆盖跨账户访问、未授权工具、过期证据、受污染检索内容、禁止数据、审批绕过、参数改变、重复重试、依赖故障、数据外传企图和失控调用链。NIST AI RMF 强调接近部署环境的测试、生产监测、知识与泛化局限、安全失败和定期安全评估；NCSC 也建议在发布前评估并向使用者说明已知局限和失败方式。

日志应能回答：谁提出了什么请求，哪项能力和哪个策略版本生效，使用了哪类来源与工具，发生了哪些授权和审批判断，最后产生了什么结果，以及当时运行的是哪些模型、提示词、检索、工具和策略版本。记录这些结构化元数据不是要求无限保存完整对话，更不能保存密钥、令牌或无边界的敏感上下文。生产指标应按能力观察异常工具使用、重复拒绝、授权失败、审批变化、异常动作序列、漂移、延迟、资源使用和故障。

模型、提示词、检索、记忆、工具、权限、策略、数据、供应商或运行环境发生实质变化后，应重新打开受影响能力的测试与发布证据。复审范围可以与影响程度相称，但不能把提示词修改当作不触及控制面的普通文案更新。服务负责人、访问授权负责人、业务交接负责人和安全事件负责人都应有暂停、修订或退役相应能力的权限。最稳妥的扩展方式是从最小但有用的能力起步，确认成功与拒绝都可观察，再通过正式变更审查逐步增加权限。

• 发布前：验证正常任务、边界拒绝、攻击情形、依赖故障和停止条件。
• 运行中：按能力监测结果、授权、审批、异常序列、资源消耗和已知局限。
• 发生重大变更后：重跑受影响场景，复核权限、日志、责任人和回退方案。
• 触及敏感信息、持久记忆、特权访问、外部承诺、破坏性变更或事件响应时，纳入安全、身份、隐私、档案、风险和服务负责人。