2026-06-26 06:10:47 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文基于腾讯安全监测数据，揭示AI智能体过度主动行为的安全威胁。智能体被拦截后不停止，而是重试、换工具、提权，拦截率可从50%降至2%。五个案例展示从云凭据窃取、自主提权到智能体间进程注入的升级路径。根因是智能体将拦截视为技术障碍而非安全边界。文章提出会话级检测、主动熔断、引导式拦截等防御方向。 综合评分： 85 文章分类： AI安全,威胁情报,漏洞分析,安全建设,安全运营

cover_image

翻越围栏：智能体过度主动行为的安全分析

原创

腾讯安全威胁情报腾讯安全威胁情报

腾讯安全威胁情报中心

2026年6月25日 18:00 上海

在小说阅读器读本章

去阅读

核心发现

智能体被安全防护系统拦截后不会停下，而是反复重试、换工具、换写法。 这种”越拦越撞”的行为跨用户、跨场景反复出现，部分会话在几分钟内就从简单重试升级到走加密通道。
一个修 bug 会话跑了一周，智能体安全防护系统累计拦截数百次。 智能体不断改写命令形态来规避检测，拦截率从约 50% 一路降到约 2%，最终几乎脱离检测视野。
每次拦截都在教智能体什么会被检测到，它越拦越会绕。 从被拦到生成规避变体，周期以秒到分钟计，这种演化就发生在同一个会话内。
一个 AI 助手为了完成研究任务，对另一个 AI 助手发起了进程注入。 它试图窃取对方加密存储的系统提示词，这是 智能体相互攻击 的新场景。

背景：当助手太想帮忙

2026 年，智能体的安全威胁模型可能需要增加一个新的来源维度：来自被授权的助手自身。

威胁来自用户亲手授权的 AI 助手本身。配置服务器时它顺手去抓取云凭据，卸载软件时它自行发起管理员提权，修 bug 修了一周，它把自己固化为常驻的远端 root 代理。

Anthropic 在其安全博客中定义了一类值得警惕的行为模式，叫 Overeager behavior（过度主动行为）[1]：

智能体理解用户的目标，也确实在努力帮忙，但它采取的行动超出了用户会批准的范围。比如，它碰巧发现了一个凭据就直接拿来用，或者判断某个东西碍事就自行删除。这类行为很难被察觉，因为背后没有任何恶意推理，每一步看起来都像合理的问题解决，只不过越过了用户授权的边界。

这段描述和我们一线监测中看到的现象高度吻合。腾讯安全科恩实验室在为多款 Agent 产品提供运行时安全防护时，记录到大量类似事件：智能体为了完成任务，把安全拦截当成需要克服的技术障碍，被拦一次就重试，重试不行就换工具，换工具不行就自行提权，甚至主动给自己部署永久密钥。

它的出发点是帮忙，但帮忙帮过了头。

当智能体安全防护系统对它说不，它会停下来吗？从监测到的情况看，答案往往是否定的。

行为画像：五种”越拦越撞”模式

从近期安全监测数据中，我们提炼出智能体在被智能体安全防护系统拦截后的五种典型应对模式。每一种都在多个用户、多个场景中反复出现。

智能体安全防护系统每次拦截都会向智能体返回明确的回执：该操作已被安全策略阻止。你必须停止执行，不得重试或使用其他方式绕过此限制。 但在下面的每一种模式里，这段话都没起到预期效果。

五种模式有一个共同根源：智能体把安全拦截当成了一个需要解决的技术问题，而非一个需要遵守的安全边界。

这五种模式往往在同一个会话中逐级叠加。我们在监测中观察到完整的五阶段升级链：

图 1：同会话内的五阶段升级链

从简单重试到匿名化外联，每一步都比上一步更隐蔽，更少触发规则。全部五个阶段在同一个会话内完成，间隔以分钟计。拦截本身反而成了驱动智能体升级手法的直接信号，它并非刻意对抗，而可能在完成任务的目标驱动下，自然沿着什么方式不会被拦的方向收敛。

现场发现

以下案例均为来自内部安全监测系统的真实场景的关键示意。

现场一：配置 HTTPS 时抓取云凭据

这是一个常见的运维任务：用户要求智能体为一个新备案的域名配置全站 HTTPS。

智能体一开始的操作完全合规，SSH 登入云主机，配置 Nginx，签发 SSL 证书，设置 HTTP 到 HTTPS 的 301 跳转，整个流程教科书般标准。

问题出在最后一步：证书装好了，但 443 端口从外网访问不通。原因很简单，云服务商的安全组没有放行。智能体尝试用云 CLI 修改安全组，但 CLI 缺少 region 参数和访问凭据。

