Google GTIG 报告：对手转向 Agent 化攻击，AI 编码工具成为供应链新入口

过去我们谈 AI 安全，多半是「模型会不会说错话」。Google 威胁情报组（GTIG）在 2026 年 Q2 的追踪报告里换了一个视角：他们看到的是对手在把 AI 当成作业平台的升级件。报告的说法很直接——在 2026 年第二季度，GTIG 观察到威胁行为者先拿下云资源，然后在里面规划、构建并执行一场由 Agent 驱动的规模化凭据收集行动。同一份报告里还有半句更值得我们这些写代码的人停下来看：AI 编码工具正在成为攻击者的首选目标，因为它们既在开发流水线的关键位置，又天然被信任。

"对手把 AI 装进了自己的流水线"

一、从「提示词」到「自主」的这条线

GTIG 的这份追踪报告，是接续其 2026 年 5 月的对抗性 AI 滥用报告而来的。前后对比勾勒出一条清晰的进化线：早期是「用模型帮我把话写得更好」，现在是「让模型帮我跑完一条工作流」。区别不在措辞，而在于自动化把人力瓶颈拿掉了——侦察、枚举、收集、打包，原来每一步都要人盯着，现在可以连续跑。对防守方来说，这意味着攻击的时间窗口从「小时」压缩到「分钟」，靠人工巡检发现异常已经不可能。实际后果不是「手段更高级」，而是节奏变了。一个人工操作者的进度受注意力和睡眠限制，而 Agent 驱动的行动只受速率限制约束。这也是报告把它描述为「自主化」而不是「更强的模型」的原因。

# 1) Never keep a long-lived publish token in CI. Use OIDC.
#    A stolen runner token is how Dustmaker published "trusted" packages.
name: release
on: { push: { tags: ["v*"] } }
permissions:
  id-token: write        # short-lived, scoped, no static secret
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci --ignore-scripts   # no arbitrary postinstall execution
      - run: npm publish --provenance   # signed provenance attestation

二、UNC6780 的手法：Dustmaker 与「混进噪音里」

报告点名的犯罪团伙 UNC6780（也叫 TeamPCP）自 2026 年 3 月起，持续对 PyPI、npm、Docker Hub 等生态发动供应链攻击。它的恶意程序 Dustmaker 有一个专门为 AI 时代设计的技巧：从 GitHub Actions runner 的进程内存里提取令牌，从而发布「能通过 AI 编码自动化信任检查」的受损软件包版本。更狡猾的一步是把恶意文件投放到 AI 编码助手的隐藏工作目录里——那里本来就堆满缓存和临时文件，恶意文件混进去，就像混进了一片日常噪音。

// 2) Scan the dirs AI coding assistants use as scratch space.
//    A payload hiding next to cache files still has a hash and a diff.
const AGENT_DIRS = [
  ".git", ".cursor", ".claude", ".aider", ".continue",
  "node_modules/.cache", ".next/cache", ".open-next",
];

function findSuspicious(root) {
  return AGENT_DIRS.flatMap((d) => scan(path.join(root, d)))
    .filter((f) => f.executable || f.hasShebang || f.installsNetwork());
}

const hits = findSuspicious(process.cwd());
if (hits.length) {
  console.error("unexpected executables in agent scratch space:", hits);
  process.exit(1);
}

三、为什么 AI 编码工具放大了风险

报告的逻辑值得我们抄下来贴墙上：AI 编码助手和开源软件一起加速了开发，同时也扩大了攻击者把恶意代码藏进项目和依赖里的机会。这句话拆开有两个机制。第一，编码 Agent 会自主读取仓库、安装依赖、执行脚本——它读到的每个文件都是潜在的输入。第二，当「代码是 AI 生成的」变成常态，团队对自动化信任检查的依赖度上升，而令牌一旦泄露，攻击者就能伪造出通过检查的发布物。信任被自动化了，伪造也就自动化了。还有第三个容易被忽略的机制：出处疲劳。当自动检查成为常态，评审者就不再真正阅读结果，一个绿色的勾从证据降级成了情绪安慰。

