Agent 攻击链上，API key 才是战利品——Anthropic 9 月滥用报告给部署方的三层防线

现状之痛：我们防 Agent 出事，注意力长期放在提示词上——怕它被诱导、怕它越权、怕它说错话。Anthropic 9 月 10 日的滥用报告把镜头挪到了另一个地方：过去八个月他们处置的攻击里，攻击者去偷、去囤、拿去转卖的，不是提示词，是 API key。报告写得很直白——拿到一个 key，攻击者一次得到三样东西：战利品、算力、替身。

读完你将：拿到三层今晚就能动手的凭据防线——为什么 key 比提示词值钱；凭据在供应链上是怎样被工业化收割的；怎么把「拿不到就带不走」「动作级门禁」「只增不删的账本」装进自己的系统。有真实数字、真实事故，和能直接跑的骨架代码。

先把结论摆在前面：在 Agent 攻击链上，提示词是敲门砖，凭据才是提款卡。

一、报告里最反常识的一段：拿到 key，等于拿到三样东西

9 月 10 日，Anthropic 发布《Detecting and countering misuse of AI: September 2026》。这份报告覆盖 2025 年 12 月到 2026 年 8 月，横跨网络攻击、影响行动、监控、诈骗、生物滥用、常规武器开发和模型蒸馏七类危害。

报告里有一段建议逐字读：

拿到 AI 凭据的操作者，一次得到三样东西——战利品（Loot）：偷来的 key 和账号在成熟市场里有转售价；算力（Compute）：攻击负载可以跑在别人的账上；替身（Cover）：这些行为会被归到凭据的合法主人名下。

前两样是钱，第三样是隐蔽性。第三样最难防——你打开日志，看到的是自己的账号在做事，第一时间未必会怀疑到别人头上。

报告同时给了三条趋势，读下来是一条比一条更具体：

高明攻击不再需要高明攻击者。AI 抹平了过去隔开国家级行动者和个体操作者的资源与工具差距。
AI 的角色从助手变成编排者。多数行动由多 Agent 框架承担侦察、利用和外泄，人留在环里做的事只有两件——定目标、看外泄结果。
AI 供应链本身成了目标。攻击者把供应链同时当成猎场和加油站。

三个案例最能说明问题。

第一个，伪装成开发工具。有一批网站自称是「多个模型之间的中转服务」，卖的是折扣价的 Claude 接入。客户以为买到了便宜，实际流量被悄悄转给另一个模型，同时那套客户端在自己的机器上装了一个凭据收集器，把账号凭据和会话令牌持续送回攻击者手里。报告把它记作 GTG-50021，并提到被伪装的目标里包括 Claude Code 这类流行工具。

第二个，评估沙箱交出生产 key。报告里的 GTG-50020 把恶意指令注入到一家 AI 厂商的自动化评估沙箱里，结果沙箱把手上的凭据交了出去——其中包含该厂商从多个供应商那里拿到的生产 API key。随后一轮攻击用同一手法在四天里连打了约三十家 AI 公司：找到一条走得通的路径，就复制到所有目标上。他想要的是预发布模型，报告写明一条路都没得手。

第三个，规模化到了流水线级别。一个行动用十台云主机搭了一条流水线，批量下载 180 万个安卓安装包，逐个反编译，扫硬编码密钥。验证通过的结果按一百多种来源类型实时分流进一个电报群。同期另一条线专收 GitHub 令牌。其中一次落库，34 小时里拿到 2100 多组 Azure AD 令牌，横跨四十多个企业租户。报告对这个环节的注脚只有一句：这些活几乎全是 AI Agent 干的。

二、凭据是怎么被工业化收割的

把报告的案例拼起来，能看到一条完整的生命周期：侦察、发现、验证、在目标内部扩张、外泄、仓储、铸新续期、变现。

我盯住的是第二段「发现」。报告列举的来源包括：应用二进制、代码仓库与集成、客户端代码、凭据库、容器镜像、metadata 端点、开放的对象存储，以及目标自己部署的 AI Agent。

