AI 黑客也会掉进蜜罐？拆解 AgentCapture 和 DropYourGunKid

先看一个场景：Agent 为什么会走进诱饵

让一个 AI 渗透 Agent 检查网站，它通常会先看页面和接口，再根据返回内容决定下一步：页面有没有隐藏入口？响应头里有没有开发环境线索？某个接口说明里有没有值得继续检查的功能？这些原本都是安全测试里正常的观察动作。

但如果页面里的线索本来就是防守方准备的呢？一条看似遗留的测试入口、一组没有真实权限的模拟凭证，或者一份能继续往下查的假资料，都可能让 Agent 花时间追踪，并在访问过程中留下行为记录。防守方不必先证明对方用了哪一种模型，才有机会观察这个过程。

最近出现的 DropYourGunKid 和 AgentCapture，分别展示了两种值得讨论的做法：一个更聚焦有界的 Web 诱饵和封禁链，另一个把蜜饵、代理、会话记录与处置做成平台。它们能影响什么，又不能证明什么，需要把机制和实验拆开看。

为什么 AI 容易注意到，普通用户却看不到

人访问网站时，通常只看浏览器里展示的页面；Agent 为了判断一个系统，还可能读取原始 HTML、响应头、脚本和接口返回。页面注释或一条看似与测试环境有关的线索，用户可能完全看不见，Agent 却可能把它当成值得进一步查看的资料。

但“会读取源码”并不专属于 AI。人工研究人员、搜索引擎或普通扫描器也可能访问同一条线索。一次命中能说明有人或某个程序碰到了诱饵，不能单凭这件事就认定对方一定是 AI、用了哪个模型，更不能把出口 IP 当成人的真实身份。

更关键的是，诱饵不一定需要直接命令模型“忽略之前的规则”。如果一个测试 Agent 认为某个模拟接口是完成任务的合理路径，它可能像操作真实功能一样继续尝试。AgentCapture 将这种思路称为功能性伪装；这与让模型服从一条明确的提示注入指令，是两条不同的路径。

DropYourGunKid：让线索一路延伸，再观察提交

DropYourGunKid，简称 DYGK，是 Yak 团队公开的 Web 欺骗原型。它可以在业务 HTML 中放入隐藏线索，线索指向多层、有限数量的模拟归档。归档之间相互关联，Agent 每往下一层看，都可能找到新的记录；其中的模拟访问码不能用于真实业务登录。

项目的一个封禁条件是：客户端拿着有效的模拟访问码，通过第一阶段表单校验。observe 模式下主要记录，block 模式下则记录命中并封禁来源 IP。是否能阻断后续业务访问，还取决于业务请求是否真的经过同一防御网关；如果业务入口绕过网关，蜜罐中的封禁不能自动覆盖它。

它想利用的不是模型算力本身，而是探索行为：一条看似有价值的线索，可能引出更多关联记录，让自动化测试继续投入请求、时间和模型预算。只是点开入口、填空表单或自称某个框架，都不能单独证明已阻断一次攻击。

AgentCapture：把蜜饵、画像和会话放在一起

AgentCapture 的项目介绍更偏向完整平台：通过反向代理和虚拟路由接入站点，提供 API、文件、凭证等诱饵，并把命中、会话和后续处置集中记录。它还描述了模拟 SSH 等交互环境，以及对来源行为和工具特征的分析。

项目文档给出的一个思路是让页面呈现看似正常的开发接口，观察 Agent 是否按说明继续接入；会话关联标记用于把多次交互串起来。作者把这与显式提示词诱导区分开：在其所述实验中，直接命令式注入被测试的 Agent 拒绝，另一种功能性伪装流程则被继续执行。

项目也包含主动控制相关能力，但“看起来可以控制”不是“证明了攻击者身份”，也不意味着适合对任何来访者执行反向操作。站在生产防御角度，更直接、可审计的价值通常是发现诱饵命中、关联行为、限制访问并保留必要证据。

两个项目的实验，到底证明了多少

