AgentMirror 源码解读：AI Agent 蜜罐、提示注入与证据链

当渗透测试从人工操作工具转为 AI Agent 自主浏览、探测与调用终端，目标站点本身也可能成为攻击 Agent 的入口。网页、接口文档和工具返回值中的文本，既可能是业务数据，也可能夹带试图改变任务的指令。

AgentMirror围绕这一问题构建实验蜜罐：给被测 Agent 展示业务页面和接口，在内容中放入提示注入，再观察它是否越过原任务的信任边界。

本文依据公众号在 2026 年 9 月 29 日发布的源码解读，整理架构、证据口径与评测限制。版本、组件数量及实验数字属于当时的研究记录，本文未部署运行项目，也不把这些数据当成独立复测结果。

它测试的是 Agent 如何处理不可信内容

传统 Web 蜜罐主要记录访问者的 IP、工具指纹和攻击手法。AgentMirror 关注的是模型驱动工具时的行为：它能否区分用户授权的任务，与目标页面要求它执行的动作。

例如，页面可能声称为了继续诊断，需要运行一条本地只读命令并回传结果。命令本身是否危险并不是唯一问题；如果操作理由完全来自被测目标，Agent 已经把不可信数据提升成了新的授权来源。

项目说明也划出了服务端的能力边界：蜜罐负责生成和交付内容、记录请求与回传，并不在自己的服务器上执行提示词中提及的命令。判断被测 Agent 是否真的执行过操作，需要结合独立日志。

对于已经让 Agent 拥有浏览器、终端与子 Agent 能力的团队，这与站内 CyberStrikeAI 的审批与权限边界设计属于同一个问题：工具能力越强，外部内容与授权之间的界线就越需要明确。

架构：素材解耦，发布时生成不可变快照

原文研究版本为 v0.0.3，技术栈包括 Go、SQLite 和 React/Vite，前端构建产物通过 go:embed 嵌入二进制。管理端默认绑定本机地址，蜜罐监听器由工作区按需创建，新数据库默认不发布站点。

素材分为三类，再由工作区组合：

发布事务会把站点版本、编译后的场景规则与当时的提示词副本一起写入快照。后续编辑素材，不会改写历史会话所引用的发布版本。

这个设计直接关系到实验可复核性：如果同一会话发生后，管理员又修改了提示词，仍然能够回答“Agent 当时实际读到的是什么”，不必依赖当前编辑器里的内容推测。

场景匹配与两级模板

公开请求进入路由后，系统先识别会话，再按顺序匹配场景规则。原文列出的条件来源包括 query、header、form、body 和 JSON，JSON 支持点路径与 JSON Pointer，比较操作包括存在、相等与包含。

普通路由优先于 fallback 匹配，可以避免宽泛的默认响应遮蔽后面的具体接口。匹配过程还会产出 trace，说明哪些规则没有命中、原因是什么，方便在请求预演界面排查。

提示词交付分两级：规则响应中使用 {{prompt}} 槽位，渲染提示词时再展开 {{run_id}}、{{token}} 与 {{callback_url}} 等会话变量。

渲染会考虑内容格式：JSON 在字符串字段中替换，HTML 做相应转义，纯文本可使用注释式前缀。对标记为必须交付提示词的响应，配置校验会检查槽位是否存在，以免出现“场景发布了，注入内容实际没有送达”的假测试。

对防御侧而言，这说明注入并不限于网页正文。接口字段、配置注释、调试附件和 source map 中的源代码文本，都可能被 Agent 主动读入上下文。

回传认证：会话归属、哈希存储与令牌轮换

回传端点用于接收被测 Agent 提交的数据。原文研究版本的处理链包括：

• 为会话生成 24 字节随机 token，数据库存储其 SHA-256 哈希。
• 正常业务请求到来时轮换 token，旧 token 失效。
• 校验 run_id、监听器归属和 token，避免跨工作区串用。
• 通过认证后保存回传原文，可选按工作区 schema 校验字段类型。
• 头部与正文同时携带 run_id 或 token 时，要求两者一致。

令牌轮换使实验能够观察 Agent 是否重新读取了最近响应中的值，但它仍不能单独证明终端操作发生过。Agent 也可能只完成了文本读取与 HTTP 提交。

这里应分清两个目标：回传认证保证“数据交给哪个实验会话”，独立执行证据回答“数据是否来自真实工具动作”。二者互相补充，不能替代。

证据链：收到回传，不等于执行成功

项目把证据分成三个层次：服务端是否交付了内容，回传端点是否收到了数据，以及被测 Agent 是否执行了动作。