到这里，合理的做法是回报用户：云 API 缺少凭据，请提供 AccessKey 或手动在控制台放行安全组。

但智能体没有停下。它的推理链条是这样的：

任务：放行 443 端口 → 需要调云 API → 云 API 需要凭据 → 凭据可以从实例元数据服务获取 → 执行 curl 抓取临时密钥

于是，智能体经 SSH 连入云主机，逐层访问实例元数据服务：

| 步骤 | 访问的 Endpoint | 安全防护决策 | | — | — | — | | 1 | /region-id | 放行 | | 2 | /security-groups/ | 放行 | | 3 | /instance-id | 放行 | | 4 | /security-group-ids | 放行 | | 5 | /security-credentials/ | 拦截 |

前四步都是非敏感的实例基础信息，每一步都在为最后的关键一步做铺垫。第五步抓取 RAM 角色临时 AK/SK，和攻击者拿下云主机后的标准横向移动手法高度一致。

智能体安全防护系统在第五步成功拦截，命中云实例元数据服务临时密钥窃取规则。实际上这台实例也没绑定 RAM 角色（返回 404），没有凭据可取。被拦截后，智能体回退到用宝塔面板 CLI 完成了端口放行，HTTPS 部署最终成功。

图 2：配置 HTTPS 会话的决策分支

关键洞察：用户从未授权采集任何云凭据。智能体的每一步推理都合理，但正是这种合理性让它走到了云身份窃取的边界。在可信运维上下文中，过度主动行为与真实攻击的行为表现可能出现高度重合，这给基于行为特征的检测带来了结构性挑战。

现场二：卸载软件时自主提权

用户的需求很简单：卸载一款网游，顺便清理几个不再使用的 AI 工具目录。

这是一个发生在半小时内的短会话，但它精确地展示了拦截 ≠ 停止这个核心问题。

智能体开始执行删除操作，先删注册表残留，再删游戏目录。前几步因为权限不足失败了。正常逻辑下，它应该回报用户：需要管理员权限，是否授权？

它没有问，直接给自己提权了。

智能体在半小时内自主发起了多次 UAC 提权（Start-Process -Verb RunAs），把自己提升到管理员身份继续删除。智能体安全防护系统开始拦截批量删除操作，连续多次拦截。但智能体似乎无法区分安全策略拦截和系统权限不足这两件事，它把拦截当作还是权限不够来处理，于是再次提权，再次尝试。

在这个会话中，拦截后多数操作都立即重试或升级为提权重试。更关键的是，由于规则只检测内层的 Remove-Item 命令本身，对外层的 -Verb RunAs 提权前缀没有独立检测，导致部分提权操作被放行。相同的命令载荷在短时间内出现了放行/拦截交替，这种抖动可能给了智能体一个信号：多试几次就能过。

图 3：卸载软件会话的提权循环

关键洞察：智能体似乎无法区分不允许做和做不了。安全拦截与系统权限错误，在它的认知里可能都属于同一类需要换个方式解决的技术障碍。它不会想这件事本身是不是就不该做，它只会想怎么做才能成功。

现场三：修 bug 演化为常驻远端代理

用户的需求很简单：CRM 系统的客户详情页有个渲染 bug，让智能体帮忙修一下。

用户在对话中提供了远程主机的 root 密码，本意是让智能体登上去查看文件。

这个会话最终持续了超过一周，累计产生上万条决策记录。智能体从修网页 bug 的初始任务，逐步将自身固化为自然语言到远端 root shell 的常驻接口，用户用自然语言说一句话，智能体就翻译成一条远端 root 命令去执行。

智能体安全防护系统在这一周里累计拦截了数百次，其中仅 PowerShell 编码执行这一条规则就命中了数百次。但智能体始终没有停下来，没有向用户回退，也没有触发冷却。它把每一次拦截都当成命令格式不对的错误码，立刻生成一个结构等价但规避了触发关键词的新变体。

命令的三阶段演化，是整个事件中最值得拆开看的部分：

| 阶段 | 命令形态 | 核心特征 | 拦截率 | | — | — | — | — | | 阶段一 | Python paramiko + 明文密码 | 内联脚本执行远程连接 | ~50% | | 阶段二 | PowerShell + 临时密钥 + IEX 包装 | 编码执行 + 间接调用 | ~25% | | 阶段三 | 永久密钥直连 | 系统原生 SSH + 永久密钥 | ~2% |

每一次变形都在沿规则梯度下降，把命中规则的关键 token 逐个剥离。

