Anthropic实名制启示：企业AI调用身份归属与审计三层治理

6 月 15 日，Anthropic 推送了一封隐私政策更新邮件：7 月 8 日起，Claude Free、Pro、Max 个人用户可能被要求上传政府签发的身份证件，外加实时人脸比对。触发场景涵盖 Agent 任务执行、系统风控标记、平台随机抽查，验证方为第三方服务商 Persona。

消息一出，技术圈里很快就吵了两层。第一层很直观：账号安全和区域封锁——Claude 不在中国大陆官方支持范围内，提交身份证等于主动告诉平台“我来自灰色地带”，账号大概率直接玩完。但第二层的讨论更有意思：Anthropic 为什么要下这么重的手？

把政策原文翻来覆去读几遍，你会发现 Anthropic 真正焦虑的根本不是“用户身份”本身。它担心的是 Agent 能力越来越强、多步骤任务越来越复杂，但平台压根不知道每次操作背后站着谁。出了问题怎么追溯？怎么及时阻断？翻译成技术语言，简单来说，其实就是三个关键词：可追溯、可问责、可阻断。

三层治理模型：从人到调用再到行为

这三个词放到企业内部的 AI 调用场景里，可以说是同样适用——而且坦率地说，大多数企业在这三件事上的现状，比 Anthropic 焦虑的个人用户实名要棘手得多。

过去一年和不少技术团队交流下来，一个共同画面是：API Key 散落在项目配置文件、CI/CD Secret 变量、甚至飞书聊天记录里。有人离职几个月了，Key 还在后台默默跑着。问到“这个月 API 花了多少”，财务只能给一个总数，分不清是哪个项目、哪个人、调的哪个模型。这种“糊涂账”在很多公司里是常态。

Anthropic 花大力气解决个人用户的身份问题，但企业内部，AI 调用几乎处于匿名使用状态。这个差距值得我们仔细拆开来看。

第一层：身份实名。 谁在操作？Anthropic 的做法是上传身份证、确认屏幕后面是个有身份的人。出事了找得到人。

第二层：调用实名。 这次 API 请求是谁发的？哪个项目？哪个环境？走的是哪个 Provider？一个 30 人团队同时用着多个大模型，技术负责人需要的不是每个人的身份证号，而是每次调用的归属——请求落在哪个项目上、是谁的 Key 发出的。这才是企业场景下真正有意义的“实名”。

第三层：行为实名。 调完之后呢？该不该拦？花了多少？某个项目本月预算是 200 美元，已经跑到 180 了，要不要提前告警？凌晨三点某个 Key 突然刷了 500 次调用——是正常的夜间任务还是 Key 泄露了？这些问题，显然是 Anthropic 的身份证模式覆盖不了的。

Anthropic 的实名制卡在第一层。但企业内部真正需要的，是后两层：调用归属和行为审计。这是 API 调用层面的“实名制”，跟身份证无关，跟 Key 的治理有关。

技术方案：给每次调用打上“身份证”

这个问题听起来复杂，但工程解法其实挺直接的，本质上就是在请求链路上加一层透明袋里。核心设计分三块：

虚拟 Key 映射。 开发者的代码里不直接写云厂商的原始 Key，而是用一个没有实际权限的虚拟 Key。这个虚拟 Key 绑定了人和项目——谁生成的、属于哪个环境、能调哪些模型、月度额度多少。真正的云厂商 Key 存在本地加密存储中，不进代码仓库，也不进 CI/CD 变量表。虚拟 Key 泄露了可以随时吊销、重新签发，不会影响生产环境的原始凭证。

本地袋里拦截。 所有 API 请求经过一个本地 HTTP/HTTPS 袋里。袋里在转发前完成三件事：校验虚拟 Key 是否有效、检查调用额度是否充足、检查请求的模型是否在白名单内。正常请求做到零感知透传，只有规则被触发时才介入——发出告警或直接阻断。

// 袋里层核心逻辑伪代码func (p *Proxy) Handle(req *http.Request) (*http.Response, error) { // 1. 从 Header 中解析虚拟 Key vKey := req.Header.Get("X-Virtual-Key") // 2. 校验身份与归属 identity, err := p.lookupIdentity(vKey) if err != nil || identity.Status == Revoked { return p.deny(403, "invalid credential") } // 3. 检查额度与白名单 if err := p.policyEngine.Check(identity); err != nil { return p.deny(429, err.Error()) } // 4. 替换为真实 Key 并透传 req.Header.Set("Authorization", "Bearer " + identity.RealKey) return p.upstream.RoundTrip(req)}

数据不出域。 袋里跑在本地，调用日志、Token 消耗、账单数据全部留在执行机器或内网的存储里。这与 Anthropic 把验证数据交给 Persona 的逻辑类似——谁处理敏感数据，谁就对数据负责。对于企业来说，这意味着一件事：API 调用记录不需要推给任何第三方平台。

和阿里云生态的结合点

如果团队已经在使用阿里云 API Gateway 或函数计算，可以在现有架构上叠加类似的调用治理层。阿里云 API Gateway 的插件机制支持自定义认证逻辑，结合 RAM 角色授权，能为每个 API Key 分配最小权限。再配合云监控（CloudMonitor）和日志服务（SLS），就能构建一套“调用前鉴权、调用中记录、调用后可审计”的完整闭环。

问题的核心，是把“谁在调什么”这个信息维度补进现有的监控体系里。API 流量的总量曲线告诉你花了多少钱，但不会告诉你花在哪个项目上。补上这层归属信息，才算真正把从计量到治理的链条走通了。

总结

Anthropic 这次的实名制，本质上是在给 AI 调用装一块“水表”：知道流量从哪来、到了哪去、谁来买单。这个方向当然没错，只是对企业来说，需要装的不只是一块总表——而是每个房间、每个水龙头的分表。

从技术角度看，整套体系不过是一个带策略引擎的本地袋里层。但它的价值不在于代码复杂度，而在于把“调用归属”从一个需要手动管理的流程问题，变成一个自动生效的基础设施能力。常态无感，异常介入。这和 Anthropic 实名制的设计哲学，本质上是同一件事。