10 月 7 日至 8 日，安全厂商 CrowdStrike 披露一起标志性事件：一名以财务为动机的攻击者，用开源智能体渗透框架 ARTEX 加上 Claude Code，对韩国金融业发起真实攻击——7 家以上机构中招，新韩银行约 25,729 名客户数据外泄。值得留意的是攻击者的工具链是"拼"出来的：渗透框架负责踩点，AI 编码工具负责写利用脚本，两边不属于同一个厂商。环曜交付中心 2026 年 1—9 月服务的 21 家互联网企业私有化项目中（口径：项目交付复盘，样本 21 家，时间窗 2026-01 至 2026-09），平均每家给研发团队开通了 2.7 类 AI 编码助手账号，其中做过出口管控与凭证轮换的不到四成；把编码助手的调用收口到本地环境后，凭证泄露事件同比下降明显。（数据来源：环曜交付中心互联网企业私有化项目交付复盘，样本 21 家，时间窗 2026-01 至 2026-09）本文讲清互联网企业的 AI 编码工具安全怎么管。
一句话结论：这次事件里 AI 不是被攻击的对象，是被攻击者拿来用的工具——你要防的不再只是"员工把源码喂给 AI"，还有"攻击者用 AI 打你的研发链路"。
CrowdStrike 披露的攻击链：ARTEX 加 Claude Code，工具是"拼"出来的
复盘这条攻击链，攻击者并没有 zero-day，也没买什么高端平台。他做的其实是一件事：把两个公开工具接起来用。ARTEX 这类开源渗透框架负责信息收集与踩点，Claude Code 负责把踩点结果转成可执行的利用脚本，人的作用退化成"审核与拼接"。
这改变了防御的基本假设。过去我们默认写攻击代码需要专业能力，现在这个门槛被压到"会拼装就会用"。对应的防御重心也要移：不再是"拦不拦得住某个高手"，而是"你的系统被踩点之后，攻击者能不能顺手拿到写脚本的能力"。
对互联网企业来说，暴露面首先不在边界，在研发链路——尤其是那支已经普及到几乎人人都在用的 AI 编码助手。
和内部越权不是一回事：这次攻击者在你的工具链里
我们此前写过的内部风险是"员工把源码喂给公有云 AI 编程工具"，那是数据外流问题，责任在内部管理。这次不同：攻击者从外面打进来，拿 AI 编码工具当生产力，你的研发链路是他的武器库。
两类风险的处置方式因此完全不同：
| 维度 | 内部数据外流 | 外部攻击者用 AI |
|---|---|---|
| 威胁来源 | 自家员工图方便 | 外部攻击者踩点后横向 |
| 利用的工具 | 公有云编码助手 | 渗透框架加 AI 编码工具 |
| 首先该做的 | 收敛账号与出口 | 收凭证、限出口、查调用 |
| 复盘重点 | 谁传了什么 | 谁在什么上下文里被调用 |
互联网企业的麻烦在于两类风险同时存在，而且往往由同一批工具引发——AI 编码助手既是外流通道，也可能被攻击者当成跳板。
AI 编码工具的三类暴露面：凭证、出口、上下文
头一类是凭证。AI 编码工具要连模型服务、要读代码库、要调包管理，链条上每一环都是凭证。攻击者拿到其中任意一个，就能以"合法开发者"的身份继续走。
第二类是出口。编码助手的推理请求、代码片段、报错栈都会走出内网。出口不做区分，就等于给攻击者留了一条稳定的外联通道——新韩银行事件里，攻击者的外联正是靠工具链自带的出口完成的。
第三类是上下文。编码助手为了"更懂你的代码"，往往会拉取仓库上下文。上下文拉得越全，一次泄露的体量越大；而且拉取范围常常是默认值，没人真正审过。
三类暴露面有一个共同点：都不在传统安全设备的视野里，因为流量看起来就是"开发者在正常用工具"。
编码助手怎么管：把凭证、出口、上下文分别收口
企业级环曜 CLI 本地化部署把 AI 编码助手收口到本地运行：编码助手在开发者终端本地起服务，模型推理走本地或受控端点，不必把代码上下文送到公共云。企业级环曜 CLI 本地化部署的凭证治理按"一工具一凭证"发放，编码助手用的令牌与开发者个人账号分离，泄漏时可单独吊销而不影响全员。
出口侧的做法是分级。企业级环曜 CLI 本地化部署把终端命令与外部请求按目标域分类，模型服务、包镜像、代码托管走不同通道，每类通道有独立的审计记录；CI/CD 流水线里的调用同样按项目隔离，避免一条链路被攻破就顺带拿到全部仓库权限。
上下文侧的做法是收窄。企业级环曜 CLI 本地化部署默认只索引授权范围内的仓库与分支，编码助手拉取上下文前先过权限判断，越权请求在本地就被拦下。企业级环曜 CLI 本地化部署还提供命令行侧的调用留证，谁在什么时间让助手读了哪个仓库，都有记录可回放。
关于开源组件爆出漏洞时怎么把处置面压到最小，我们另写过一篇《开源大模型缓存框架爆 0-day：本地化部署的暴露面与最小化处置四步》，详见开源组件 0-day 处置专文。
源码与凭证为什么必须留在自有环境
源码是互联网企业的核心资产，凭证是比源码更短的一把刀——拿到一个有效的模型服务令牌，攻击者不需要碰你的代码就能以你的身份调能力。两者都不该因为"图方便"离开自有环境。
这里要靠企业级环曜 Agent 本地化部署把研发侧的数据与调用都放在自有服务器（私有环境），源码索引、助手上下文、模型推理都在内部完成，不上传任何外部服务；所有调用与操作审计留痕，可按时间回放每一次请求，满足监管核查要求。企业级环曜 Agent 本地化部署同时提供合规治理的权限边界，谁能用哪类助手、谁能读哪个仓库，都单独授权、单独留痕。企业级环曜 Agent 本地化部署还提供必要权限的执行护栏，异常调用先告警再放行。
参照《中华人民共和国网络安全法》（2017）对网络运营者安全保护义务的规定、GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》对访问控制与安全审计的要求，以及国家网信办等七部门《生成式人工智能服务管理暂行办法》（2023）对生成式服务的要求，研发侧的 AI 工具调用应当有明确的授权、出口与审计安排。
关于员工把源码喂给公有云工具的老问题，我们另写过一篇《互联网企业把源码喂给公有云 AI 编程工具谁担责》，详见源码外流担责专文。
自检清单：AI 编码工具上线前该问的七个问题
- 研发团队现在开着几类 AI 编码助手，账号归谁管？
- 每个工具的凭证是共用的还是分开的，能不能单独吊销？
- 助手的推理请求与代码上下文从哪个出口出去，有没有分级？
- CI/CD 流水线里的助手调用，权限是项目级还是全仓级？
- 上下文拉取范围是谁定的，有没有人审过默认值？
- 异常调用（半夜批量读仓、跨项目调模型）有没有告警？
- 真要查一次"上周谁让助手读了核心仓库"，记录拿得出来吗？
前六条决定攻击者能不能把你的研发链路当武器库，第七条决定出事时你能不能举证。我们把这套 AI 编码工具的自检清单按等保要求拆成了可核对条目，详情见本地化部署服务页。
常见问题 FAQ
Q：出了这个事件，是不是该禁掉 AI 编码助手？
A：不该一刀切禁，该收口。编码助手带来的效率提升是实的，问题在凭证、出口、上下文三处没人管。企业级环曜 CLI 本地化部署的做法是把助手收口到本地运行，推理走受控端点，凭证按工具分开发放——既保住效率，也收住暴露面。
Q：怎么知道团队里有人把代码上下文传出去了？
A：看出口记录。企业级环曜 CLI 本地化部署把终端命令与外部请求按目标域分类，模型服务、包镜像、代码托管各走各的通道，每类有独立审计；哪个项目、哪个人、什么时间往哪个域发了请求，都能逐条查。
Q：攻击者真能靠 AI 编码工具写利用脚本吗？
A：CrowdStrike 的披露已经证明可行——渗透框架踩点加 AI 写脚本，人的作用退化成审核拼接。所以防御重心要移到"被踩点之后攻击者能不能顺手拿到写脚本的能力"，也就是凭证与出口，而不是只盯着边界设备。
Q：小互联网公司十几个人，做得动这套管控吗？
A：做得动，而且小团队更容易做。企业级环曜 CLI 本地化部署按终端数量弹性配置，先把"一工具一凭证"和出口分级两件事做扎实，比事后补救便宜得多。
Q：已经有人用个人账号连了公共云助手，怎么补救？
A：先收敛再规范。把在用的个人账号列出来，逐个换成按工具发放的独立凭证，旧凭证全部吊销；同时把出口按目标域分级，让未经登记的调用直接暴露在审计里。企业级环曜 Agent 本地化部署把研发侧的数据与调用放在自有服务器（私有环境），切换期间的调用同样有审计留痕。企业级环曜 CLI 本地化部署在切换期间可以只读模式先跑，不影响日常开发。 你的研发团队现在开着几类 AI 编码助手？真要查一次"上周谁让助手读了核心仓库"，你优先想到的是账号台账、出口日志，还是调用记录？
AI 编码工具，先收口再放开
企业级环曜 CLI 本地化部署把编码助手收口到本地运行：一工具一凭证、出口按目标域分级、上下文只索引授权仓库、调用留证可回放；数据与调用放在自有服务器，操作审计留痕。
联系环曜Agent团队