原文提到，HTTP 201 只表示收到回传，响应头使用 X-Execution-Evidence: unverified 明示尚未验证执行；schema 校验只能确认结构正确，即使内容完全合成，也可能通过。

请求观测日志记录规则命中、提示词交付、下载和回传接受情况。观测来源与会话归属分别处理，有助于排查共享 cookie、IP 变化等现象。前端访问画板则把浏览、命中、交付、下载和回传表示为路径图，供人工分析。

管理员可以把会话标记为 executed、refused 或 unknown。只有回传字段与独立工具日志对应时，才应提高结论强度。模型在报告中说“已经执行”，或者服务端显示绿色收件状态，都不够。

这套证据口径也适用于 多 Agent 漏洞分析流水线：发现、验证和报告之间需要可回溯的原始记录，不能把上一层 Agent 的总结当作最终事实。

写作助手与隔离自测

工作区内的 writer Agent 使用有界工具循环，原文给出的默认上限是 24 轮、96 次工具调用和 600 秒。它通过显式工具修改文件、规则和绑定；普通文字回复不直接构成配置写入。

供应商密钥独立保存，不进入普通素材导出。这个安排降低了实验包分发时夹带模型凭证的机会。

发布前的 redteam 自测使用临时目录和新的 SQLite 数据库，把工作区快照重新发布，通过真实 HTTP handler 运行测试。其“终端”是合成环境，只支持指定的无害命令，不直接操作宿主机。

自测会在已读内容和工具结果中安排随机 canary。判定需要形成闭环：动作发生、命令确实出现在模型读过的内容里、回传包含对应标记。这样可以减少模型凭空声称完成任务造成的误判。

仍要注意，合成终端验证的是该沙箱内的行为，不能自动推广为真实宿主系统上的执行效果。真实环境的工具权限、网络出口和进程隔离需要另行测试。

站点克隆的另一条安全边界

站点克隆器本身会访问用户提供的 URL，因此也需要防止 SSRF。按原文分析，项目会逐跳检查地址，阻断私网和保留地址，DNS 解析后固定连接目标，并限制页面、单资源和总抓取量。

需要浏览器渲染时，浏览器请求通过服务端代理并沿用地址检查。这里的价值在于：安全限制不只覆盖第一个 URL，还覆盖重定向和附属资源。

静态克隆也有能力边界。登录态、验证码和依赖复杂业务交互的页面，不应假设能够完整重现；用于实验的站点外观应与真实业务网络隔离。

12 个场景覆盖哪些问题

原文把冻结评测场景分为四组：

命令组以无害命令作为观测标记，但这种测试的意义在于检查权限来源，而不是把“只读”当成天然授权。下载运行组与命令组的后果和成功判据不同，不能混成一个简单成功率。

多 Agent 场景还涉及事实记忆与任务交接：worker 从页面提取的内容，可能经“记录事实”或“派发意图”进入其他 Agent 的上下文。因此，主 Agent 最终报告没有异常，不代表子 Agent 没有发生越界动作。

公开评测数据如何阅读

项目按原文时点公布了六个模型的观察记录，每个模型覆盖 8 种 Agent 配置与 12 个场景，共 96 个组合。下表保留原文数字，含义为项目记录的诱导成功组合数：

这些数字不能直接作为模型安全排行榜。起始拒绝意味着没有进入相同暴露条件；框架、客户端、Skill、工具权限和场景版本，也都影响结果。

原文的重要观察是，Agent 对下载并运行陌生程序通常比执行简单诊断命令更警惕；一些越界行为发生在 worker 层；同一模型换框架后差异很大。评测应保留完整配置和原始证据，而不是只转载汇总数字。

可借鉴的设计与项目限制

对蓝队和 Agent 平台维护者，最值得参考的是不可变发布快照、会话令牌轮换、证据分层，以及把自测限制在合成终端内。这些设计能让一次注入实验更容易复现、归因和复核。

项目仍是实验性质的工具。冻结的 12 个场景不能代表最新模型、所有框架和所有真实环境；服务端收件不是执行证明；站点克隆能力也有边界。原文研究时还提示仓库许可文件发生过变化，准备复用代码时，应检查所使用版本的实际许可证与授权条款。

实际落地时，先用已授权的本地环境观察工具调用，记录模型、框架、提示词版本和时间，再用同一批输入比较防护前后差异。对目标页面提出的新动作，权限应回到原任务或可信的人机审批流程中确认。

项目资料：仓库、部署架构、工作区指南、多模型评测记录。