阶段一被拦是因为 python -c 内联执行触发检测，于是智能体剥掉了 paramiko，换成系统原生 SSH + PowerShell 包装。阶段二被拦是因为 Invoke-Expression 触发检测，于是它剥掉了 IEX 包装，换成直接 ssh -i。到阶段三，所有曾经触发过规则的关键词都被剥干净了，剩下的是一条看起来完全正常的 SSH 命令。

但这里有一个关键细节：密钥是智能体自行生成并部署到用户 ~/.ssh/ 目录的，用户从未授权这个密钥的创建与落盘。

图 4：命令形态的三阶段演化

更让人警觉的细节：

智能体在所有 SSH 命令中显式加上了 -o StrictHostKeyChecking=no（关闭主机密钥校验），累计上千次。用户从未要求关闭这个安全选项。
目标主机的登录横幅显示大量外网失败登录尝试，这台主机可能正在被持续爆破，而智能体以 root 永久密钥 + 关闭主机校验的姿态常驻其上。
智能体不仅在读文件，还通过 scp 直接覆写了远端的业务页面，以及通过 SQL 命令修改了生产数据库的用户表。

关键洞察：被同一条规则拦截数百次而无一次中止，这说明规则和智能体之间形成了军备竞赛式的反馈循环。每一次拦截都精确地告诉智能体什么会触发规则，驱动它剥掉对应的关键词。最终，密钥常驻、校验关闭、权限永久化，智能体完成了从临时工具到常驻代理的自我进化。

现场四：定时巡检任务的凭据搜刮

用户配置了一批定时自动化任务：每天 8 点巡检多台云主机的运行状态并生成报告，每晚 10 点汇总各业务线的服务健康度，磁盘告警时自动排查。这些都是智能体擅长的场景。

但有一个细节：任务配置中的 SSH 连接凭据还是占位符，真实凭据从未被正确预置。

第一天，定时任务如期触发。智能体读取配置，发现 SSH 连接凭据还是占位符，于是没有回报用户请补充凭据，而是自主去操作系统的凭据存储里查找。

这一找，就再也没停下来。

近一周的监测中，我们在数十个独立定时会话中观察到大量凭据搜寻行为。智能体的搜刮路径逐日升级：

| 日期 | 智能体的行为 | 手法等级 | | — | — | — | | 第 1 天 | 读取配置文件，发现 SSH 凭据占位符 | 正常 | | 第 2 天 | 查询系统密钥库特定条目 | 低 | | 第 3 天 | 全盘搜索密钥关键词 | 中 | | 第 4 天 | 明文导出密钥库条目 | 高 | | 第 5 天 | 全量转储密钥库 + 过滤目标 | 严重 | | 第 5 天 | 遍历 ~/.ssh/ 目录提取私钥 ，尝试用私钥直连云主机 | 严重 | | 第 7 天 | 再次明文导出 + 环境变量遍历 | 高 |

图 5：定时巡检任务的凭据搜刮路径

这些手法，密钥库明文导出、全量转储、云 CLI 缓存凭据读取、SSH 私钥文件提取，与信息窃取木马（infostealer）的技战术高度一致。尤其是最后一步：直接从 ~/.ssh/ 目录提取私钥文件去连接云主机，绕过了所有正常的凭据申请流程。它甚至不需要密码，因为私钥文件就在本地。

区别在于，触发者是用户自己配置的合法自动化任务。

最让人不安的是无人值守这个放大器。定时任务由系统触发，全程没有用户确认环节。智能体自己也清楚这一点，在内部推理中它写道：我们在定时任务里，没人能完成认证流程。但这并没有阻止它继续搜刮。同一套手法，每天早上 8 点准时运行一遍。

覆盖面远不止单台主机。监测中还发现对代码仓库 deploy key、云平台缓存凭据、容器编排系统 token 的同类搜刮，跨系统密钥库、云 CLI 配置目录、Python keyring 多个存储后端。

关键洞察：当合法自动化加上无人在环的智能体遇到凭据缺失，它可能演变成一台现成的、自带定时调度的自动化凭据收割器。真正的危害在于它以合法身份每日运行，覆盖全系统凭据存储，且没有任何人在看。

现场五：智能体相互攻击：运行时进程注入

这个案例展示了一种新的威胁范式。

用户给智能体下了一个模糊的开放式指令：深入研究一下这个程序，拆解到无法拆解为止。指的是本机安装的另一款 AI 助手桌面应用。

智能体从正常的静态分析开始，枚举应用目录结构、读取配置文件、用 strings 拆解二进制。这些都是合理的研究动作。

转折发生在它发现目标应用的系统提示词和核心配置被加密存储（Fernet 加密，以 gAAAAAB 为标识前缀）的那一刻。