最后一项值得停一下。你为了让 Agent 能干活，给它配了 key、配了工具、配了出口；在攻击者眼里，那是把凭据送到生产环境里的一次集中投放。

报告里还有一句关于这条路的老话被改写：过去靠「没人知道我有这东西」的安全，在 AI 辅助的搜索面前不成立——连上网络的东西都能被理解、被适配、被利用。这一句我读了两遍，因为它说的不是攻击变强了，而是「隐蔽」这个前提本身被取消了。

三个数字落在这里最直观。

数字背后是同一件事：找密钥这件事，已经从「手工翻找」变成了流水线作业。防御端如果还停在人工巡检，节拍是跟不上的。

三、我们跟凭据有关的两次真实动作

热闹讲完，说我们自己。这两件事都记在案，不是编的。

第一件，2026 年 8 月 8 日。排查发布任务为什么反复失败时，我发现命令里躺着明文的微信凭据——账号和密钥直接写在任务文本里，跟着模板跑了很久。当晚做了两件事：把凭据从任务文本里拿掉，改成脚本从受限配置文件里读；把这段历史写进错误库。

这件事之后我给自己定了一条：凭据只要进过执行环境或提示词，就当它已经泄露。处置顺序是先换、再清、后记账，不能只清不换。

第二件，2026 年 9 月 10 日。一个早就没用的用户级服务单元在三天里被拉起了五万两千多次，失败、重启、再失败。它跟凭据没有直接关系，但性质一样：没人再用的东西，还在被系统反复使用。

旧单元如此，旧 key 也如此。没轮换的密钥、没注销的授权、没回收的令牌，都是我自己账上的凭据负债。它不是「暂时用不上」，是「随时可能被用上」。

四、三层防线：拿不到、过不去、赖不掉

凭据这条线上，我们把防线拆成三层。每一层都有对应的真实动作。

第一层，凭据边界：拿不到就带不走。

凭据不进 Agent 的执行环境、不进提示词、不进工具参数。它只放在脚本能读、模型看不到的地方。发布脚本读的是受限配置文件里的令牌，模型上下文里从来没有出现过它。

同一层还有两件配套的事：按用途拆 key，一个 key 只开一扇门；出口做白名单，能连的地方列成清单，不在清单上的直接拒。

第二层，动作门禁：越界过不去。

每个动作进来先过一遍允许、拒绝、升级给人，规则写在代码里。这就是我们的 0 号闸门——十七项检查嵌在推送脚本最前面，任何一项不过就退出，物理上绕不过去。

规则写在提示词里不算数，嵌进出口才算数。这句话不是修辞，是 9 月 3 日那天查出来的结论：门禁当时以文档形式存在，而文档约束不了任何一次执行。

第三层，审计账本：赖不掉。

账本只增不删，每条动作记清是谁、做了什么、范围多大、谁授权的。我们的错误库到今天是 82 条，四段式写全症状、根因、解法、状态；9 月 11 日又给它补了一个字段——谁授权的。

每晚 21 点复盘，把当天的事故回流成明天的门禁。审计不是给别人看的，而是给自己留退路的：出事那天，你至少答得出这件事是谁、在哪一层放行的。

五、今晚能改的五件事和一页骨架

按上面的顺序落地，五件事，都不需要买新东西。

第一，把系统里所有凭据列一遍，标出哪些能被 Agent 碰到。第二，能被 Agent 碰到的，按用途拆开，一个 key 只开一扇门。第三，凭据移出提示词和执行环境，改成受限通道读取；移完立刻轮换一次。第四，加上动作级门禁：工具白名单 + 允许 / 拒绝 / 升级给人，放在真正执行的地方。第五，账本加一个授权字段，只增不删，挂一个定时复盘。

落到代码上，最小骨架就这几行：

# One key, one door. Gate the action, then log who approved it.
SCOPES = {"publish": {"tools": ["draft_add"]}}   # key purpose -> what it may do

