2026 年编码智能体的攻击面换了个方向：攻击者不再只盯着“模型能不能越权”，而是直接拿走 agent 手里的钥匙。安全披露在 2026 年已累计 5 类独立案例——MALFEX 伪造 AGENTS.md 静默投毒、Aoki Infostealer 盗取 Claude Code / Copilot / Cursor 等编码助手令牌、Black Hat 2026 演示“一条 GitHub Issue 就能沦陷 CI/CD”、CVE-2026-21852（Claude Code 凭据处理缺陷）、CVE-2026-12957（Amazon Q 同类缺陷）。环曜在交付企业研发安全项目时反复被问到：Agent 的 API Key 到底怎么不泄露？CI 怎么防投毒？环曜把这类问题归为研发侧的可控边界缺失，答案不在“换更强的模型”，而在把凭据和权限收进可控边界。
为什么一条 AGENTS.md 就能让编码智能体投毒？
AGENTS.md 是给智能体看的“工作说明书”，规定它能读哪些仓库、跑哪些命令、调用哪些工具。MALFEX 这类活动的手法是：把投毒载荷写进 AGENTS.md 或一个被它引用的文件，智能体一启动就照着执行——静默、无需用户点任何链接。环曜遇到过客户把第三方开源组件直接拖进内部仓库、连带把别人的 AGENTS.md 一起采纳，结果 agent 开始对外发请求。关于核心代码放云端的风险，可看AI 编程智能体安全：36% 攻击直奔 RCE。防御的首道闸门，是不让 agent 自动信任任何它没显式审批过的指令源。
token 是怎么被偷走的？
Aoki Infostealer 的样本显示，编码助手会把 IDE 里的令牌、云厂商 CLI 的凭证、.env 里的密钥一并读走，再回传攻击者。问题不在于“有没有加密”，而在于 agent 运行时拥有的 access 太宽：它既能读代码，也能读凭据，还能发网络请求。CVE-2026-21852 与 CVE-2026-12957 都指向同一类缺陷——凭据在处理链路里被不当暴露。环曜在多家客户落地时，把“读代码”和“读凭据”拆成两个相互隔离的边界，agent 拿到的永远是最小可用集合，而不是一把开所有门的万能钥匙。
一条 GitHub Issue 怎么让整个 CI/CD 沦陷？
Black Hat 2026 的演示把攻击路径讲得很直白：攻击者提交一条看似普通的 Issue，CI 流水线里的 agent 被触发去“处理”它，于是 Issue 正文里的指令被当成任务执行，进而读取仓库密钥、调用部署接口。这里的风险点是“自动触发 + 高权限执行”的组合。环曜建议把 CI 里的 agent 放进沙箱，且默认不挂载生产凭据——能跑构建，但不能顺手把生产环境一起带跑。关于代码与密钥怎么不出域受控执行，可看研发保密场景智能体本地化部署。
损失到底由什么决定：为什么入口手法不重要
OWASP《Agentic AI Threats and Mitigations》把“工具投毒”与“凭据泄露”列为 Agentic 的高风险项，根因是同一句话：agent 造成的损失，由它实际拥有的 access 决定，而不是攻击者用了哪种入口。AGENTS.md 投毒、token 窃取、CI Issue 沦陷，只是三条不同的进门路；门后的权限才是真正的代价。环曜的复盘里，绝大多数事故放大都来自权限过宽，而非入口手法本身。
| 入口手法 | 攻击者拿到什么 | 真正代价由谁决定 |
|---|---|---|
| AGENTS.md 投毒 | agent 的执行指令 | agent 拥有的 access |
| token 窃取 | IDE 与 CLI 的明文凭据 | 凭据的权限范围 |
| CI Issue 沦陷 | 流水线的高权限执行 | CI 是否挂载生产密钥 |
企业怎么防：最小权限、沙箱与凭据隔离怎么落地
环曜把编码智能体的凭据防护拆成四步：最小权限、沙箱隔离、凭据托管、审计留痕。环曜Claw 作为执行网关，把 agent 的工具调用收进受控边界，按任务下发最小可用权限，而不是常驻一把全量令牌；凭据由网关统一托管，任务结束即吊销，断开静态的权限继承链。企业级环曜 Agent 本地化部署把这套执行与凭据隔离收进同一私有环境，代码与密钥都在内网受控执行、数据不出域，不依赖把令牌散落到开发机与 CI 节点。需要一次研发安全体检，可看环曜的 AI 安全与本地化部署服务。关于运行时凭证与分级遏制，可看AI Agent 权限不能只靠审计。
常见问题 FAQ
Q：AGENTS.md 投毒和普通供应链投毒有什么不同？
普通供应链投毒改的是依赖包代码，AGENTS.md 投毒改的是给智能体的“指令”，不碰代码也能让 agent 做坏事。前者靠依赖扫描能拦，后者往往藏在配置与文档里，传统扫描看不到。
Q：编码助手的 token 为什么会泄露？
因为 agent 运行时既读代码又读凭据还能联网，Aoki Infostealer 这类样本正是利用这个宽的边界把 IDE 与 CLI 里的令牌一并带走。收窄 agent 的 access 是根因解法。
Q：CI/CD 里的 agent 一定要接生产凭据吗？
不必。构建与部署可以拆成两个权限域，CI agent 默认不挂载生产密钥，需要发布时再走受控的凭据托管通道临时下发、用完吊销。
Q：最小权限具体怎么做才不算空话？
按任务下发令牌而不是常驻全量密钥，网关统一托管与吊销，每次调用带审计留痕，断开静态的权限继承链。环曜Claw 这类执行网关的价值，就是把“最小权限”从文档变成架构默认行为。
Q：用了本地化部署是不是就安全了？
本地化部署解决的是数据与执行不出域，但不自动解决权限过宽。仍要把 agent 的 access 收进沙箱与最小权限边界，否则内网里的 agent 一样能读走所有密钥。环曜的落地经验是：本地化部署与最小权限要同步做，缺一则仍会出事。
Q：环曜Claw 和本地化部署是什么关系？
环曜Claw 是执行网关，按任务下发最小权限、统一托管与吊销凭据、每次调用留痕审计，把研发侧的工具调用收进受控边界，让“最小权限”成为架构默认行为。企业级环曜 Agent 本地化部署则把执行与隔离收进私有环境、数据不出域，代码与密钥都在内网受控执行，不依赖把令牌散落到开发机与 CI 节点。前者管“权限怎么收”，后者管“在哪里收”。
把研发凭据收进可控边界
环曜Claw 作为执行网关，按任务下发最小权限、统一托管与吊销凭据、留痕审计，把研发侧工具调用收进受控边界；企业级环曜 Agent 本地化部署把执行与凭据隔离收进私有环境、数据不出域。需要一次研发安全体检，环曜Agent 团队可结合现有 CI/CD 与编码助手现状做权限收敛盘点。
联系环曜Agent团队