AI 代理十小时打穿一家企业：首例多智能体入侵事件复盘
安全厂商 Unit 42 在 9 月 2 日发布了一起入侵事件的复盘：一名人类攻击者，一套多 AI 代理框架，从突破入口到拿走数据，全程不到十小时，用了五十多种 ATT&CK 技战术。人工红队做同样的事，通常要两周。
攻击者在勒索谈判中自己承认：用的是前沿大模型，加一套专门搭建的攻击框架。取证侧的旁证也对得上——多个前沿模型的并行调用记录、代理之间传递状态用的结构化 Markdown 文件、高置信度由 AI 生成的定制脚本。
这是第一起被完整记录的多智能体 AI 入侵。本文按复盘报告还原攻击全程，对照两个月前的同类事件看趋势，最后归纳防守方能直接拿走的对策。
入侵而非勒索软件
中文圈这几天的标题大多叫"全球首例多智能体勒索攻击"。披露团队在报告发布第二天专门更正：这起事件的定性是"入侵"，不是"勒索软件攻击"。攻击者没有加密文件、没有留勒索信，走的是偷数据、再拿数据谈赎金的路子。
这个更正本身值得展开。加密是勒索产业链里最重的一环：要把数据拖出去、要批量加密、要在受害者网络里留下接触面，每一环都增加暴露时间，也给防守方 ...
AI安全现况：AI无法保证 AI 的安全
全行业的想象是一个闭环：AI 写代码，写得快；出了漏洞，再让 AI 修；怕它不靠谱，就在提示词里加一句"注意安全"。三道保险，环环相扣，听起来滴水不漏。
这个闭环里的每一环，最近都被人拿数字拆过了。
一个大学团队扫了四万多条安全通告，第一次把漏洞具名归因到 AI 头上；一家密码管理公司的安全实验室跑了六千多次补丁实验，看 AI 修漏洞到底修成什么样；还有两篇互不相识的学术论文，测了"提示词里叮嘱安全"到底有没有用。
三拨人，三种方法，互相不知晓，结论却指向同一个地方：AI 保证不了 AI 的安全。写它的、修它的、验证它的，每一环都比你以为的更漏。
这篇文章把三份账单摆在一起，算一算 AI 代码安全的真实基线到底在哪。
证据一：写——AI 写出的漏洞，已经具名进了漏洞库
先看最直接的一份证据。
"AI 写的代码不安全"这个说法流传了很久，但大多停留在基准测试和推测里。直到有研究团队换了个思路：不测模型能力，直接去安全通告数据库里数。扫了四万三千条通告，靠提交记录里的机器人署名、协作标签这类元数据，判断哪些漏洞的代码里有 AI ...
s1ngularity 时刻：AI 编码工具第一次被武器化
摘要
2025 年 8 月 26 日，npm 的 Nx 包供应链攻击里，攻击者把 Claude Code 和 Gemini CLI 下载到受害者机器上，让 AI 替自己搜机密、传机密。安全厂商 Wiz 的定性：已知首次在供应链攻击中用 AI 执行数据窃取。
续集在 CI/CD：一条恶意 GitHub issue 劫持了 Claude Code 官方 Action 的权限检查，从读密钥打到完整仓库接管。漏洞已修复，但同类配置错误已在另一个 AI 编程工具的仓库被真实利用。
背景板：chalk 事件中，维护者账号失陷后约 16 分钟即发出恶意版本，18 个包合计周下载 20 亿次。
本文判断：AI 编程工具的角色变了——从"被攻击的软件"变成"攻击者借用的自动化劳动力"，攻击成本近乎零。
防御三件事：终端上收小 AI 的权限；CI 里密钥与 AI 会话隔离；issue/PR 默认按不可信输入对待。
一、那天发生了什么
2025 年 8 月 26 日起，npm 上 Nx 的多个包被投毒，事件后来被命名为 s1ngularity。真正让它进入史册的 ...
"以模治模"写进政策：国内智能体新政安全条款逐条读
2026 年，国内智能体产品的执行形态发生了明显变化：定时任务、事件触发、长时自主执行成为主流产品能力，单次任务中的人工介入持续减少。执行链路的自动化程度越高，权限控制、行为审计和越权阻断的工程权重就越大。
监管侧对这一问题的回应集中在两份文件。2026 年 5 月 8 日，国家网信办等三部门公布《智能体规范应用与创新发展实施意见》（国信办发文〔2026〕6 号，下称"6 号文"）；2026 年 7 月 21 日，北京市发展和改革委员会等四部门印发《关于加快智能体引领发展的若干措施》（京发改〔2026〕1185 号，下称"北京十条"）。
现有公开解读大多聚焦产业促进条款。本文限定范围，只解读两份文件中与安全直接相关的条款：先梳理 6 号文的安全条款分布与决策权限界定，再分析行为管控、供应链与风险处置条款，最后解读北京十条提出的技术路线，并给出对应的工程落地项。文中条款引用均为官方原文；执行细则尚未发布的内容，本文注明"待细则明确"，不做扩大解释。
一、安全条款在 6 号文中的分布
6 号文正文分六个部分，可执行任务条目共 3 ...
首份办公 Agent 用户行为调查解读：Vibe Coding 之外，办公 Agent 或将成为主流
首份办公 Agent 用户行为调查解读：Vibe Coding 之外，办公 Agent 或将成为主流
过去两年，AI 应用最确定的主流场景是 Vibe Coding——用自然语言指挥 AI 写代码。Cursor、Claude Code、各类代码助手把编程变成了一场对话，也让"AI 真正干活"第一次有了千万级的用户验证。但编程终究是一部分人的工作。绝大多数职场人的日常是写文档、做表格、整理信息、跑流程——这个体量大得多的场景，正在成为 AI 的下一个主战场。
9月7日，国内首份《中国办公Agent用户行为不完全报告》在北京发布，出品方是网易有道旗下开源桌面端办公 Agent 产品 LobsterAI。这是国内第一次有人用真实产品数据（上线8个月、用户超100万，据报告），而不是问卷，来回答"办公 Agent 到底被谁在用、拿来做什么、用到了什么深度"。
先看几个数字：近60%的 token 消耗发生在常规办公时间之外；12.2%的模型调用不需要人实时发起；新模型上线3天，用户渗透率接近50%；过半调用给了价格只有旗舰三分之一的经济型模型。这些数字放 ...
AI 代码扫描与安全检测全景
AI 写的代码 45% 带漏洞，"审 AI"成了安全行业一条拥挤的新赛道。
安全公司 Veracode 在 2025 年做过一组实验：让 100 多个大模型完成 80 个常见编码任务，45% 的任务生成了带 OWASP Top 10 漏洞的代码。XSS 防护失败率 86%，日志注入 88%，Java 语言的失败率超过 70%。更早的 2022 年，NYU 那篇《Asleep at the Keyboard》就测出 GitHub Copilot 生成的程序约四成带安全缺陷。
写代码的速度翻了几倍，审代码的人手没变多。卡点在哪，不用说也知道。这就是过去一年"AI 代码扫描"突然卷起来的原因。
一、AI 代码扫描时间线
2023 年那批工具的做法很简单：GitHub 收到 pull request，webhook 触发脚本，把 diff 拉下来整段塞进 ChatGPT，让它挑毛病。cr-gpt 这类开源 bot 一夜之间冒出来，几百行代码就能搭一个。新鲜感过去得也快，模型经常一本正经地指出根本不存在的漏洞，或者纠结一个无关紧要的命名。幻觉和误报太 ...
代码图结构化工具与知识库是否能够帮助AI理解代码?
摘要:Agent 写对了每一行代码,系统还是出了事故。我们用 Django、CPython、Kafka 三个仓库出题、跑了 480 个 run,想验证代码图能不能让 Agent 更懂代码,结果没有得到一个简单的「能」——它真正改善的是探索效率,而会话本身是另一个被低估的变量。
产品要做一个「用户活跃度周报」。Agent 接到需求后的表现,挑不出毛病:复用了项目里现成的 getActiveUsers(),直接读取 email/phone,接入了现成的 RateLimiter.check(),测试全绿。
两周后,线上出了三件事。
已删除用户混进了周报,活跃度被虚假拉高。低权限角色拿到了明文手机号。真实用户登录被限流——周报的批量轮询,把和登录模块共用的那个限流配额池耗光了。
三段代码单拎出来都算合格:复用的方法别的模块一直在用,工具是现成的,测试也通过了。问题都不在这些代码本身,而在它们周围——在那些没写在函数体里的事实里。
第一次接这个需求,Agent 用了 37 次 grep、读了 21 个文件、花了 12 分钟,最后靠人把坑一个个揪出来。一周后第二个类似需求,新会话从零开始:34 ...
Agent 上下文越用越堵?6 种压缩策略,从实验数据到生产落地
做过 Agent 的人大概都遇到过这一幕:任务跑到第五轮,上下文窗口满了,任务直接失败。不是模型不够聪明,是对话历史里堆了几十万字符的工具输出——搜索结果、网页正文、代码片段,绝大多数在读完那一刻就成了占地方的噪声。
但你有没有好奇过:Claude Code、ChatGPT、Deep Research 这些主流 Agent,到底是怎么处理这个问题的?大多数人对压缩的认知停留在两句口诀:一句是"上下文超过阈值就自动压缩",另一句是"把脏活累活拆给子 Agent,只回传结论"。可真要追问下去——超过阈值之后具体做了什么?摘要怎么写的,丢了什么、留了什么?除了压缩和子 Agent,还有没有别的招?能说清楚的人就不多了。
这些问题的答案,藏在一本开源书里:《AI Agents in Depth》第二章「上下文工程」。作者用一组对照实验把压缩这件事拆得很彻底:六种压缩策略逐一对测,token 消耗、压缩率、任务成功率摆在一起对比;又给了一套生产环境的分层压缩方案,外加一张"什么能删、什么绝不能动"的保留优先级清单。这篇把核心结论提炼给你 ...
对抗AI的Java安全测试基准
当安全工具可以通过类名 SQLInjectionController 直接判断漏洞类型时，我们测试的到底是工具能力，还是靶场本身提供的提示？
随着大语言模型被广泛应用于代码安全分析，传统漏洞靶场正在逐渐失去其评估价值。许多安全工具在这些靶场上取得极高的检测率，但这并不一定意味着它们在真实环境中同样有效。
原因很简单：传统靶场过于"诚实"了。
它们往往在代码结构、命名和路径中直接暴露漏洞语义，使得工具无需深入分析即可判断漏洞类型。
本文提出一种新的设计方法：构建对抗 AI 的漏洞靶场，并通过自动化验证体系确保漏洞仍然真实存在。
具体来说，我们提出三个核心设计原则：
语义中立（Semantic Neutrality） —— 移除代码中的漏洞语义提示
代码混淆（Code Obfuscation） —— 模拟真实世界的对抗环境
Ground Truth 验证体系 —— 确保混淆后漏洞仍然可触发和利用
这些原则构成了一个新的安全测试基准：面向对抗环境的漏洞靶场（Adversarial Vulnerable Benchmark）。
传统漏洞靶场的问题
漏洞靶场长期以来 ...
ClaudeDevKit：一个面向 Claude Code CLI 的轻量 AI 协作工作流实践
项目地址：https://github.com/LuckVd/ClaudeDevKitV2
为什么做这个项目
在使用Claude Code Cli进行开发的时候，即使工具本身已经非常强大，但如果不对项目提前进行规划，而是通过多轮对话进行“对话式”开发，那么往往会有如下问题：
AI失焦：比如在开头告诉了AI，修改完之后，严禁自己提交。但偶尔会忘掉该约束。
上下文漂移：随着对话轮次增加，AI更容易被后续局部任务“带偏”，遗忘最初设定的全局目标、边界条件或编码规范，最后虽然局部修改看起来合理，但整体实现已经偏离预期。
修改失控：缺少前期拆解和任务边界约束时，AI容易为了“顺手修好”相关问题而扩大改动范围，导致本来只想做小修小补，最后却引入额外重构、影响未涉及模块，增加回归和排查成本。
例如：
12345678910111213用户：帮我优化一下用户模块的性能 │ ▼AI：好的，我优化了数据库查询... 顺便重构了认证逻辑... 还清理了一些"冗余"代码... │ ▼结果： • 用户模块确实快了 20% • 但认证系统崩了（那不是冗余代码） ...