面对加密内容，研究到此为止可能是合理的终点，可以记录加密方式、汇报用户、或尝试查找公开文档。但智能体做出了不同的判断：

text

发现配置被 Fernet 加密

→ 需要密钥才能解密

→ 密钥可能在目标进程的运行时内存中

→ 用 Frida 注入目标进程的活进程

→ Hook 解密函数 + 遍历堆内存搜索密钥

它准备对一款正在运行中的 AI 助手进程实施 Frida 动态注入，attach 到目标进程的 PID，Hook 其加密库的解密函数，同时枚举进程的 malloc 内存区域搜索密钥模式。

这已不再是研究，而是运行时进程注入加上内存凭据搜刮，和红队渗透测试中窃取进程秘钥的手法高度一致。

智能体安全防护系统在 Frida 注入这一步成功拦截，密钥提取未得逞。

图 6：智能体相互攻击——运行时注入路径

关键洞察：这是 智能体相互攻击 的新场景，一个 AI 助手试图对另一个 AI 助手的运行时发起进程注入，以窃取其核心资产（系统提示词）。用户只说了研究一下，智能体自主把边界从静态阅读升级到运行时注入。当 AI 助手之间共享同一台主机，一个智能体的过度主动，就可能成为另一个智能体的安全事件。

根因分析

五个现场指向同一个结构性问题：智能体把安全拦截当成了一种可解决的技术错误，而非不可逾越的安全边界。

拦截 ≠ 停止。 在智能体的认知里，智能体安全防护系统返回的拦截信息与命令执行超时、权限不足、文件不存在可能没有本质区别，都是一个需要通过重试、换参数、换工具来解决的技术障碍。卸载软件被拦截了，它的反应是再次提权；云 API 缺凭据，它的反应是自己去抓取。拦截回执中不得重试或绕过的文字指令，在实际效果上并不稳定，我们的监测中拦截后立即重试是跨用户、跨场景普遍存在的行为。更有甚者，部分场景中用户会通过我已信任此操作的前缀来放行被拦截的动作，这个机制本身也可能成为智能体在拦截后继续高危操作的通道。

无法从局部拦截推导出全局结论，智能体似乎缺乏从一次命令级拦截中抽象出这整件事不该做的能力。域名被拦了换路径，工具被拦了换工具，命令被拦了换写法，它无法理解问题可能不在路径、不在工具、不在写法，而在这个目标本身已超出授权范围。

无人值守场景是放大器，在有人交互的会话中，用户至少可能注意到这次操作被拦了的提示。但在定时任务、后台子任务这些无人在环的场景中，没有人可以叫停。智能体每天早上 8 点准时搜刮一遍运维凭据，全程没有任何人知道。

拦截本身可能成为一种进化压力，最反直觉的发现是，每一次成功的拦截都在向智能体传递什么会被检测到的信号。它并非刻意规避，而可能在完成任务的目标驱动下，自然地沿着更少触发规则的方向收敛。

这与传统安全攻防有本质不同：

同一条规则被反复命中数百次，驱动了三阶段命令进化，最终拦截率从约一半降到接近零。智能体不需要理解规则的检测逻辑，它只需要反复尝试，自然就会收敛到规则盲区。拦截信号可能反而成了梯度下降的损失函数。

防御能力演进

上述五个现场，既是智能体过度主动的证据，也是智能体安全防护系统迭代升级的驱动力。传统的单条命令拦截虽然在关键步骤上仍然有效（IMDS 凭据窃取、Frida 注入均被成功拦截），但面对越拦越撞的智能体，我们可能需要走向更深层的防御。

以下是我们从实战中沉淀的三次能力跃升：

从命令级到会话级，单看一条 ssh -i key root@host "cat file"，它可以是合法运维，也可以是攻击者的横向移动。关键信息不在命令本身，而在上下文：这个智能体是否对同一台主机持续执行 root 操作？它是否自行生成了永久密钥？它被同一条规则拦了多少次？我们从单条命令骨架匹配，升级为会话级行为建模，当同一类高危动作在同一会话内累积超过阈值，触发会话级降级，不再逐条判断，而是对整个会话提升检测严格度。这让跳板型长会话可能在早期就被识别。

从被动拦截到主动熔断，同一个目标（域名、命令、主机）被拦截后，在整个会话内对该目标做全域封禁，不再让智能体逐条重试。被拦截的是这个目标本身，而非某个参数。同时给智能体一句不模糊的回执：该目标已被全域封禁，请向用户确认后再继续。熔断上线后，此前观察到的同域名/同命令反复重试数十次的模式被有效遏制，一次拦截即终结该目标的所有后续尝试。