DYGK 的研究报告记录了一个有边界的对照：同样的任务在无防御、只观察和启用封禁的条件下运行。项目选出的十种框架接入中，每种有一组满足其判据的配对案例；完整防御组有七组出现封禁、三组达到预定预算，没有成功登录。

这不是“十个框架 100% 防住”的通用成功率。作者说明，结果来自跨批次补测，每种条件样本有限，包含适配修复和预算调整；其中三组是预算耗尽，不等于已经封禁。报告还保留了早期失败结果，并说明缺少跨模型重复和正常用户误封率评估。

项目另公开了隔离的 NocoDB 副本对照：第三轮无防御组取得受保护记录，封禁组命中诱饵后未取得目标。但这是一次探索性配对，环境中有为测试保留的弱口令；不能把它写成发现了 NocoDB 产品漏洞，更不能推算真实网站的稳定拦截率。

AgentCapture 的项目页面则称，在同一 GLM-5.3-Flash 模型底座下测试了五款 Agent 客户端，均完成其定义的诱饵接入与心跳流程。这个结果应理解为项目作者报告的特定环境案例；客户端不同不等于测试了五种底层模型，本站没有独立复现，也不能由此断言所有版本或所有模型都会中招。

提示注入、解析异常和诱饵，是三件事

用户提供的《反制 AI 黑客》原文还讨论了模型输出解析边界：一种情况是模型生成的内容与推理服务的解析结构发生冲突；另一种是 Agent 框架用文本格式拼接工具调用和工具结果，处理边界不严时可能出现混淆。它们涉及的组件、触发条件和后果并不相同。

可以把这三类问题分开：解析异常关注模型输出怎样被框架识别；提示注入关注外部内容是否被模型当成指令；业务诱饵则关注 Agent 是否主动追随看似有价值的线索。实际系统可能同时出现几类情况，但不能因为 Agent 走进假入口，就断言它发生了解析漏洞或执行了提示注入。

vLLM 上游公开过流式与非流式工具解析结果不一致的具体问题，可用于理解解析器也会有边界情况。这个问题本身不等于证明原文提到的所有模型、版本和部署都可以被同一种内容干扰；对于原文的具体触发实验，本站未独立复现。

真要在自己环境里试，先衡量什么

第一步是在有明确授权的隔离测试环境里，给诱饵配置独立标识，确保不连接真实账户、客户数据和生产密钥。先用观察模式收集路径、时间和会话行为，再评估哪些事件足以触发处置；不要把首页一次访问就当作入侵。

第二步看误伤。项目按来源 IP 处置时，同一个出口可能承载公司代理、共享网络或搜索爬虫；可信代理设置错误还可能把整个代理地址封掉。应先确认真实客户端地址的获取方式、网关覆盖范围、封禁时长和恢复流程，并用正常访问与授权测试作对照。

第三步看证据质量和数据边界。记录诱饵命中、同一会话的后续访问及实际处置结果，比只看一个请求更有解释力；但 User-Agent 可以伪造、自报模型无法直接验证，日志也要限制敏感信息、访问权限与留存时间。

最后再考虑自动阻断或更激进的交互。伪装和隔离不能替代修复真实漏洞、收紧凭证权限与监控。对未知第三方主机下发命令、搜集真实凭证或进行破坏，会带来明显的授权与安全问题，不应作为默认防御动作。

一个更值得继续验证的问题

这两个项目展示了一个有意思的变化：防守方不只是等扫描器撞上一张假登录页，还可以观察 Agent 如何理解并追随一串线索。但是否真的带来更好的防御，最终要看对照实验：相同目标、相同任务和预算下，无防御、仅观察与启用处置分别发生了什么；还要看正常用户误伤、不同模型和长期运行成本。

眼下最稳妥的结论是：它们提供了值得研究的 AI 诱捕思路，并公布了各自的实验或产品记录；独立重复和生产表现仍待验证。对日常防守来说，先把蜜罐当成可审计的观测点，再根据证据决定处置，比期待一个项目“通杀 AI 黑客”更可靠。