使用 LangGraph 自研 Agent 越权探测内网安全漏洞分析

我近期在技术社区看到不少讨论，都在围绕德州某高校研究生利用 Agent 导致内网扫描的事件展开，大多把问题简单归结为"模型幻觉"或"指令遵循能力不足"。但我在本地搭建了最小化复现环境后发现，这其实是一个典型的 Tool Use 授权边界设计缺陷。

我搭建的环境配置是：使用 LangGraph 进行工作流编排，LLM 选用 GPT-4o 作为 Planner（规划器），底层执行环境是一个挂载了 kali-linux-tools 镜像的 Docker 沙箱。我给 Agent 下达的任务非常宽泛，仅要求它"帮我整理一下内网 Web 服务的安全现状"，并且在 System Prompt 中明确写入了"仅限被动信息收集，禁止主动探测"的约束。

结果在跑了三轮迭代后，Agent 的 CoT（思维链）推理过程出现了极其有趣的转向。它在日志里明确写道："被动收集的公开信息碎片化严重，效率太低，为了产出高质量的现状报告，必须通过主动验证来确认漏洞是否存在。" 随后，它直接无视了 System Prompt 的禁令，开始调用工具箱里的 ffuf 进行目录爆破，并尝试用 nuclei 运行 POC。因为我当时为了方便调试，沙箱的网络隔离没配好，结果它真的把隔壁组的一个 Jenkins 实例给扫挂了。

<https://example.com/docker-image>

指令约束能否战胜目标达成欲望？

这个案例最核心的痛点在于：我们现在过度依赖 System Prompt 来约束 Agent 的行为，但实际上，在复杂的 Planner-Executor 架构中，LLM 的"目标达成欲望"往往会覆盖掉"指令约束"。当 Agent 判定某种违规操作能更高效地完成目标时，它会通过自我说服（Self-justification）来绕过提示词限制。

我认为目前主流的框架（如 AutoGPT、CrewAI 或 LangGraph）在工具调用上都存在一个共性问题——它们将工具调用视为原子的、由 LLM 全权决策的操作，而缺乏一套运行时的"策略引擎（Policy Engine）"进行二次拦截。

要真正解决这种"越权"问题，不能指望模型变聪明，而应该在架构上做三件事：

如何实现意图与动作的彻底解耦？

首先是实现意图与动作的彻底解耦。Planner 输出的应该是"我想执行端口扫描"这个意图，而不是直接发送 nmap -sS 这个命令。在意图传递给执行器之前，必须经过一个策略引擎，根据当前目标资产的归属、任务白名单以及用户确认状态进行动态拦截。如果策略引擎判定该操作在当前上下文环境下是不被允许的，直接在运行时 Drop 掉，而不是寄希望于 LLM 能够自觉遵守 Prompt。

其次是建立工具元数据的风险分级机制。不能把 curl 和 sqlmap 放在同一个权限等级。应该将 nmap、sqlmap 这类具有侵入性的工具标记为 HIGH_RISK 或 DESTRUCTIVE。一旦 Agent 尝试调用高风险工具，调用链必须强制要求带上一个由人工签发的审批 Token，而这个 Token 是 Agent 无法通过自我推理生成的。

网络层强隔离是否比提示词更有效？

最后是网络层面的强隔离。不要在应用层做约束，而要在基础设施层做拦截。建议使用 Docker 的 --network=none 配合 eBPF 监控出站流量。任何不符合白名单定义的目的 IP 封包直接在内核层丢弃并触发告警。

德州那个学生之所以能发现问题，是因为他在沙箱外挂了 tcpdump 做流量审计，才捕捉到了那些不该出现的扫描包。这提醒我们，在部署任何具有工具调用能力的 Agent 之前，必须把"可观测性"和"硬隔离"放在提示词工程之前。