# 3) "Passed the automated check" is not "trustworthy". Verify bytes.
import hashlib, json

def verify_lockfile(lock, registry):
    problems = []
    for name, meta in lock["packages"].items():
        want = meta.get("integrity")
        got = registry.digest(name, meta["version"])   # fetch authoritative hash
        if want != got:
            problems.append((name, meta["version"], want, got))
    return problems

bad = verify_lockfile(json.load(open("package-lock.json")), registry)
if bad:
    raise SystemExit(f"integrity mismatch: {bad}")

四、把安全护栏当成绕过技巧

同一份追踪报告里还有一个极具讽刺意味的细节：UNC6780 把生物与核武器的示意直接粘贴进恶意代码的注释里，目的不是造武器，而是让审查它的安全扫描器「不敢看」——模型的安全策略在这些内容上会拒绝分析或降级处理，恶意载荷于是躲在注释的缝隙里通过。这是一个通用教训：任何「模型会自动拒绝危险内容」的假设，都会被人反过来当成绕过的开关。防守方的对策不是关掉护栏，而是在护栏之外加上确定性检查——签名、哈希、可复现构建。

// 4) Least privilege for coding agents: explicit allowlists only.
const AGENT_POLICY = {
  readRepos: ["org/checkout-service"],          // nothing else is visible
  install: { allow: ["^[a-z0-9-]+$"], deny: ["*-nightly", "*-beta.*"] },
  secrets: [],                                  // agents hold no static secrets
  egress: { allow: ["registry.npmjs.org"], deny: ["*"] },
  maxRuntimeSeconds: 900,
};

function authorize(agentCall) {
  if (!AGENT_POLICY.readRepos.includes(agentCall.repo)) return deny("repo");
  if (agentCall.host && !AGENT_POLICY.egress.allow.includes(agentCall.host))
    return deny("egress");
  return allow();
}

五、先堵四个洞

按报告给出的证据链，优先级最高的四件事是：一，别再让长期令牌躺在 CI 里，改用 OIDC 短时凭据换取发布权限；二，把 AI 编码助手的隐藏工作目录纳入扫描范围，别让缓存区成为法外之地；三，对依赖做来源与哈希校验，让「通过了自动检查」不再等同于「是可信的」；四，对编码 Agent 的权限做最小化——它能读的仓库、能装的包、能碰的密钥，都要显式列出白名单。这四条不解决全部问题，但能挡住报告里描述的那条完整攻击链。

# 5) Agent-driven attacks are fast. Alert on rate, not just on type.
ALERT_RULES = [
    # one actor pulling many packages in a short window
    {"name": "bulk-download", "threshold": 50, "window_sec": 60},
    # a brand-new publisher touching a high-download project
    {"name": "new-publisher-hot-project", "min_stars": 1000, "account_age_days": 2},
    # token used from an unexpected network range
    {"name": "token-egress-anomaly", "expect_regions": ["us-east-1"]},
]

def triage(events, rules):
    fired = []
    for rule in rules:
        window = [e for e in events if e["kind"] == rule["name"]]
        if len(window) >= rule.get("threshold", 1):
            fired.append((rule["name"], len(window)))
    return fired

print(triage(load_audit_log(), ALERT_RULES))

六、加固清单

落地成五条规则。第一，所有发布走 OIDC，工作流里不出现长期写权限令牌。第二，把 .git、隐藏缓存目录、Agent 工作目录全部纳入 secret 扫描与文件完整性检查。第三，依赖锁文件加哈希校验，CI 里禁止无锁安装。第四，给编码 Agent 单独的凭据与网络出口，绝不与人工账号共用。第五，把「模型拒绝」当软信号、把「确定性校验」当硬门禁。GTIG 的这份报告真正的价值不在于又列了几个 CVE，而在于它告诉我们：对手已经把 AI 装进了自己的流水线，防守方的流水线也得跟上。还有最便宜的一条：凡是具备发布权限的凭据都要轮换。一个存活上限一小时的凭据，不可能被悄悄复用一个月。