【大模型安全实战】智能体安全工程实践如何把安全控制分发到每个 Harness专栏智能体攻防卷·进阶文章类型原创技术分析参考方向Distributing Security Controls Through Harness Engineering审阅边界本文讨论的是智能体安全架构方法不代表对任何具体论文结论、项目或生产系统的安全认证。适合读者AI 工程师、平台架构师、安全负责人、研发管理者。说明本文基于公开安全治理思路整理示例用于方法说明不构成安全审计结论。具体平台的推荐、质量分和活动规则可能动态调整发布前应以 CSDN 当前公开规则为准。作者Valhalla Matrix治理实验室摘要随着智能体逐渐具备调用工具、访问数据、执行代码和修改业务状态的能力传统“只在网络边界做安全控制”的方式开始暴露局限。网关可以检查流量但无法天然理解智能体每一次工具调用的业务意图统一入口可以做身份认证但不一定能判断当前动作是否超出授权范围。当智能体通过内部服务、异步队列或本地工具执行任务时部分动作甚至可能不经过原有网关。一种更稳妥的思路是将安全控制分发到智能体动作的执行 Harness 中在工具调用、数据访问和副作用产生之前进行本地校验同时使用统一策略中心和审计系统保持治理一致性。本文将从以下几个方面介绍这一方法什么是智能体 Harness为什么安全控制不能只停留在网络边界哪些控制适合下沉到 Harness如何设计执行前、执行中和执行后的安全检查如何避免分布式控制带来的策略漂移和性能问题如何通过最小 PoC 验证方案是否有效。一、问题背景安全不能只依赖一堵边界墙传统系统通常采用如下安全路径客户端 ↓ API 网关 ↓ 认证与授权 ↓ 后端服务 ↓ 数据库或外部系统这种架构仍然有价值网关可以承担身份认证访问控制流量限制请求过滤日志记录协议转换。但智能体的执行链路通常更加复杂用户请求 ↓ 智能体规划 ↓ 工具选择 ↓ 数据读取 ↓ 外部 API 调用 ↓ 文件修改或任务提交智能体的一次回答可能触发多个动作每个动作的风险也不同动作可能风险查询公开知识库风险相对较低读取内部客户资料涉及数据权限调用支付接口涉及资金和业务副作用修改生产配置涉及高风险变更执行 Shell 命令涉及主机和供应链安全向外部系统发送内容涉及数据泄露和合规如果所有安全控制都集中在最外层入口就很难对每个动作进行足够细粒度的判断。因此问题不只是“这个请求能不能进入系统”还包括“当前智能体是否有权执行这个具体动作”“这个动作访问了哪些数据”“它会产生什么副作用”“当前上下文是否满足执行条件”二、什么是智能体 Harness在智能体系统中Harness 可以理解为包裹智能体运行过程的执行外壳。它通常负责注入任务上下文管理工具和资源控制动作执行处理失败和重试记录执行轨迹约束智能体行为。可以用下面的模型表示任务输入 ↓ Harness ├── 上下文管理 ├── 工具注册 ├── 权限校验 ├── 数据访问控制 ├── 副作用审批 ├── 超时与限流 └── 审计记录 ↓ 智能体动作 ↓ 工具或外部系统将安全控制放入 Harness重点不是“把所有安全逻辑复制到每个组件”而是在每个关键动作真正执行之前确保它经过统一定义、分布式执行的安全检查。需要区分两个概念策略统一 ≠ 检查集中更适合智能体系统的方式通常是策略集中管理 执行检查分布在各个 Harness 审计结果统一汇聚这样既可以降低绕过单一入口的风险也能减少不同组件自行解释安全策略造成的不一致。三、边界安全与 Harness 安全的关系Harness 安全不是对网关安全的替代而是纵深防御的一部分。3.1 仅依赖边界的模型用户或智能体统一网关后端服务工具与数据系统这种方式的优点是结构简单、策略集中但风险也比较明显内部调用可能绕过网关异步任务未必经过相同检查网关难以理解动作级业务语义工具之间的权限边界可能不清晰一次授权可能被错误地沿用到多个动作。3.2 加入 Harness 控制后的模型用户请求智能体 Harness动作授权数据访问检查副作用检查工具或外部系统统一策略中心统一审计系统在这个模型中网关负责入口级控制Harness 负责动作级控制工具适配层负责资源级约束策略中心提供统一规则审计系统记录完整执行链路。这是一种“集中制定、分布执行、统一审计”的架构。四、为什么动作级安全控制更重要智能体安全的关键单位不应该只是“请求”还应该包括“动作”。同一个用户请求可能产生多个不同风险等级的动作用户帮我分析这份销售报告并给重点客户发送跟进邮件。智能体可能执行读取销售报告提取客户信息生成邮件内容调用邮件系统向外部收件人发送邮件。这几个动作不应该共用完全相同的授权结果。动作建议控制读取报告数据范围和字段权限提取客户信息敏感字段脱敏生成邮件内容安全和敏感信息检测调用邮件系统工具权限和目标限制发送邮件高风险副作用审批如果只在用户请求进入时做一次授权就可能出现入口授权通过 ↓ 智能体连续执行多个动作 ↓ 某个后续动作超出了原始授权范围因此授权应尽量绑定到具体动作、资源和上下文而不是只绑定到最初请求。五、Harness 中应该有哪些安全控制一个可落地的 Harness至少可以包含以下几类控制。5.1 动作授权检查当前动作是否符合用户身份智能体身份当前会话任务目标工具权限资源范围时间和环境限制。授权判断不应只回答“用户是谁”还应回答谁 在什么上下文 以什么身份 对什么资源 执行什么动作可以将动作抽象为{actor:agent-123,principal:user-456,tool:customer_email,operation:send,resource:customer-789,purpose:follow-up,risk_level:high}5.2 数据级检查工具调用前应确认是否有权读取目标数据是否只读取必要字段是否需要脱敏是否允许将数据传递给模型是否允许将数据发送到外部系统是否超过数据用途范围。特别是以下内容不能仅依赖网络边界保护身份证件信息联系方式财务信息医疗信息内部源代码客户合同访问凭证。5.3 副作用校验副作用是智能体安全中最需要重点控制的部分。常见副作用包括发送邮件创建订单发起付款修改数据库删除文件修改生产配置发布内容创建账号调用外部系统。建议将动作分为三个等级等级示例建议处理低风险查询公开信息自动执行中风险读取内部数据、生成草稿自动执行并记录高风险付款、删除、发布、变更配置二次确认或审批对于高风险操作可以采用智能体提出动作 ↓ Harness 生成待审批任务 ↓ 用户或审批人确认 ↓ 重新校验上下文 ↓ 执行动作注意审批不能只绑定一个布尔值。审批后还应重新确认目标资源是否改变参数是否改变权限是否过期风险等级是否升高是否超过时间窗口。5.4 信任和风险评分可以根据以下因素计算动作风险工具类别目标资源数据敏感等级是否产生不可逆副作用是否涉及外部系统是否由用户明确授权当前会话是否异常动作是否偏离任务目标。一个简单的风险决策模型可以表示为风险等级 f( 工具风险, 数据敏感度, 副作用强度, 用户授权, 上下文可信度 )需要注意风险评分只能作为辅助决策不应替代明确的禁止规则。对于付款、删除生产数据等动作应该设置硬性控制。5.5 审计记录每个动作至少应记录请求标识用户标识智能体标识Harness 标识工具名称目标资源输入摘要授权结果风险等级执行结果阻断原因时间戳策略版本。建议避免在日志中直接记录完整敏感数据而是使用字段摘要数据哈希脱敏内容资源标识访问范围结果状态。审计记录的目标不是“把所有内容都保存下来”而是让组织能够回答谁在什么时候让哪个智能体执行了什么动作 当时使用了哪条策略 为什么允许或阻断六、一个动作的安全执行流程可以将 Harness 的动作流程设计为是否是否接收智能体动作解析工具与参数校验身份与会话匹配动作策略是否访问敏感数据执行数据权限与脱敏检查继续风险评估是否产生高风险副作用审批或二次确认执行前检查重新校验上下文调用工具执行后校验与审计这个流程至少覆盖三个时点执行前身份和授权参数校验数据范围风险等级审批状态。执行中超时限流输出大小资源范围中断和取消。执行后结果脱敏输出内容检查状态变化记录审计写入异常告警。七、分布式 Harness 的主要风险把控制分发到每个 Harness 并不意味着风险自动消失反而会带来新的工程问题。7.1 策略漂移不同 Harness 可能加载不同版本的策略导致A Harness 允许 B Harness 拒绝建议策略集中存储策略版本化动作记录策略版本定期检查策略一致性高风险动作必须使用受控策略版本。7.2 检查被绕过如果工具还提供了不经过 Harness 的直连接口攻击者或错误代码可能绕过安全控制。建议工具调用统一经过适配层禁止业务代码直接访问高风险资源对工具接口设置最小权限在资源侧保留最终授权检查对绕过路径进行静态和运行时检测。7.3 检查过重导致性能下降如果每个低风险动作都进行复杂网络查询可能造成响应延迟升高策略服务成为瓶颈智能体任务超时重试放大流量。可以采用分级策略低风险动作本地快速检查 中风险动作缓存策略 远程确认 高风险动作强制实时校验或人工审批7.4 审计数据过多智能体可能在一次任务中执行几十甚至上百个动作。如果全部记录原始输入和输出会造成日志成本增加敏感数据扩散审计系统压力增大数据保留和删除困难。建议采用结构化事件输入输出摘要敏感字段脱敏分级留存关键动作保留完整证据低风险动作保留最小元数据。八、不要把“分布式安全”理解为“完全分散”一个成熟方案通常不是把安全逻辑复制到每个地方而是明确分层。层级主要职责网关层入口认证、基础限流、协议检查Harness 层动作授权、工具控制、审批和审计工具适配层参数约束、资源范围、调用隔离资源层最终访问控制和数据保护策略中心统一策略、版本和发布审计中心统一记录、检索和告警可以概括为控制执行分布式 策略管理集中化 最终资源控制不下放 审计结果统一化尤其要注意Harness 不能成为资源系统唯一的安全边界。数据库、对象存储、支付服务和生产集群仍应保留自己的权限控制。九、适合落地的最小安全 Harness企业不需要一开始就构建完整的智能体安全平台可以先实现一个最小版本。最小能力动作白名单 参数 Schema 校验 工具最小权限 高风险操作审批 敏感字段脱敏 结构化审计一个简化的伪代码示例defexecute_tool(action,context):policypolicy_center.get(toolaction.tool,operationaction.operation,policy_versioncontext.policy_version,)authorize(context,action,policy)validate_arguments(action.arguments,policy.argument_schema)dataapply_data_scope(action,context,policy)ifpolicy.requires_approval:approvalapproval_service.require(context,action)ifnotapproval.accepted:audit.record(action,statusblocked,reasonapproval_required)raisePermissionError(approval required)resulttool_registry.execute(toolaction.tool,argumentsdata,timeoutpolicy.timeout,)safe_resultredact_sensitive_output(result,policy)audit.record(action,statussucceeded)returnsafe_result这个示例只用于说明结构不能直接作为生产安全实现。生产系统还需要补充防重放幂等控制超时和取消资源级授权审批过期策略缓存一致性密钥保护失败重试边界审计完整性保护。十、如何设计安全控制的优先级建议优先把控制下沉到以下位置。第一优先级高副作用工具例如支付删除发布修改生产配置发起外部通知创建账号执行代码。这些动作应强制经过 Harness必要时增加人工审批。第二优先级敏感数据访问例如客户资料财务数据医疗信息内部源代码凭证和密钥未公开业务数据。重点控制最小字段最小范围数据用途结果脱敏外发限制。第三优先级外部系统连接重点关注目标域名请求方法参数范围调用频率返回内容凭证使用网络出口。第四优先级低风险查询动作低风险动作也应保留基本审计但可以使用更轻量的本地检查避免安全控制反而成为系统瓶颈。十一、企业 PoC 验证方案建议通过一个包含不同风险等级工具的最小实验验证方案是否有效。11.1 准备四类工具公开信息查询工具 内部数据查询工具 邮件草稿生成工具 邮件发送或配置修改工具11.2 设计正向场景验证正常用户可以读取授权范围内的数据智能体可以执行低风险查询中风险动作能够正确记录高风险动作触发审批审批后动作可以正常执行。11.3 设计负向场景验证未授权用户读取敏感数据智能体尝试访问超出范围的资源工具参数被篡改审批状态过期绕过 Harness 直接调用工具动作目标在审批后发生变化外部输出包含敏感字段重试导致重复副作用。11.4 记录关键指标建议记录阻断率误报率漏报案例平均检查延迟高风险动作审批耗时策略版本一致性审计事件完整率Harness 绕过路径数量。没有这些数据很难判断“安全控制分发”是否真正改善了系统安全性。十二、落地检查清单策略治理策略是否集中管理策略是否版本化高风险动作是否有强制策略策略更新是否支持回滚是否能追踪某次动作使用的策略版本执行控制所有高风险工具是否经过 Harness是否存在直连绕过路径参数是否经过 Schema 校验是否具备超时、限流和取消机制是否支持幂等和防重放数据保护是否按字段和资源做权限控制敏感字段是否脱敏是否限制数据向外部系统传递模型上下文是否遵循最小必要原则日志是否避免记录原始敏感数据审计与响应是否记录用户、智能体和工具身份是否记录动作参数摘要是否记录允许或阻断原因是否能关联一次任务中的全部动作是否能根据审计记录回放安全决策十三、三个核心经验经验一不要把安全做成孤立的边界设备网关、WAF 和入口认证仍然重要但它们无法理解所有智能体动作的业务语义。智能体系统需要把关键控制下沉到动作执行点。经验二安全检查要轻量但不能缺失不是所有动作都需要人工审批也不是所有动作都需要实时访问策略中心。可以采用分级控制低风险本地快速检查 中风险策略缓存与上下文校验 高风险实时检查与审批但无论风险高低都应保留最基本的授权和审计能力。经验三分布式执行必须有统一主线如果每个 Harness 自行定义规则最终会形成新的治理问题策略不一致 权限难追踪 审计不可关联 升级难以回滚因此推荐采用统一策略 分布执行 统一版本 统一审计 资源侧兜底十四、最终结论智能体带来的安全问题不只是“模型会不会输出错误内容”还包括它能访问哪些数据它能调用哪些工具它能执行哪些动作它能产生哪些副作用它的每一步是否能够被审计和追责。将安全控制引入 Harness并不意味着取消网关或边界安全而是将安全控制从单一入口扩展到每一个关键动作。更准确的架构原则是策略集中管理控制分布执行资源侧最终兜底审计统一汇聚。在实际落地中应优先保护高副作用工具、敏感数据访问和外部系统连接再逐步扩展到低风险查询和普通内容生成。最终需要通过 PoC 验证的不是“是否增加了更多安全检查”而是是否减少了绕过路径 是否降低了越权风险 是否控制了副作用 是否保持了可接受的延迟 是否能够完整审计只有这些问题都得到实测回答Harness 才真正成为智能体安全架构的一部分而不是额外增加的一层复杂度。参考资料Distributing Security Controls Through Harness EngineeringarXiv2607.25890发布前请核验论文标题、编号和公开链接是否准确。OWASP Top 10 for LLM Applicationshttps://owasp.org/www-project-top-10-for-large-language-model-applications/NIST AI Risk Management Frameworkhttps://www.nist.gov/itl/ai-risk-management-framework