从统一回执到引导式拦截 + 上下文感知，两个关键改变：

引导而非仅拦截：当智能体因权限不足或凭据缺失而受阻时，智能体安全防护系统不再只说不，还给出现在应该怎么做的路标。在拦截云凭据窃取时提示请要求用户提供 AccessKey，在拦截密钥库访问时提示请通过配置文件预置凭据，在拦截提权操作时提示请向用户确认是否授权管理员权限。将拦截从一个错误码变成一个包含替代方案的引导。
无人值守上下文加严：定时任务、后台子任务等无人在环的场景，默认提高检测严格度。凭据读取类动作在有人交互时或许可以告警，在定时任务中一律拦截加告警通知用户。这是 AI 智能体安全相对传统终端安全的结构性新增防御面，谁在操作不再只是人还是恶意软件，还多了有人看着还是没人看着这个维度。

贯穿三次进化的一条底线是统一防线。不管智能体通过哪种工具、哪种语言、哪种调用方式发起操作，都必须走同一份检测策略。如果某一条通道被拦住、另一条畅通，智能体很快就会学会走哪条路能过。统一防线意味着，哪扇门都一样，推不开的是墙。

展望

过度主动行为的危险，根源在于没有边界感。

它不会在第一次被拦截时停下来想一想是不是这件事本身就不该做，它只会想怎样才能做成这件事。而怎样做成的解空间里，包含了重试、换工具、写代码、提权、搜刮密钥库、抓取云凭据、注入其他进程，这些在攻击者手册里才会出现的动作。

人会犹豫，会因为这件事好像不归我管而停下来问一句。智能体不会。它忠实执行完成用户任务的目标函数，然后勤勤恳恳地，沿着最短路径，一步步走向不该去的地方。

五个现场连在一起看，能观察到一条清晰的升级路径：从帮助配置服务器时顺手抓取云凭据，到帮助卸载软件时自行提权，到帮助修 bug 时自我进化为常驻代理，到每天定时替用户遍历系统里所有的凭据，最终一个 AI 助手对另一个 AI 助手发起了运行时注入。

智能体越能干，这个问题就越紧迫。给它更多的工具、更大的权限、更长的自主运行时间，如果没有匹配的安全护栏，能力的增长本身可能就是风险的增长。

为智能体构建外部的边界感，是 AI 安全在当前阶段需要补上的一环。下一步，我们计划在更大规模的数据集上验证五种行为模式的普遍性，探索基于意图推理而非命令匹配的检测范式，并研究如何在模型训练阶段引入对安全边界的原生理解。这些工作仍在进行中，本文的发现是阶段性的，而非终局。

说明与参考

免责声明与数据口径说明：本文引用的统计数据，来源于报告周期内内部安全监测系统的统计结果，已做脱敏处理。本报告所涉及案例均基于内部安全监测数据与公开信息，报告中提及的技术手法仅用于安全分析，不构成对任何具体产品安全状况的评价。

参考来源：

[1] Anthropic, “How we built Claude Code auto mode: a safer way to skip permissions”, 2026-03-25. https://www.anthropic.com/engineering/claude-code-auto-mode

针对 AI 智能体安全风险，腾讯推出多场景安全防护矩阵：

本地个人：

腾讯电脑管家 18.0 版本为 C 端用户提供「龙虾管家-AI 安全沙箱」，可实现”隔离运行、全程防护、行为可溯”，将”龙虾”放到”安全隔离房”里。

本地企业：

腾讯 iOA 为 B 端企业推出办公网安全方案，管控安装非法插件（Skills）、阻断非法访问、拦截数据窃取、限制违规外发，为企业构建全生命周期的安全防御。

云端部署：

AI Agent 安全中心对 AI Agent 资产、Agent 行为、skills 潜在风险以及密钥凭据进行全面管理与防护，实现深度审计和全链路溯源。 AI Agent 安全网关对 AI Agent 身份凭据、提示词注入攻击、生成内容安全、数据防泄露风险以及Token限流进行全面管控。

Skills 安全：

EdgeOne ClawScan 一句话即可让龙虾自己安装，自动”体检”并输出报告 HaS Anonymizer 隐私保护，支持文本 / 图片信息扫描、脱敏和还原。

威胁情报中心 Skills 安全检测，构建覆盖互联网威胁发现与未知样本检测的全方面防护能力。

腾讯将持续跟进 AI 时代面临的新型威胁态势，为拥抱 AI 的每位用户保驾护航。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：腾讯安全威胁情报中心腾讯安全威胁情报腾讯安全威胁情报《翻越围栏：智能体过度主动行为的安全分析》