D-CIPHER Paper Read
D-CIPHER 是一个多 Agent 框架用于进攻性安全
特点
- 具有不同角色的 Agent,通过多个 LLM 代理的协作
- 引入自动提示 Agent,通过自动生成高度相关的初始提示来改善问题解决
- 引入规划者执行者代理系统,包含一个规划者和多个执行者,以分配责任并增强对复杂问题的长期关注
- 通过动态反馈循环来增强对复杂任务的推理能力
Benchmark
Claude 3.5 Sonnet 又遥遥领先了
D-CIPHER 在三个基准上实现了最先进的性能:在 NYU CTF Bench 上为 22.0%,在 Cybench 上为 22.5%,在 HackTheBox 上为 44.0%
这里有一个有趣的现象 D-CIPHER 在没有 auto-pompter 且使用 Claude 3.5 Sonnet 的情况下 PWN 赛道大幅超过了具有 auto-pompter 的 D-CIPHER,但是在使用 GPT4o 时 具有 auto-pompter 的 D-CIPHER 要更优。
架构
D-CIPHER 工作在容器环境上由 Auto-prompter Agent,Planner Agent 和 Executor Agent 协作完成任务
工作流程
-> AutoPromptAgent开始执行他会先进行初始化探索然后动态的生成提示
-> Planner Agent 进行Planner进行初始化探索
-> 直接提交 End.
-> 放弃 End.
-> 委派具体Task给Executor Agent (Planner Agent 保持整体上下文推动Task 完成,根据Executor 反馈修订计划)
-> Executor Agent 执行Task并返回总结(Executor Agent 使用新的上下文,专注执行被委托的Task)
这个架构挺有意思的我之前想的是将 浏览器、命令解释器、Code 解释器 作为独立的 Agent 然后作为工具完成任务然后摘要,模仿的是人渗透测试中使用的工具然后交叉使用完成小任务的方式最终完成大任务的方式 这样上下文也隔离掉了能够起到压缩上下文的能力然后由一个 Planner Agent 统一调度。
最开始看到他是一个多 Agent 且带规划的时候就感觉会不会将一个简单任务变复杂了。本来几步就能过完成的看下来他这个 AutoPromptAgent 和 Planner Agent 都会自主探索 简单任务在这一步应该就能够直接收敛掉了。 然后规划时也做了调查应该不会存在规划时和某些脚不着地的领导一样臆想。 导致的领导动动嘴下属跑断腿最后任务没完成的情况了。
上下文管理
上下文内容
- 设置 Agent 角色提供 Act 的系统提示
- 描述环境和任务的初始提示
- Agent actions 和 observations 的对话历史,遵循 ReAct 策略 提示 LLM 进行推理并产生一个系统。Act 通过 LLM 的 Func Call 来产生,所以并没有定义自己的结构格式,依赖 LLM 的 API 来正确解析 Act。
上下文压缩
在每次 React 迭代中对话的历史将发送给 LLM,从而生产一条包含推理和 Act 的消息。
Act 执行后的结果被附加到对话历史中。生成的推理、行动和相应的观察构成了一轮对话。Agent 继续进行循环执行直到上下文满为止,为了避免上下文填满 D-CIPHER 将观察结果截断为 25000 个字符。 除此之外论文中还提到了可以选择在最后几轮之外节点所有的 Act 和观察,同时保持推理的完整性类似EnIGMA
可以说几乎没有对上下文进行压缩过,只有对多 Agent 的上下文相互隔离。
环境和 Tools
所有的 Agent 工作在同一个容器运行时支持网络访问
工具
- RunCommand 执行 shell 命令
- CreateFile 创建文件
- Disassemble 和 Decompile 触发 Ghidra
EnIGMA 对交互式工具实现了高级接口 而在 D-CIPHER 这里专门的逆向工程工具为代理提供了访问 Ghidra 的权限
D-CIPHER 还提供了 Agent 之间的特殊操作
- GeneratePrompt 让 AutoPromptAgent 生成提示;
- Delegate 让 Planner Agent 委派任务;
- FinishTask 让 Executor Agent 终止并返回任务摘要。 也就是 Agent 之间也是可以互相调用的
Auto-prompter Agent
和经典的提示词重写不同,Auto Prompter Agent 会运行命令与 CTF 环境进行几轮交互,以访问 ctf 环境、读取或执行 ctf 文件基于这些探索然后通过 GeneratePrompt 工具生成一个针对该 CTF 挑战定制的提示,以下是 Auto Prompter Agent 通过几次探索后为硬编码的 ctf 挑战量身定制的提示词。 硬编码通常只提供了通用的方向无法对 ctf 挑战进行定制。
Planner-Executor system
Planner Agent 使用 Auto Prompter Agent 生成的提示进行行动,并在 CTF 环境中探索几轮。 他被提供了 RunCommand,但是没有 CreateFile 等其它工具,这允许探索,但不鼓励他自己解决 CTF。
它制定一个逐步计划,通过 Delegate 将任务委派给 Executor Agent。执行者以任务细节启动,通过运行命令和创建脚本来执行任务,之后通过调用 FinishTask 并提供任务摘要和结果。摘要作为结果返回给 Planner Agent,Planner Agent 利用这些信息接续修订其计划并委托进一步的任务。
对于每一个任务委托,框架会启用一个新的对话历史给 Executor Agent。 D-CIPHER 会运行多个异构 Executor Agent 来解决一个挑战,每个 Executor Agent 都只专注于完成自己的任务。而 Planner Agent 只能看到任务的摘要从而完成高效的上下文管理。
以下是 Planner Agent 解决 collision_course CTF 的一个示例。 基于 Auto Prompter Agent 生成的提示和自身进行的探索,Planner Agent 首先将 破解 hash 盐的任务委派给暴力破解。第一个 Executor Agent 成功实施了暴力破解攻击并将任务摘要和哈希盐返回给规划者。然后 Planner Agent 推理委派下一步使用盐解密密码,第二个 Executor Agent 执行了解密脚本。成功执行脚本后 得到 Flag 解决了 CTF。
这个例子展示了 Planner Agent 如何关注整个挑战,而每个 Executor Agent 则关注单一任务。确保了 Planner Agent 和 Executor Agent 之间的持续互动,使他们能够协作以增强解决问题的能力。
Agent 约束
- 对于每个 Agent,D-CIPHER 定义了一个最大对话轮次,当超过该轮次后 Agent 将被停止。且还设定了所有代理的最大成本限制。
- 在所有的 Agent 中 只有 Planner Agent 可以使用 SubmitFlag 或 Giveup 工具使其成为 D-CIPHER 的核心代理
Agent 终止条件
- 当 SubmitFlag 被调用并且 Flag 正确(如果提交的 Flag 错误将返回负面响应,解决过程可能会继续)
- Giveup 被调用
- Planner Agent 耗尽最大对话轮次 或达到成本限制
Auto Prompter Agent 和 Executor Agent 有时会通过只执行命令造成最大对话轮次被耗尽,未能通过调用 GeneratePrompt 或 FinishTask 为 Planner Agent 生成输出, 在这种情况下,会最后一次 Agent 提示并坚持生成输出。
如果 Auto Prompter Agent 失败,将使用硬编码提示。如果 Executor Agent 失败,将返回硬编码警告。为了提高专注度并避免超出 LLM 上下文,我们截断执行器的对话历史,仅保留最近的操作和观察。
相关工作
摘抄自论文
- InterCode-CTF: 显示 LLM 代理展现了基本的网络安全技能,但在更复杂的任务上表现不佳。
- NYU CTF Base Agent: 集成了外部工具,并展示了工具辅助的 LLM 在解决 CTF 方面的潜力,然而当命令输出历史增长时,该代理耗尽了 LLM 的上下文长度。InterCode-CTF 通过截断历史到最后几次迭代来管理这一问题。即便如此,代理在处理较长任务时仍面临问题。代理在使用一组专注的、界面定义良好的工具时表现更佳
- EnIGMA 结合了交互式工具、上下文学习和 LLM 摘要器进行上下文管理,以实现最先进的结果。
- HackSynth 使用迭代规划和反馈摘要阶段,帮助完成多个任务并改善整体问题解决能力。同样,
- Cybench 引入了一个包含 40 个 CTF 的基准,增强了逐步任务,专注于每个较小任务的 LLM 代理。
- Hacking CTFs with Plain Agents 通过实施计划和解决提示,扩展了 InterCode-CTF,显著提高了 InterCode-CTF 基准。这些工作突显了 LLM 代理在提供动态反馈和任务特定工具集时,能够出色地实现代码和执行命令以完成小型具体任务。虽然这些工作涉及多个具有不同任务(如规划和总结)的 LLM 与主代理协作,但 D-CIPHER 是首个为 CTF 制定多代理系统的工作,具有责任分工和明确的动态反馈交互。
附录
参考文章
版权信息
本文原载于 not only security,复制请保留原文出处。