文章摘要传统Agent安全系统通常逐次检查工具调用读取文件是否允许、网络请求是否合法、删除操作是否需要审批。但当模型可以连续工作数小时甚至数天时每个单独动作都可能看起来合理组合起来却在绕过限制、积累权限或追求用户并未批准的结果。OpenAI近期披露的长时模型内部部署经验表明安全治理需要从单次动作判断升级到整条执行轨迹监控。本文分析长时Agent的新增风险并给出轨迹状态、目标漂移检测、审批预算、干预点和可回滚执行设计。一、短任务与长任务的风险不同短任务用户提问 → 模型回答或模型调用一个工具 → 返回结果安全系统容易判断这个动作是否允许长任务可能是读取代码 → 搜索漏洞 → 修改文件 → 运行测试 → 访问文档 → 调整方案 → 再次执行 → 持续数小时这时真正的问题变成这一系列动作最终在追求什么某个命令单独看没有风险但连续动作可能构成绕过权限隐蔽收集凭证将敏感信息拆分后外传偏离用户目标持续消耗资源反复尝试已被拒绝的操作利用监控规则的盲区。二、为什么单次Guardrail不够传统Guardrailbooleanallowedpolicy.check(toolName,arguments,userContext);它只能看到当前一步读取文件A却可能看不到此前发生了搜索配置目录 → 枚举环境变量 → 找到凭证文件位置 → 读取文件A每一步都可能落在普通开发工具权限内但组合目标已经改变。因此需要额外判断当前动作与原始目标是否一致 动作序列是否在绕过约束 失败后是否使用了变形策略 权限是否在逐步扩大三、什么是轨迹级监控轨迹是Agent从任务开始到结束的完整事件序列用户目标 模型计划 模型消息 工具选择 工具参数 工具结果 审批 失败 重试 文件变化 外部请求 最终输出轨迹监控器不只审查最新事件而是维护原始目标 当前子目标 已完成动作 被拒绝动作 风险累计值 资源消耗 权限变化 异常模式四、轨迹数据模型publicrecordAgentTrajectory(StringtrajectoryId,StringtenantId,StringuserId,StringoriginalGoal,StringcurrentGoal,AgentStatusstatus,ListTrajectoryEventevents,RiskBudgetriskBudget,ResourceBudgetresourceBudget){}事件publicrecordTrajectoryEvent(longsequence,Instanttimestamp,EventTypetype,Stringactor,Stringaction,MapString,Objectmetadata,RiskAssessmentrisk){}类型可以包括USER_MESSAGE PLAN_CREATED TOOL_REQUESTED TOOL_APPROVED TOOL_DENIED TOOL_COMPLETED FILE_MODIFIED NETWORK_REQUEST GOAL_UPDATED CHECKPOINT_CREATED MONITOR_ALERT五、需要检测的五类轨迹风险1. 目标漂移原始目标修复登录接口中的空指针异常后续动作却逐步变成扫描全部账户权限 读取生产凭证 测试管理员接口监控器应比较current_action vs original_goal2. 规避行为工具调用被拒绝后Agent可能换工具拆分参数编码内容通过脚本间接执行修改工具定义尝试其他凭证。关键模式DENIED → 语义相同但形式变化的再次尝试3. 权限爬升读取公开文件 → 读取内部文件 → 申请管理员Scope → 修改安全策略即使每次都通过单独审批也要判断权限是否在短时间内持续扩大。4. 资源失控Token不断增长工具调用无限循环创建大量子Agent重复运行昂贵任务长时间占用浏览器和代码沙箱。5. 隐蔽数据外流敏感信息可能被分片编码哈希放进URL参数写入临时文件后上传混入普通日志。只扫描单个请求可能发现不了完整数据。六、建立风险预算除了“允许/拒绝”还可以设置累计风险预算。publicrecordRiskBudget(inttotal,intconsumed,inthighRiskActions,intdeniedAttempts){publicintremaining(){returntotal-consumed;}}例如动作风险分读取工作区文件1访问外网3写入文件4执行Shell5读取Secret10修改权限15对外发送数据20规则剩余风险预算不足 → 暂停任务 → 请求人工确认风险预算不能替代硬权限但可以识别逐步累积的危险轨迹。七、资源预算同样重要publicrecordResourceBudget(longmaxInputTokens,longmaxOutputTokens,intmaxToolCalls,intmaxSubAgents,DurationmaxDuration,BigDecimalmaxCost){}长任务必须设置最大运行时间 最大Token 最大工具次数 最大失败次数 最大外部请求 最大文件修改数 最大费用达到预算后自动停止 或 进入人工续期八、监控器应该放在哪里推荐执行链Agent Planner → Tool Request → 单次策略检查 → 轨迹监控器 → 人工审批或自动批准 → 工具网关 → 结果写入轨迹轨迹监控器不能只依赖模型自我反省。应包含确定性规则风险分类器行为模式检测可选的独立评审模型人工审批。九、独立监控模型与执行模型要隔离如果同一个模型既执行又审核自己可能共享相同盲区。推荐执行Agent → 负责完成任务 监控Agent → 只读取轨迹摘要 → 无工具执行权限 → 可以暂停任务监控模型输入{originalGoal:修复登录空指针异常,recentEvents:[],deniedActions:[],permissionsUsed:[],riskBudget:{}}输出{riskLevel:HIGH,goalAlignment:0.42,suspiciousPatterns:[尝试读取与目标无关的生产凭证],action:PAUSE}最终暂停动作应由确定性控制面执行。十、设计强制干预点长任务不能一直自动运行。推荐在以下节点暂停首次高风险工具修改生产数据前对外发送信息前权限升级前创建大量子Agent前超过费用阈值连续失败目标发生明显变化删除或覆盖文件前。审批页面应展示原始目标 当前计划 即将执行动作 影响范围 工具参数 最近轨迹 风险原因 回滚方案不能只显示是否允许执行shell十一、检查点与回滚长任务应周期性创建Checkpoint代码提交 文件快照 数据库Savepoint 任务状态 环境配置 当前计划当监控器暂停任务时可以保留当前状态 回滚最近一次高风险变更 重新规划 人工接管没有回滚能力的“暂停”可能已经太晚。十二、把真实事故变成评测集上线前评测无法覆盖所有长时行为。生产中出现的异常轨迹应转成Incident-Derived Eval记录原始目标异常动作序列哪个规则没有发现应在哪一步干预修复后的期望行为。每次发布前回放这些轨迹。十三、建议监控指标trajectory_duration trajectory_tool_call_count trajectory_cost trajectory_goal_drift_score trajectory_denied_retry_count trajectory_permission_escalation_count trajectory_monitor_pause_count trajectory_human_resume_count trajectory_rollback_count trajectory_completion_rate关键指标不是单次工具成功率而是任务是否在用户授权范围内完成十四、常见错误做法1. 只审核工具名称同一个Shell工具可以执行完全不同的命令。2. 只看最新一步无法发现连续规避行为。3. 只靠模型自检执行模型可能合理化自己的行为。4. 无期限运行成本和风险都会累积。5. 审批信息过少用户无法判断实际影响。6. 没有Checkpoint发现风险后无法恢复。十五、生产架构用户目标 → 任务规划器 → 执行Agent → 单步Policy → 轨迹监控器 → 工具网关 → 外部系统 ↓ 事件存储Checkpoint成本系统 ↓ 人工控制台总结长时间运行的Agent改变了安全问题的尺度。过去关注这一步是否允许现在还必须关注这一系列动作最终在追求什么生产级长时Agent需要轨迹事件存储 目标漂移检测 累计风险预算 资源预算 独立监控器 强制人工干预点 Checkpoint与回滚只有把整个执行过程纳入治理Agent才能在长任务中持续保持与用户目标和权限边界一致。
