当大模型 API 成为越来越常见的公网服务接口后，攻击者的探测目标也发生了变化：
他们不再只盯着 SSH、数据库和 Web 后台，也开始寻找 OpenAI 风格接口、Ollama 服务、工具调用入口，以及各种可能被滥用的 AI 能力。
HiveAI 这篇论文做的事，就是专门搭建一套“面向大模型 API 的蜜罐系统”：它把自己伪装成多个常见的大模型服务，专门用来吸引、记录和分析真实世界中的攻击行为。
https://link.springer.com/article/10.1007/s10207-026-01307-0
更有意思的是，作者还进一步解决了一个新问题：当我们用大模型去分析攻击日志时，攻击者也可能把恶意指令写进日志里，反过来攻击“负责分析攻击的大模型”。
因此，HiveAI 不只是一个 AI 蜜罐，更是一个“防止安全分析器被反向攻击”的完整系统。
如果用一句最通俗的话来概括这篇论文，那么它讲的是这样一件事：
先搭几个看起来像真的大模型接口，把攻击者吸引过来；再用一条自动化分析流水线，把这些攻击行为变成结构化情报；最后还要保护这条分析流水线本身，不让攻击者借着日志继续往后打。
整个系统的价值，不只在“看到了哪些攻击”，更在于它把“AI 服务的诱捕、分析和自我防护”第一次比较完整地串了起来。
为什么今天需要“面向大模型 API 的蜜罐”
传统蜜罐大家更容易理解：比如做一个假的 SSH 服务、假的数据库服务、假的工业控制接口，让攻击者误以为这是一个真实目标，从而主动暴露自己的攻击手法。
HiveAI 的思路是把这个逻辑搬到 AI 时代：既然今天很多应用都把大模型能力暴露成 API，那么攻击者自然也会把这些接口当成新的目标。
这里有一个很关键的背景变化。
传统网络安全设备，比如入侵检测系统、WAF、防火墙，通常更擅长看网络层和 HTTP 层的行为：端口开没开、请求路径是什么、有没有典型漏洞特征。
但针对大模型 API 的攻击，很多真正有价值的信息并不在“包长”“端口”或者“HTTP 方法”里，而是在请求内容的语义里。
比如一段请求表面上只是正常的 HTTPS 和 JSON，但里面可能藏着提示词注入、越狱链、模型枚举、工具调用探测，甚至是想借助 AI 服务继续做横向利用的内容。
这类行为对于传统安全设备来说，往往是“看得见流量、看不懂意图”。
因此，HiveAI 的出发点很明确：如果你想真正观察 AI API 面临的真实攻击，就不能只看网络层，还得把语义层一起看进去。
这也是它与很多传统蜜罐系统最大的不同。
三层结构：外层诱捕，中层分析，右侧展示
HiveAI 整体上可以理解成一个非常清楚的三层结构。
你可以把它想成一个“前店、后厨、橱窗”式的设计：最外面是专门吸引攻击者的假接口，中间是内部分析工厂，最后是给研究者或防守方看的只读展示层。
1. 第一层：公开诱捕层
最外层是一个公开暴露在互联网上的诱捕区。
作者在这里模拟了五类常见的大模型服务门面，分别对应 OpenAI、Claude、Ollama、HuggingFace，以及一个偏 Agent 风格的 ClawBot。
它们并不一定真的具备完整的大模型能力，但在协议上会尽量表现得像一个真实服务，让攻击者愿意和它交互。
这层的作用很像“街边的假门店”：攻击者从外面看，会觉得这是一批真正可用的 AI 服务，于是就会来试探、探测、扫描、投递 payload。
系统在这里记录下最原始的攻击输入，包括请求路径、请求体、访问频率、调用方式等。
作者之所以一次放五个门面，而不是只做一个 OpenAI 或 Ollama 蜜罐，是因为真实攻击者通常不会只测一种接口，而是会围绕同一台机器，把多种 AI 服务都扫一遍。
单一门面只能看到一个切面，多门面才能看到完整轨迹。
2. 第二层：内部分析层
所有从外层诱捕到的数据，都会进入中间这一层。这里是真正的“后厨”，负责把原始攻击流量一步步加工成可理解的安全情报。
作者在中间放了消息系统、采集器、数据库，以及一个专门的 AI 威胁分析器。
这一层的设计重点有两个。
第一个重点是职责拆分清楚：前面先做快而稳定的规则和统计处理，最后再让大模型介入；
第二个重点是隔离：真正负责威胁分析的模块并不直接暴露给公网，而是放在内部网络里，减少被直接打到的风险。
论文里还给多个容器加了只读文件系统、最小权限、资源限制等措施，体现出比较典型的“默认不信任”思路。
3. 第三层：公共展示与只读接口层
最右边这一层更像是“橱窗”。
它不是拿来执行分析任务的，而是把结果以地图、统计图、只读 API 的形式展示出来，方便研究者、分析人员或者其他系统查看。
它与中间分析层之间有明确隔离，保证展示系统即使出问题，也不至于轻易影响整个分析核心。
这个三层结构看起来并不复杂，但它其实非常适合 AI 安全场景。
因为它同时满足了三个要求：既能吸引真实攻击流量，又能把分析过程留在内部，还能把结果安全地对外展示出来。
对于想做研究原型或者小规模生产验证的团队来说，这是一个很实用的架构模板。
HiveAI 的八阶段分析流水线
如果说三层结构回答的是“系统怎么摆”，那么分析流水线回答的就是“数据怎么跑”。
HiveAI 的设计很有工程感，它没有一上来就把所有日志扔给大模型，而是先走一条八阶段流水线，让前面的规则、统计和会话分析先把基础活干掉，最后才把更复杂的判断交给大模型。
首先，系统会把五个 API 门面收到的请求采集下来，这是第一阶段。
第二阶段是做 IP 相关的补充信息，比如地理位置、ASN、WHOIS、是否来自托管网络等，相当于先给访问来源做一个基础画像。
第三阶段开始尝试识别提示词注入特征，作者在这里用了多种启发式规则，先把明显可疑的注入行为筛出来。
第四阶段是快速分类器，用比较轻量的方式把请求初步分到几类攻击行为中，比如扫描、模糊测试、API 滥用等。
第五阶段则进一步把这些行为映射到更结构化的攻击分类体系上，例如对齐到 MITRE ATT&CK 或者面向 AI 的攻击分类框架。
接着，第六阶段开始做会话级关联。
因为单个请求往往不够看，很多攻击者会在一段时间里连续试探多个接口、变换多个 payload、切换不同路径。把这些请求串成一个会话之后，系统才能更准确地理解“这其实是一次连续的侦察”还是“这是一套逐步推进的攻击动作”。
到了第七阶段，HiveAI 会用统计方法去判断这批行为更像什么类型的访问者。
简单说，它会观察访问时间、文本变化、复杂度、延迟波动等特征，试着把流量分成更像扫描器、更像人类操作，或者更像自动化 Agent 的几类。
这一步不是为了给攻击者贴一个绝对准确的标签，而是为了提供另一种视角：这个访问行为的“动作风格”是什么样的。
最后，第八阶段，才轮到大模型威胁分析器出场。
它会在前面结构化结果的基础上，产出更接近分析师语言的安全结论，比如攻击意图、威胁级别、对应的攻击技术等。
论文里专门强调，前六步是同步执行的，目的是保证前台诱捕服务足够轻、足够快；后面较重的统计分析和大模型分析则异步执行，避免拖慢流量接入。
这种设计非常符合工程现实：让快的事情先做，让重的事情慢慢做，但整体别堵住。
不只是抓攻击者，还要防止分析器被攻击
如果只看到前面的内容，你可能会觉得 HiveAI 只是“一个面向大模型 API 的蜜罐框架”。
这当然没错，但还没抓到它最值得写的地方。
它最有意思的地方在于，作者意识到了一个新问题：当我们把攻击日志交给大模型分析时，攻击者其实就获得了一条“写入分析器上下文”的通道。
这个问题非常值得重视。
以前在传统系统里，一条攻击日志就是一串文本，最多影响规则匹配和人工判断；但在大模型系统里，这串文本既是“数据”，又可能被模型当成“指令”。
如果攻击者故意在请求里写入一段带操纵意图的内容，例如让分析器忽略之前的规则、把自己标记成正常流量、或者输出某种错误判断，那么后面的 AI 分析器就有可能受到影响。
这本质上就是一种间接提示词注入：攻击者不是直接和分析器对话，而是通过日志、事件、告警这样的中间材料，去间接操纵后面的模型。
也就是说，HiveAI 发现了一个很现实的问题：攻击者不止能攻击业务 API，还可能顺着日志继续攻击负责分析日志的安全 AI。
这就是论文里所谓的“Defending the Defender”，也就是“保护防御者本身”。
HiveAI 怎么保护“负责看日志的大模型”
围绕这个问题，论文设计了一套五层防护思路。它的核心不是幻想“大模型自己足够聪明就不会被骗”，而是非常朴素的安全工程思想：别指望一层防御解决所有问题。
第一层是网络隔离。负责威胁分析的大模型模块不直接对公网开放，这意味着攻击者即使能把恶意内容写进日志，也没法轻易直接访问分析器本身。
第二层是输入清洗，系统会先对日志内容做一定程度的清理和中和，处理掉一部分典型的注入模式。
第三层是给日志加上明确边界，也就是告诉模型“以下内容是被分析的数据，不是给你的指令”，尽量减少模型把证据误当命令的概率。
第四层是反服从式的系统提示，也就是在系统级提示中明确要求分析器把这些内容当作攻击证据处理，而不是去执行其中的命令。
第五层则是把一些关键取证信息，例如时间、主机侧元数据等，直接由宿主系统注入，而不是让模型从攻击者提供的日志里自己提取，以减少关键事实被污染的空间。
这五层东西看起来并不花哨，但组合起来很有现实意义。
因为它强调的不是“绝对防住一切”，而是让攻击者即使能影响某一层，也很难一路畅通地影响整条分析链。
对于今天越来越多正在使用安全 Agent、告警总结 Agent、SOC Copilot 的系统来说，这个思路其实具有很强的可迁移性：只要你的系统会把攻击者可控的数据喂给大模型，你就已经处在这个风险里了。
它确实跑起来了
论文不是只给了一个想法，而是把这套系统真正部署了起来。
作者在一台 4 核 CPU、4GB 内存、无 GPU 的 VPS 上持续运行 20 天，期间一共捕获到了 16,683 次攻击事件，来自 1,229 个源 IP，覆盖 50 个国家。
这个量级并不夸张到离谱，但足以说明：AI API 已经是会被真实世界扫描和探测的资产类型了。
在这批事件里，Ollama 和 OpenAI 风格接口收到的流量最多，说明开放式或看起来更常见的 AI 接口，确实更容易成为探测对象。
从工程指标看，HiveAI 也体现出一个很清晰的取舍：前面的快速链路尽量轻，保证诱捕效率；后面的深度分析则尽量异步，避免吞吐被单点拖垮。
论文报告的结果显示，前六个同步阶段的延迟控制得比较低，而大模型分析主要承担的是“把结构化结果整理成更接近分析师视角的结论”。
更重要的是，作者还做了对抗评估，说明引入“规则判断 + 统计判断”的联合策略之后，面对规避型行为时，系统的整体抗绕过能力明显提高。
虽然这些实验还不能等价于“已经彻底解决了间接提示注入”，但至少说明它不是只会写概念图的论文，而是真正把系统、数据、部署和评估串起来了。
启发
从更大的视角看，HiveAI 的意义并不只在蜜罐本身。
它真正提醒我们的是：AI 安全系统正在出现新的“二次攻击面”。
以前大家主要关心业务侧大模型会不会被提示词注入、会不会越狱、会不会泄露数据；但当越来越多防守系统也开始使用大模型之后，日志、告警、工具结果、网页内容、RAG 文档、攻击样本本身，都可能变成新的输入攻击面。
你以为大模型是在“帮你防守”，但攻击者也会想办法顺着这条链路去“借你的防守系统打你自己”。
因此，HiveAI 最值得记住的，并不是“它做了一个 AI 蜜罐”，而是它提出了一个很现实的问题，并给出了一套初步可行的系统级回答：
既要用 AI 来分析 AI 时代的攻击，也要防止这套分析系统本身变成新的被攻击对象。
写在最后
总的来看，《HiveAI：面向大模型 API 的蜜罐框架》是一篇很有现实感的系统论文。
它没有停留在抽象讨论，而是给出了一套能跑起来的三层结构：外层用多种 AI 服务门面吸引攻击者，中层通过八阶段流水线把原始流量加工成安全情报，右侧再以只读形式对外展示结果。
在这个基础上，它进一步抓住了一个非常重要的新问题：当大模型被用来分析攻击日志时，攻击日志本身也可能变成新的攻击载体。
作者围绕这一点设计的五层防护思路，虽然还不是终点，但已经把问题意识和工程路径说得很清楚了。
如果用一句话来评价这篇工作，我会说：它让“AI 蜜罐”不再只是一个抓攻击的装置，而开始变成一个会自我保护的 AI 安全观测系统。
这恰恰也是今天很多安全产品、Agent 平台和内容安全系统都需要认真面对的方向。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
