【大模型安全实战】智能体安全进阶为什么“能连接工具”不等于“可以执行操作”第8期专栏智能体攻防卷·进阶 第 8 期作者Valhalla Matrix治理实验室主题执行控制、工具授权与安全不变量论文线索《From Tool Connection to Execution Control: Benchmarking Security Invariants…》**说明**本文结合智能体工程实践讨论执行控制模型。文中示例为简化实现不能替代生产环境中的权限系统、审批系统和安全审计。摘要在很多 Agent 系统中工具调用流程通常被简化为用户请求 ↓ Agent 选择工具 ↓ 连接工具 ↓ 执行调用这种设计容易把“可以连接工具”和“可以执行操作”视为同一件事。但在真实业务中读取文档、查询订单、修改配置、删除资源、发送消息和转账操作的风险完全不同。Agent 即使被允许访问某个工具也不应该天然拥有该工具的全部执行权限。更合理的安全模型是连接权限 ≠ 执行权限本文围绕执行控制展开分析工具连接和实际执行之间的安全边界并给出一套可落地的执行安全不变量模型帮助团队将 Agent 安全控制从外围网关下沉到具体动作执行点。一、真正的风险不在“能不能连”而在“能不能动”很多团队首先关注的是 Agent 是否能够连接外部系统是否能访问数据库是否能调用搜索服务是否能使用文件系统是否能访问工单系统是否能调用支付或审批接口。但“连接成功”只说明系统之间建立了通信关系并不代表 Agent 应该执行所有操作。举个简单例子Agent 可以访问订单系统 ≠ Agent 可以取消订单Agent 可以读取数据库 ≠ Agent 可以修改或删除数据Agent 可以调用邮件服务 ≠ Agent 可以向任意外部地址发送邮件如果系统把连接权限直接映射成执行权限就可能出现以下问题只读工具被误用为写操作工具普通查询权限被扩展成管理权限Agent 可以访问授权范围之外的资源高风险动作没有人工确认工具调用失败或参数异常时无法及时阻断日志只记录“调用了哪个工具”没有记录“实际改变了什么状态”。因此Agent 的安全边界不能只设在工具入口还应该设在每一个具体执行动作之前。二、连接权限与执行权限必须分层可以把工具调用拆分为两个不同阶段工具连接 ↓ 动作识别 ↓ 执行授权 ↓ 参数和目标校验 ↓ 实际执行2.1 工具连接工具连接解决的是Agent 是否可以发现并访问某个工具例如获取工具描述建立客户端连接读取工具元数据获取临时会话查询可用操作。2.2 实际执行执行权限解决的是Agent 当前是否可以对指定目标执行指定动作例如查询某个租户的数据修改某个项目的配置删除某个临时文件向指定收件人发送邮件提交一笔支付发布一项生产变更。这两个权限的风险等级通常不同维度工具连接实际执行主要问题能否访问工具能否改变系统状态风险等级通常较低可能较高授权粒度工具级动作、资源、参数级是否需要审批通常不需要高风险操作可能需要审计重点连接对象和身份动作、目标、参数和结果最基本的权限模型应该避免if can_connect(tool): execute(tool, action)而应该明确拆分if not can_connect(tool): deny() if not can_execute(principal, tool, action, target): deny() execute()三、什么是执行安全不变量执行安全不变量是指在 Agent 执行具体动作之前必须满足的一组条件。它们不是普通的提示词也不是执行后的日志而是可以在运行时被检查、被记录、必要时阻断的约束。一个动作可以抽象为Action { actor: 当前 Agent 或用户, tool: 目标工具, operation: 具体操作, target: 资源目标, arguments: 调用参数, side_effects: 预期副作用, risk_level: 风险等级, context: 当前会话和环境 }执行护栏需要对这个动作进行检查动作请求 ↓ 身份检查 ↓ 目标检查 ↓ 参数检查 ↓ 副作用检查 ↓ 风险和审批检查 ↓ 审计记录 ↓ 允许或拒绝可以将常见不变量归纳为五类。四、五类核心执行护栏4.1 目标必须在授权范围内这是最基础的一条不变量Agent 只能操作当前身份和当前任务被授权访问的目标。例如允许访问 tenant-a/project-1/config.yaml 拒绝访问 tenant-b/project-9/config.yaml目标校验不应该只依赖 Agent 自己生成的字符串。更可靠的做法是将资源标识解析为结构化对象校验租户、项目、环境和资源类型对路径进行规范化防止路径穿越防止通配符扩大授权范围防止通过别名或重定向绕过检查。伪代码示例defcheck_target(action,principal):targetnormalize_target(action.target)iftarget.tenant_id!principal.tenant_id:returnFalseiftarget.project_idnotinprincipal.allowed_projects:returnFalseiftarget.environmentproductionandnotprincipal.can_prod:returnFalsereturnTrue这里的重点是目标授权必须基于结构化属性而不是简单字符串匹配。4.2 操作必须被明确授权同一个工具可能同时暴露读、写、删除和管理操作get_config update_config delete_config rotate_secret不能因为 Agent 可以调用get_config就默认允许调用其他操作。建议为工具操作建立明确的权限矩阵工具操作普通 Agent管理 Agent是否需要审批配置中心查询配置允许允许否配置中心修改配置拒绝允许视环境配置中心删除配置拒绝允许是密钥系统读取密钥拒绝受限是发布系统创建发布单允许允许否发布系统生产发布拒绝受限是授权对象至少应包含主体 工具 动作 资源 环境 时间窗口 审批状态这样才能避免“工具级权限过粗”的问题。4.3 参数必须符合预期约束即使操作本身被允许参数也可能扩大风险。例如一个查询接口允许 Agent 查询订单但不能让它提交任意 SQL允许 查询指定订单号 拒绝 执行任意 SQL参数校验可以包括类型校验长度校验枚举校验数值范围校验正则校验资源归属校验禁止危险字段禁止隐式扩大查询范围禁止将用户输入直接拼接为命令。示例defcheck_arguments(action):ifaction.operationget_order:order_idaction.arguments.get(order_id)ifnotisinstance(order_id,str):returnFalseifnotorder_id.isascii():returnFalseiflen(order_id)64:returnFalsereturnTrue生产系统中还应避免将参数校验全部交给自然语言模型。模型可以提出参数但最终校验应由确定性代码完成。4.4 副作用必须明确且可控副作用是执行控制中经常被忽略的部分。以下操作都可能产生副作用修改数据库写入文件删除资源发送消息创建用户触发部署产生费用修改权限调用外部系统。执行前应明确这个动作会改变什么 改变范围有多大 是否可以撤销 失败后是否会留下中间状态 是否会触发其他自动化流程可以为动作声明副作用等级等级示例默认策略L0纯计算自动执行L1只读查询受范围限制后执行L2写入临时资源自动执行并记录L3修改业务数据需要更严格校验L4删除、发布、支付强制审批或人工确认需要注意可回滚不代表低风险。即使数据库操作可以回滚也可能已经触发外部通知审计事件下游任务计费流程用户可见状态变化。4.5 高风险动作必须满足信任和审批条件Agent 的执行权限应与当前上下文相关而不是永久固定。信任上下文可以包括当前用户身份会话来源任务来源是否经过人工确认当前环境近期行为任务是否发生越权尝试是否存在敏感数据是否超过操作额度。可以使用简单的风险评分模型risk_score action_risk target_sensitivity environment_risk context_anomaly - approval_strength然后按分数决定策略低风险自动执行 中风险二次确认 高风险人工审批或直接拒绝这里的“信任分”只能作为辅助信号不能替代明确的权限规则。高风险动作应优先依赖确定性的授权和审批状态。五、执行控制的最小实现下面给出一个简化的 Python 示例用于说明执行控制的基本结构fromdataclassesimportdataclassfromtypingimportAnydataclassclassAction:tool:stroperation:strtarget:strarguments:dict[str,Any]risk_level:strside_effects:list[str]dataclassclassDecision:allowed:boolreason:strdefauthorize(action:Action,principal:dict[str,Any])-Decision:allowed_toolsprincipal.get(allowed_tools,set())allowed_operationsprincipal.get(allowed_operations,set())ifaction.toolnotinallowed_tools:returnDecision(False,tool is not allowed)operation_keyf{action.tool}:{action.operation}ifoperation_keynotinallowed_operations:returnDecision(False,operation is not allowed)ifaction.target.startswith(prod/)andnotprincipal.get(production_access):returnDecision(False,production target is not allowed)ifaction.risk_levelhighandnotprincipal.get(approved):returnDecision(False,approval is required)returnDecision(True,allowed)实际生产实现还需要增加目标规范化资源级授权参数 Schema 校验审批单绑定幂等性检查超时和重试限制审计日志防重放结果校验失败补偿。这个示例的重点不在于提供完整安全框架而在于体现一个基本原则执行授权必须发生在实际工具调用之前并且授权对象应包含工具、动作、目标和上下文。六、执行护栏应该放在哪里完整的 Agent 调用链可以抽象为用户请求 ↓ 意图识别 ↓ 任务规划 ↓ 工具选择 ↓ 参数生成 ↓ 执行授权 ↓ 工具调用 ↓ 结果校验 ↓ 输出审计其中执行控制至少应覆盖三个位置。6.1 工具选择后检查 Agent 是否有权限使用目标工具。6.2 参数生成后、实际调用前这是最重要的阻断点。此时已经知道使用哪个工具执行什么操作目标是什么参数是什么预计产生什么副作用。如果护栏只在工具注册阶段检查而不在实际调用前再次检查就可能被恶意参数或错误规划绕过。6.3 工具返回结果后执行控制不应只关注“是否允许调用”还应校验返回结果返回数据是否超过授权范围是否包含敏感字段是否出现异常状态是否需要脱敏是否需要阻止继续传递给用户或其他工具。因此更完整的模型是调用前授权 调用中约束 调用后结果检查七、哪些控制适合下沉到 Harness不是所有安全控制都必须放在同一层。适合下沉到 Harness 的控制工具和动作授权目标资源校验参数类型和范围校验敏感字段检查副作用声明校验审批状态检查超时、重试和调用额度调用前审计调用后结果过滤。适合保留在统一控制面的能力全局策略发布角色和权限管理风险规则维护审计日志汇总策略版本管理跨 Agent 行为分析统一告警和事件响应。更合理的架构不是“所有控制都集中”或“所有控制都分散”而是统一策略中心 ↓ 策略下发与版本管理 ↓ 各 Agent Harness 本地执行 ↓ 统一审计与监控也就是策略集中管理控制分布执行结果统一审计。八、为什么不能只告警不阻断对于高风险动作单纯告警往往不足以阻止损害发生。例如Agent 准备删除生产数据库 系统记录一条“高风险告警” Agent 继续执行删除这种设计的安全价值非常有限。建议按照风险等级配置不同策略风险等级示例建议策略低查询公开数据自动执行并记录中修改测试环境配置校验后自动执行高修改生产配置人工确认或审批极高删除资源、转账、发布强制审批必要时双人复核需要注意阻断策略应由确定性系统执行而不是只依赖提示词提示 Agent “不要执行危险操作” 不等于 系统真正阻止危险操作提示词可以帮助模型理解边界但不能作为最终权限控制。九、三个常见错误设计错误一工具连接成功后自动获得全部权限toolconnect(database)tool.execute(DELETE FROM users)问题在于连接、动作和目标没有分层控制。改进方式toolconnect(database)decisionauthorize(tooldatabase,operationdelete,targettenant-a/users,)ifnotdecision.allowed:raisePermissionError(decision.reason)tool.delete(tenant-a/users)错误二只校验工具名称不校验参数iftool_namefile_writer:allow()攻击者或错误规划可能通过参数访问../../production/secrets.env改进方式是对目标路径进行规范化和资源级授权。错误三把模型输出当成可信计划planagent.generate_plan()execute(plan)模型生成的计划必须被转换成结构化动作并经过确定性校验planagent.generate_plan()actionparse_action(plan)decisionpolicy_engine.check(action)ifdecision.allowed:execute(action)else:deny(action,decision.reason)十、如何设计可审计的执行记录每次执行至少应记录以下信息{request_id:req-123,agent_id:agent-support,principal:user-456,tool:ticket_system,operation:update_ticket,target:ticket-789,argument_digest:sha256:...,risk_level:medium,policy_version:policy-2026-08-02,approval_id:null,decision:allowed,result:success,timestamp:2026-08-02T10:00:00Z}日志中不应直接记录明文密码完整 Token私钥未脱敏的个人信息完整敏感请求体。建议使用参数摘要敏感字段脱敏资源标识分级审计日志防篡改策略版本绑定请求链路 ID。这样才能回答后续审计问题是谁让 Agent 做了什么 Agent 在什么上下文中执行 执行前通过了哪条策略 操作影响了什么资源 最终结果是什么十一、执行控制的验证清单企业可以使用下面的最小验证清单进行 PoC。权限隔离连接权限和执行权限是否分开读操作和写操作是否分开测试环境和生产环境是否分开普通 Agent 和管理 Agent 是否分开工具发现权限和工具执行权限是否分开。目标校验是否校验租户是否校验项目是否校验环境是否防止路径穿越是否防止通配符扩大范围是否防止别名或重定向绕过。参数校验是否使用结构化 Schema是否限制长度和类型是否限制枚举值是否拒绝危险参数是否防止命令、SQL 或模板注入。副作用管理是否声明副作用是否对高风险动作强制审批是否支持幂等执行是否配置超时和重试上限是否有失败补偿方案。审计和结果处理是否记录调用前决策是否记录策略版本是否记录审批关系是否过滤敏感结果是否能够关联完整调用链。十二、从“连接控制”升级到“执行控制”一个成熟的 Agent 安全架构可以用下面的分层模型表示第一层身份控制 谁在请求 第二层工具连接控制 可以访问哪些工具 第三层动作执行控制 可以执行哪些操作 第四层目标和参数控制 可以对什么资源、以什么参数执行 第五层副作用和审批控制 是否允许产生当前级别的影响 第六层结果和审计控制 执行结果能否返回是否完整留痕每一层都有自己的职责层级主要目标身份确认主体工具连接限制工具可见性和访问范围动作执行限制具体操作目标参数限制资源和输入副作用审批控制高风险变更结果审计防止数据泄露并支持追溯如果只实现第一层和第二层系统仍然可能存在“能连就能动”的问题。十三、如何接入现有 Agent 工程建议把执行控制封装为独立的 Policy Enforcement Point而不是散落在每个业务函数中。否是Agent Planner结构化 ActionPolicy Enforcement Point是否允许拒绝并审计Tool Adapter目标系统结果过滤与审计一个较清晰的代码边界可以是agent/ ├── planner.py ├── action_schema.py ├── policy_engine.py ├── approval.py ├── tool_adapters/ └── audit.py其中planner.py只负责生成计划action_schema.py负责结构化动作policy_engine.py负责确定性授权approval.py负责人工审批tool_adapters/负责连接外部系统audit.py负责统一审计。这样可以避免让模型直接持有能够改变外部状态的原始客户端。十四、最终结论执行控制是 Agent 安全体系中容易被忽略的一层。核心原则可以概括为能连接不代表能执行 能执行不代表能执行任意目标 目标合法不代表参数合法 参数合法不代表副作用可以自动放行。因此企业在设计 Agent 工具体系时应至少做到将工具连接权限与动作执行权限分离在实际调用前执行确定性策略检查对目标资源和参数进行结构化校验对写入、删除、发布和支付等高风险操作设置审批对工具返回结果进行权限过滤记录主体、工具、动作、目标、策略和结果由统一策略中心管理规则由各 Harness 负责本地执行。最终建议是把安全控制放到每一个真正改变状态的执行点而不是只放在 Agent 的外围入口。边界网关仍然重要但它不应成为唯一防线。更可靠的架构是统一策略管理 分布式执行护栏 调用前阻断 调用后审计这才是从“Agent 可以连接工具”走向“Agent 只在满足安全条件时执行”的关键一步。参考资料《From Tool Connection to Execution Control: Benchmarking Security Invariants…》arXiv2606.29073OWASP 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-frameworkNIST Cybersecurity Frameworkhttps://www.nist.gov/cyberframework 大模型安全实战】智能体安全进阶：为什么“能连接工具”不等于“可以执行操作”（第8期）
【大模型安全实战】智能体安全进阶为什么“能连接工具”不等于“可以执行操作”第8期专栏智能体攻防卷·进阶 第 8 期作者Valhalla Matrix治理实验室主题执行控制、工具授权与安全不变量论文线索《From Tool Connection to Execution Control: Benchmarking Security Invariants…》**说明**本文结合智能体工程实践讨论执行控制模型。文中示例为简化实现不能替代生产环境中的权限系统、审批系统和安全审计。摘要在很多 Agent 系统中工具调用流程通常被简化为用户请求 ↓ Agent 选择工具 ↓ 连接工具 ↓ 执行调用这种设计容易把“可以连接工具”和“可以执行操作”视为同一件事。但在真实业务中读取文档、查询订单、修改配置、删除资源、发送消息和转账操作的风险完全不同。Agent 即使被允许访问某个工具也不应该天然拥有该工具的全部执行权限。更合理的安全模型是连接权限 ≠ 执行权限本文围绕执行控制展开分析工具连接和实际执行之间的安全边界并给出一套可落地的执行安全不变量模型帮助团队将 Agent 安全控制从外围网关下沉到具体动作执行点。一、真正的风险不在“能不能连”而在“能不能动”很多团队首先关注的是 Agent 是否能够连接外部系统是否能访问数据库是否能调用搜索服务是否能使用文件系统是否能访问工单系统是否能调用支付或审批接口。但“连接成功”只说明系统之间建立了通信关系并不代表 Agent 应该执行所有操作。举个简单例子Agent 可以访问订单系统 ≠ Agent 可以取消订单Agent 可以读取数据库 ≠ Agent 可以修改或删除数据Agent 可以调用邮件服务 ≠ Agent 可以向任意外部地址发送邮件如果系统把连接权限直接映射成执行权限就可能出现以下问题只读工具被误用为写操作工具普通查询权限被扩展成管理权限Agent 可以访问授权范围之外的资源高风险动作没有人工确认工具调用失败或参数异常时无法及时阻断日志只记录“调用了哪个工具”没有记录“实际改变了什么状态”。因此Agent 的安全边界不能只设在工具入口还应该设在每一个具体执行动作之前。二、连接权限与执行权限必须分层可以把工具调用拆分为两个不同阶段工具连接 ↓ 动作识别 ↓ 执行授权 ↓ 参数和目标校验 ↓ 实际执行2.1 工具连接工具连接解决的是Agent 是否可以发现并访问某个工具例如获取工具描述建立客户端连接读取工具元数据获取临时会话查询可用操作。2.2 实际执行执行权限解决的是Agent 当前是否可以对指定目标执行指定动作例如查询某个租户的数据修改某个项目的配置删除某个临时文件向指定收件人发送邮件提交一笔支付发布一项生产变更。这两个权限的风险等级通常不同维度工具连接实际执行主要问题能否访问工具能否改变系统状态风险等级通常较低可能较高授权粒度工具级动作、资源、参数级是否需要审批通常不需要高风险操作可能需要审计重点连接对象和身份动作、目标、参数和结果最基本的权限模型应该避免if can_connect(tool): execute(tool, action)而应该明确拆分if not can_connect(tool): deny() if not can_execute(principal, tool, action, target): deny() execute()三、什么是执行安全不变量执行安全不变量是指在 Agent 执行具体动作之前必须满足的一组条件。它们不是普通的提示词也不是执行后的日志而是可以在运行时被检查、被记录、必要时阻断的约束。一个动作可以抽象为Action { actor: 当前 Agent 或用户, tool: 目标工具, operation: 具体操作, target: 资源目标, arguments: 调用参数, side_effects: 预期副作用, risk_level: 风险等级, context: 当前会话和环境 }执行护栏需要对这个动作进行检查动作请求 ↓ 身份检查 ↓ 目标检查 ↓ 参数检查 ↓ 副作用检查 ↓ 风险和审批检查 ↓ 审计记录 ↓ 允许或拒绝可以将常见不变量归纳为五类。四、五类核心执行护栏4.1 目标必须在授权范围内这是最基础的一条不变量Agent 只能操作当前身份和当前任务被授权访问的目标。例如允许访问 tenant-a/project-1/config.yaml 拒绝访问 tenant-b/project-9/config.yaml目标校验不应该只依赖 Agent 自己生成的字符串。更可靠的做法是将资源标识解析为结构化对象校验租户、项目、环境和资源类型对路径进行规范化防止路径穿越防止通配符扩大授权范围防止通过别名或重定向绕过检查。伪代码示例defcheck_target(action,principal):targetnormalize_target(action.target)iftarget.tenant_id!principal.tenant_id:returnFalseiftarget.project_idnotinprincipal.allowed_projects:returnFalseiftarget.environmentproductionandnotprincipal.can_prod:returnFalsereturnTrue这里的重点是目标授权必须基于结构化属性而不是简单字符串匹配。4.2 操作必须被明确授权同一个工具可能同时暴露读、写、删除和管理操作get_config update_config delete_config rotate_secret不能因为 Agent 可以调用get_config就默认允许调用其他操作。建议为工具操作建立明确的权限矩阵工具操作普通 Agent管理 Agent是否需要审批配置中心查询配置允许允许否配置中心修改配置拒绝允许视环境配置中心删除配置拒绝允许是密钥系统读取密钥拒绝受限是发布系统创建发布单允许允许否发布系统生产发布拒绝受限是授权对象至少应包含主体 工具 动作 资源 环境 时间窗口 审批状态这样才能避免“工具级权限过粗”的问题。4.3 参数必须符合预期约束即使操作本身被允许参数也可能扩大风险。例如一个查询接口允许 Agent 查询订单但不能让它提交任意 SQL允许 查询指定订单号 拒绝 执行任意 SQL参数校验可以包括类型校验长度校验枚举校验数值范围校验正则校验资源归属校验禁止危险字段禁止隐式扩大查询范围禁止将用户输入直接拼接为命令。示例defcheck_arguments(action):ifaction.operationget_order:order_idaction.arguments.get(order_id)ifnotisinstance(order_id,str):returnFalseifnotorder_id.isascii():returnFalseiflen(order_id)64:returnFalsereturnTrue生产系统中还应避免将参数校验全部交给自然语言模型。模型可以提出参数但最终校验应由确定性代码完成。4.4 副作用必须明确且可控副作用是执行控制中经常被忽略的部分。以下操作都可能产生副作用修改数据库写入文件删除资源发送消息创建用户触发部署产生费用修改权限调用外部系统。执行前应明确这个动作会改变什么 改变范围有多大 是否可以撤销 失败后是否会留下中间状态 是否会触发其他自动化流程可以为动作声明副作用等级等级示例默认策略L0纯计算自动执行L1只读查询受范围限制后执行L2写入临时资源自动执行并记录L3修改业务数据需要更严格校验L4删除、发布、支付强制审批或人工确认需要注意可回滚不代表低风险。即使数据库操作可以回滚也可能已经触发外部通知审计事件下游任务计费流程用户可见状态变化。4.5 高风险动作必须满足信任和审批条件Agent 的执行权限应与当前上下文相关而不是永久固定。信任上下文可以包括当前用户身份会话来源任务来源是否经过人工确认当前环境近期行为任务是否发生越权尝试是否存在敏感数据是否超过操作额度。可以使用简单的风险评分模型risk_score action_risk target_sensitivity environment_risk context_anomaly - approval_strength然后按分数决定策略低风险自动执行 中风险二次确认 高风险人工审批或直接拒绝这里的“信任分”只能作为辅助信号不能替代明确的权限规则。高风险动作应优先依赖确定性的授权和审批状态。五、执行控制的最小实现下面给出一个简化的 Python 示例用于说明执行控制的基本结构fromdataclassesimportdataclassfromtypingimportAnydataclassclassAction:tool:stroperation:strtarget:strarguments:dict[str,Any]risk_level:strside_effects:list[str]dataclassclassDecision:allowed:boolreason:strdefauthorize(action:Action,principal:dict[str,Any])-Decision:allowed_toolsprincipal.get(allowed_tools,set())allowed_operationsprincipal.get(allowed_operations,set())ifaction.toolnotinallowed_tools:returnDecision(False,tool is not allowed)operation_keyf{action.tool}:{action.operation}ifoperation_keynotinallowed_operations:returnDecision(False,operation is not allowed)ifaction.target.startswith(prod/)andnotprincipal.get(production_access):returnDecision(False,production target is not allowed)ifaction.risk_levelhighandnotprincipal.get(approved):returnDecision(False,approval is required)returnDecision(True,allowed)实际生产实现还需要增加目标规范化资源级授权参数 Schema 校验审批单绑定幂等性检查超时和重试限制审计日志防重放结果校验失败补偿。这个示例的重点不在于提供完整安全框架而在于体现一个基本原则执行授权必须发生在实际工具调用之前并且授权对象应包含工具、动作、目标和上下文。六、执行护栏应该放在哪里完整的 Agent 调用链可以抽象为用户请求 ↓ 意图识别 ↓ 任务规划 ↓ 工具选择 ↓ 参数生成 ↓ 执行授权 ↓ 工具调用 ↓ 结果校验 ↓ 输出审计其中执行控制至少应覆盖三个位置。6.1 工具选择后检查 Agent 是否有权限使用目标工具。6.2 参数生成后、实际调用前这是最重要的阻断点。此时已经知道使用哪个工具执行什么操作目标是什么参数是什么预计产生什么副作用。如果护栏只在工具注册阶段检查而不在实际调用前再次检查就可能被恶意参数或错误规划绕过。6.3 工具返回结果后执行控制不应只关注“是否允许调用”还应校验返回结果返回数据是否超过授权范围是否包含敏感字段是否出现异常状态是否需要脱敏是否需要阻止继续传递给用户或其他工具。因此更完整的模型是调用前授权 调用中约束 调用后结果检查七、哪些控制适合下沉到 Harness不是所有安全控制都必须放在同一层。适合下沉到 Harness 的控制工具和动作授权目标资源校验参数类型和范围校验敏感字段检查副作用声明校验审批状态检查超时、重试和调用额度调用前审计调用后结果过滤。适合保留在统一控制面的能力全局策略发布角色和权限管理风险规则维护审计日志汇总策略版本管理跨 Agent 行为分析统一告警和事件响应。更合理的架构不是“所有控制都集中”或“所有控制都分散”而是统一策略中心 ↓ 策略下发与版本管理 ↓ 各 Agent Harness 本地执行 ↓ 统一审计与监控也就是策略集中管理控制分布执行结果统一审计。八、为什么不能只告警不阻断对于高风险动作单纯告警往往不足以阻止损害发生。例如Agent 准备删除生产数据库 系统记录一条“高风险告警” Agent 继续执行删除这种设计的安全价值非常有限。建议按照风险等级配置不同策略风险等级示例建议策略低查询公开数据自动执行并记录中修改测试环境配置校验后自动执行高修改生产配置人工确认或审批极高删除资源、转账、发布强制审批必要时双人复核需要注意阻断策略应由确定性系统执行而不是只依赖提示词提示 Agent “不要执行危险操作” 不等于 系统真正阻止危险操作提示词可以帮助模型理解边界但不能作为最终权限控制。九、三个常见错误设计错误一工具连接成功后自动获得全部权限toolconnect(database)tool.execute(DELETE FROM users)问题在于连接、动作和目标没有分层控制。改进方式toolconnect(database)decisionauthorize(tooldatabase,operationdelete,targettenant-a/users,)ifnotdecision.allowed:raisePermissionError(decision.reason)tool.delete(tenant-a/users)错误二只校验工具名称不校验参数iftool_namefile_writer:allow()攻击者或错误规划可能通过参数访问../../production/secrets.env改进方式是对目标路径进行规范化和资源级授权。错误三把模型输出当成可信计划planagent.generate_plan()execute(plan)模型生成的计划必须被转换成结构化动作并经过确定性校验planagent.generate_plan()actionparse_action(plan)decisionpolicy_engine.check(action)ifdecision.allowed:execute(action)else:deny(action,decision.reason)十、如何设计可审计的执行记录每次执行至少应记录以下信息{request_id:req-123,agent_id:agent-support,principal:user-456,tool:ticket_system,operation:update_ticket,target:ticket-789,argument_digest:sha256:...,risk_level:medium,policy_version:policy-2026-08-02,approval_id:null,decision:allowed,result:success,timestamp:2026-08-02T10:00:00Z}日志中不应直接记录明文密码完整 Token私钥未脱敏的个人信息完整敏感请求体。建议使用参数摘要敏感字段脱敏资源标识分级审计日志防篡改策略版本绑定请求链路 ID。这样才能回答后续审计问题是谁让 Agent 做了什么 Agent 在什么上下文中执行 执行前通过了哪条策略 操作影响了什么资源 最终结果是什么十一、执行控制的验证清单企业可以使用下面的最小验证清单进行 PoC。权限隔离连接权限和执行权限是否分开读操作和写操作是否分开测试环境和生产环境是否分开普通 Agent 和管理 Agent 是否分开工具发现权限和工具执行权限是否分开。目标校验是否校验租户是否校验项目是否校验环境是否防止路径穿越是否防止通配符扩大范围是否防止别名或重定向绕过。参数校验是否使用结构化 Schema是否限制长度和类型是否限制枚举值是否拒绝危险参数是否防止命令、SQL 或模板注入。副作用管理是否声明副作用是否对高风险动作强制审批是否支持幂等执行是否配置超时和重试上限是否有失败补偿方案。审计和结果处理是否记录调用前决策是否记录策略版本是否记录审批关系是否过滤敏感结果是否能够关联完整调用链。十二、从“连接控制”升级到“执行控制”一个成熟的 Agent 安全架构可以用下面的分层模型表示第一层身份控制 谁在请求 第二层工具连接控制 可以访问哪些工具 第三层动作执行控制 可以执行哪些操作 第四层目标和参数控制 可以对什么资源、以什么参数执行 第五层副作用和审批控制 是否允许产生当前级别的影响 第六层结果和审计控制 执行结果能否返回是否完整留痕每一层都有自己的职责层级主要目标身份确认主体工具连接限制工具可见性和访问范围动作执行限制具体操作目标参数限制资源和输入副作用审批控制高风险变更结果审计防止数据泄露并支持追溯如果只实现第一层和第二层系统仍然可能存在“能连就能动”的问题。十三、如何接入现有 Agent 工程建议把执行控制封装为独立的 Policy Enforcement Point而不是散落在每个业务函数中。否是Agent Planner结构化 ActionPolicy Enforcement Point是否允许拒绝并审计Tool Adapter目标系统结果过滤与审计一个较清晰的代码边界可以是agent/ ├── planner.py ├── action_schema.py ├── policy_engine.py ├── approval.py ├── tool_adapters/ └── audit.py其中planner.py只负责生成计划action_schema.py负责结构化动作policy_engine.py负责确定性授权approval.py负责人工审批tool_adapters/负责连接外部系统audit.py负责统一审计。这样可以避免让模型直接持有能够改变外部状态的原始客户端。十四、最终结论执行控制是 Agent 安全体系中容易被忽略的一层。核心原则可以概括为能连接不代表能执行 能执行不代表能执行任意目标 目标合法不代表参数合法 参数合法不代表副作用可以自动放行。因此企业在设计 Agent 工具体系时应至少做到将工具连接权限与动作执行权限分离在实际调用前执行确定性策略检查对目标资源和参数进行结构化校验对写入、删除、发布和支付等高风险操作设置审批对工具返回结果进行权限过滤记录主体、工具、动作、目标、策略和结果由统一策略中心管理规则由各 Harness 负责本地执行。最终建议是把安全控制放到每一个真正改变状态的执行点而不是只放在 Agent 的外围入口。边界网关仍然重要但它不应成为唯一防线。更可靠的架构是统一策略管理 分布式执行护栏 调用前阻断 调用后审计这才是从“Agent 可以连接工具”走向“Agent 只在满足安全条件时执行”的关键一步。参考资料《From Tool Connection to Execution Control: Benchmarking Security Invariants…》arXiv2606.29073OWASP 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-frameworkNIST Cybersecurity Frameworkhttps://www.nist.gov/cyberframework