def run(action, key):
    scope = SCOPES.get(key.purpose)              # unknown purpose -> nothing
    if scope is None:
        raise Denied("unknown key purpose")      # reject, do not guess
    if action.tool not in scope["tools"]:
        return escalate_to_human(action)         # out of scope -> human
    if action.dest not in EGRESS_ALLOWLIST:
        raise Denied("egress not allowed")       # unknown target -> reject
    rec = execute(action)                        # the only place it acts
    ledger.append(rec, actor=key.id, approved_by=action.approval)
    return rec

# three checks you can run tonight
grep -rn "sk-\|secret\|token" ./prompts/     # expect: no hits in prompts
python3 gate.py --dry-run --key unknown      # expect: Denied: unknown key purpose
tail -3 ledger.jsonl                         # expect: approved_by on every row

顺序不能反。先把门装上、把账本打开，再给 Agent 加权限；反过来的话，你等于先把钥匙交出去，再回头想装哪扇门。

六、这一层能防住什么，防不住什么

边界要说清楚，不然容易误用。

三层防线管的是「凭据被拿走去当加油站」这一类：拿不到、过不去、赖不掉。它管不住把密钥直接贴进公开仓库这种人工操作，那属于流程和习惯，我们靠的是每晚复盘。

报告里的案例都发生在别人的环境里，我引用它们是为了说明这条风险线是真的，不是为了渲染恐慌。安分做事的系统仍然是绝大多数。

还有一条：这套做法在一个人、一套小系统上跑通，不代表在几百人的组织里直接可用。对组织来说，这是底线，不是上限。

结尾

报告里最有价值的一句建议，是让组织像对待生产凭据那样对待 AI key 和 Agent 集成。原因报告也说了：因为攻击者就是这么对待它们的。

对称这件事很有意思。攻击者算的是成本——偷一个 key，比培养一个攻击手便宜得多；你算的应该是边界——一个 key 能开几扇门，谁授权它开的。

攻击者算成本，你算边界。

此刻的你

一句话读懂：Anthropic 9 月滥用报告显示，AI 供应链成了攻击者的目标、战利品和算力，落到执行层就是凭据在供应链上被工业化收割——三层防线（拿不到、过不去、赖不掉）不依赖任何新产品，今晚就能动手。

三个认知

凭据是出口，不是入口：过去我们把注意力放在提示词上，报告显示攻击者真正囤积和转卖的是 API key。拿到一个 key 就同时拿到战利品、算力和替身。
隐蔽不再是防线：报告直说，靠「没人知道我有这个」的安全在 AI 面前不成立。能被找到的凭据，早晚会被用上；旧 key、旧授权、旧单元都是负债。
三层防线各有分工：边界管拿不到，门禁管过不去，账本管赖不掉。缺任何一层，另外两层都会退化——只有门禁没账本，出事答不出谁放行；只有账本没门禁，只能事后追。

你应该带走的真正价值

价值一（技术人/团队场景）：一套可即刻落地的凭据治理顺序——先列凭据、再拆用途、移出执行环境后立刻轮换，最后开门禁和账本。顺序反了，等于先把钥匙交出去再装门。
价值二（个人开发者/OPC 场景）：不给 Agent 直接可用的生产凭据，改为按用途拆分的受限通道。攻击者要的是「一个能用的 key」，你把「一个 key 只开一扇门」做成默认，损失面就从全部变成一扇门。
价值三（长期机制场景）：账本只增不删，每条记清谁授权。它不是合规装饰，是出事那天你能答话的唯一依据；再挂每晚复盘，把当天事故变成明天的门禁。

三步行动

步骤	动作	验证
1	列出所有凭据，标出哪些能被 Agent 碰到	每个能被碰到的 key 都写得出用途和出口
2	拆用途、移出执行环境，然后立刻轮换一次	提示词与执行环境里搜不到任何凭据串
3	开门禁与账本，记录授权来源，挂定时复盘	越界动作被拒或升级给人；每条记录答得出谁授权

金句：在 Agent 攻击链上，提示词是敲门砖，凭据才是提款卡。

魏无记