Harness 如何设计安全和权限边界？

核心回答

Harness 要把模型的动作建议交给可信的授权与执行层检查，再在受限环境中执行。核心是明确“谁能对什么资源做什么”，并让约束在模型判断错误时仍然生效。

• 身份与最小权限：从认证会话取得用户、租户和授权范围，按任务开放必要工具；每次执行前校验参数、资源归属和业务状态，不能接受模型自行声明的身份或批准标记。
• 执行隔离：文件、命令和网络访问分别设边界。限制可读写目录、进程权限、网络出口和资源预算，子进程也要受相同约束；提示词中的目录要求不能替代实际隔离。
• 按风险处理授权：已获授权且在范围内的操作可以自动执行；超出范围或需要额外确认的动作，先展示具体目标和影响。授权要绑定工具、资源、参数和有效期，拒绝后不能换个工具绕过。
• 数据与记录：网页、文档和工具结果作为不可信数据；凭据留在执行层，返回和日志做必要脱敏。记录允许、拒绝、授权与实际执行结果，并验证越权、注入和重复执行等场景。

例如 Coding Agent 可以在获准工作区内读代码、修改文件并运行测试；读取其他用户文件、访问凭据目录或向新地址上传内容，应由资源与出口策略决定是否允许，不能因模型说“任务需要”就自动放行。

展开说明

1. 权限要落实到每一次具体操作

认证先回答“调用者是谁”，授权再判断“是否允许这次操作”。Harness 可以根据用户角色配置工具能力，再结合租户、资源所有者、任务范围和环境条件校验具体请求。例如“能用查询工具”不等于“能查所有租户的数据”；查询时仍应由服务端带入可信租户范围，而不是采用模型给出的 tenant_id。

工具执行器先解析工具名与参数，校验类型、必填项和枚举，再检查资源权限、业务条件和操作风险。Schema 合法只说明参数形状合格，不能证明订单属于当前用户、路径在允许范围内，或该用户具有删除权限。身份、策略和授权状态应由服务端或可信宿主维护。

工具也尽量按具体操作设计。受限的“查询当前租户销售汇总”比任意 SQL 更容易授权；只读账户、数据视图和查询额度可共同限制实际访问。只在提示词里要求“仅生成 SELECT”，不足以形成数据库只读保障。

2. 文件、命令和网络需要独立的执行边界

文件工具应规范化并解析最终路径，再按允许的读写根目录检查；还要考虑符号链接和检查后资源变化，避免仅做字符串前缀判断。使用独立工作区有助于组织任务，但最终能访问哪里，应由文件访问控制、受限挂载或操作系统机制落实。

执行命令时，优先提供参数明确的业务工具；确需通用命令能力，再校验实际命令、参数、目录和运行环境。单纯按命令名字或关键字判断，容易遗漏脚本、重定向和子进程带来的额外操作。受限进程不应拥有宿主机全部权限，派生的程序也不能逃出既定文件和网络边界。

网络出口按业务需要限制目标，检查协议、地址、DNS 解析和重定向，限制下载、上传及响应大小。只限制文件写入，却允许任意读取并外传，仍可能泄露数据。运行环境还应限制执行时间、进程、内存和磁盘等资源，避免一次错误循环持续消耗系统。

研搜参考实现按会话组织目录，但路径解析器保留部分会话外绝对路径；SQL 工具也直接执行传入查询。这些能力说明任务链路已经打通，不能据此认为实现了强文件沙箱或完整只读权限。上面的控制是进一步设计，不是现有项目功能清单。

3. 授权、暂停恢复和执行结果分别处理

风险判断应看资源敏感度、影响范围和副作用，而不只是读写标签。公开资料读取与密钥读取都是读操作，风险不同；生成本地草稿与发送给外部收件人也不是同一动作。业务可以预先授权一组明确操作，在边界内自动执行，需要额外确认时才暂停。

确认界面应展示操作、目标、规范化参数和实际影响。授权记录绑定当前主体、动作与资源、参数摘要、有效期，必要时绑定资源版本；执行前验证授权仍有效，并原子消费一次性授权。参数或目标改变后重新判断，模型输出的 approved=true 不能代替这一步。

使用 LangGraph 时，interrupt 和 Command(resume=...) 可以承接暂停与恢复，checkpointer 保存执行状态；审批者身份、授权范围与有效期仍由应用校验。恢复可能重新执行节点中的代码，因此审批前只做可重复的准备工作，真实操作放在校验之后，并用业务动作 ID、幂等键或唯一约束避免重复生效。内存检查点也不提供跨进程的持久恢复。

如果外部写操作超时，应先确定远端是否已经生效，再决定是否重试；取消当前 Agent 或恢复检查点，不会自动撤销已发生的业务操作。可逆操作可以安排补偿，不可逆操作更需要执行前的范围控制。

4. 降低不可信内容的影响，并验证实际边界

检索片段、网页、邮件和其他 Agent 的消息可能夹带指令。上下文中可以保留来源和数据边界，但这些内容不能授予新权限，也不能修改执行策略。子 Agent 只得到完成子任务所需的能力，远程接收方仍要独立鉴权，避免借助主 Agent 的身份扩大权限。

访问令牌和数据库凭据尽量留在工具服务或受限代理中，不放进模型上下文。工具只返回所需业务字段，日志记录任务 ID、工具、策略版本、授权标识、参数摘要与结果；敏感正文按需求受控保留，不能因为需要排障就默认把全部内容写入普通日志。

验证要观察实际执行结果。例如越权路径是否真的被拦截，子进程是否受限，外部文档能否诱导额外调用，失效或重放的授权是否被拒绝，以及工具已生效但回复超时时是否重复操作。同时检查正常任务的误拦截，确认这些控制既形成边界，也保留已授权工作的可用性。

常见追问

用容器是否就够了？

要看容器配置和所保护的资源。过宽挂载、高权限运行、宿主机套接字或任意网络出口都会扩大能力。容器可以作为隔离的一层，仍需明确身份、数据权限、凭据和资源限制；高敏感场景再评估更强隔离。使用托管沙箱时也要确认平台与应用各自负责什么，不能把基础隔离等同于业务授权已经完成。

为什么工具白名单还不够？

白名单只限制工具种类。同一个读文件工具仍可能读取不同目录，同一个发信工具可以发送给不同对象，所以执行前还要校验资源和参数。未知工具、缺失的关键授权或无法判断的高风险操作，应按已定义策略停止或进入受控处理。

用户已经授权过，还需要反复确认吗？

在授权主体、资源、动作、有效期和影响范围都未变化时，可以按既有授权执行。范围扩大、对象变化或授权失效才重新判断。把范围表达清楚，比对每次低风险操作重复弹窗更能帮助用户理解和控制权限。

对应教程

参考资料