有人在网上找到一家提供「打折 Claude」的中转商，装了对方提供的客户端，看着像 Claude Code()，用起来也像。
他不知道的是：请求被悄悄转到了另一个模型，配套工具还在偷取他的 Anthropic() 账号凭据，再卖给其他中转商。
这是 Anthropic 2026 年 9 月威胁情报报告里记录的 GTG-50021 案例。同一节还描述了另一种持续窃取凭据的手法：恶意客户端留在电脑上，用户换了密钥、重新登录，它就继续收集新的密钥和会话凭据。
如果开发者把这个客户端装在公司电脑上，发给模型的代码会经过哪些服务？这台电脑上还存着哪些可能被窃取的凭据？这些情况，IT 部门能查清楚吗？
01 / MODEL VERIFICATION
买到的究竟是谁的模型
这份报告里，AI 访问权本身已经成了黑产的商品：有人偷密钥，有人转卖账号，还有人用假客户端继续收集凭据，供给下游中转商。
Anthropic 可以封禁涉事账号、公布恶意域名，并改进检测机制。企业内部使用哪些客户端、接入哪些服务，则需要由企业自己管理。
通过第三方渠道接入模型的团队，还需要确认一件事：接口虽然能正常调用，实际提供的模型和功能是否与购买时的承诺一致？
核验模型服务时，除了返回的模型名称，还需要检查接口结构是否符合约定，工具调用、PDF 输入和思考过程等能力是否可用，以及返回的 token 用量是否异常。开源项目 veridrop 提供了这些检测功能，可以将结果与官方基线对比，也支持自托管和通过 API 提交检测任务。
不过，检测到异常不等于发现了造假。比如，多次请求返回的缓存读取量都一样，可能只是因为它们复用了同一段提示内容。要判断计量是否有问题，需要改变用于缓存的内容，观察读数是否随之变化，再用相同请求对比可信渠道的结果。
即使模型确实来自官方，中转站仍可能留存请求。因此，模型来源、计费方式和数据处理方式需要分别核查。
这些工具可以检查供应商提供的模型服务，但一次检测只能反映当时的情况。企业还需要统一维护供应商清单、定期复测并处理异常，同时记录每次调用实际使用的上游，便于后续追查。
02 / FOUR QUESTIONS
企业要查清的四个问题
第一问：密钥在谁手里？
如果开发者从群里复制同一把「公司的 key」，再填进各自的工具配置，一把密钥就可能出现在十几台电脑上。一旦泄露，很难仅凭调用记录中的密钥信息区分使用者；要撤销某个人的访问权限，只能停用这把共享密钥，其他人也得更换配置。
第二问：请求发给了哪家上游？
公司采购了模型服务，开发者却未必都在用。有人可能把工具接到了另一家中转站，也有人用的是个人订阅。IT 部门需要查清楚：大家实际在用哪些服务，公司的代码和数据发给了谁。
第三问：AI 准备执行什么操作？
Claude Code、Cursor() 这类工具可以运行命令、修改文件和调用外部服务。判断操作是否安全，需要结合命令内容、运行环境，以及工具持有的凭据和权限。同一条删除语句，在测试库和生产库中执行，后果完全不同。
客户端审批可以拦截部分危险操作，但每位开发者的审批设置可能不同。Claude Code 还提供了 --dangerously-skip-permissions 启动参数，允许用户跳过权限检查。
第四问：发出去的内容里有没有客户数据？
开发者提交给 AI 的排错日志可能包含手机号和访问令牌，SQL 查询结果中也可能包含客户记录。如果请求发出前没有经过内容检查，这些信息就会一并发送给上游服务。
企业通过防火墙控制网络访问，通过统一认证管理账号。接入 AI 工具后，还需要管理模型访问权限、统计调用费用，并在请求发出前检查敏感数据。对于模型生成的命令，则需要在工具执行前检查风险。
03 / OPERATION SAFETY
Claude Code 如何检查 AI 要执行的操作
针对第三问“AI 准备执行什么操作”，Anthropic 在 Claude Code 中提供了 auto 模式，在工具执行前检查操作风险。2026 年 8 月 14 日起，Claude Code 的 Pro、Max、Team 套餐新会话开始默认使用这一模式；用户已经固定的默认设置不受这次变更影响。
auto 模式先根据权限规则处理工具调用，再将需要进一步判断的调用交给分类器，识别破坏性删除、敏感数据外发和危险代码执行等风险。操作被拦截后，Claude 会尝试调整方案；连续被拦截时，则恢复人工审批。
Anthropic 公布了一项受控实验：研究方付费招募了 1,053 名测试人员，在他们执行测试任务的过程中，将一次审批提示中的命令替换为危险命令。人工审批的拒绝率为 13.6%，auto 模式对同一组命令的拦截率为 89%。这一结果表明，在该实验条件下，自动检测比人工审批识别出了更多危险命令，但仍存在漏判。
但 auto 模式只在 Claude Code 中提供。如果团队还在用 Cursor 或自研 agent，公司怎样才能让这些工具遵守同一套安全规则？
我们的答案是将模型请求统一接到网关，在请求发出、结果返回时按规则检查，并同时检查模型要求工具执行的操作。不过，网关看不到开发者电脑上的全部情况。命令能访问哪些文件、能不能修改生产数据库，还得靠本地权限、沙箱和数据库授权来限制。
04 / GATEWAY GOVERNANCE
网关可以管什么
要实现这样的统一管理，企业需要在各类 AI 工具和上游模型服务之间建立统一的接入与治理入口。ZStack Zentrix 正是面向这一场景设计的企业级 AI 网关：它将原本分散在各个工具中的模型配置和访问凭据集中起来，由管理员统一配置可用模型与上游服务，开发者则使用企业分发的密钥发起调用。
在此基础上，可以通过密钥管理、路由策略、内容护栏和调用记录，对请求进行策略检查，并持续记录调用方、实际使用的上游和用量，为费用核对与异常排查提供依据。
密钥：上游凭据由管理员保管
管理员在网关中配置上游供应商的密钥，开发者使用网关签发的访问密钥。网关收到开发者的请求后，使用对应的上游凭据调用模型服务。
管理员可以为不同人员和应用分别签发密钥，以便区分调用来源，并在需要时单独撤销某一把密钥，不影响其他使用者。
网关密钥被窃取后仍可能被冒用，但攻击者无法直接从中取得上游密钥。管理员可以限制这把密钥的权限和额度，或直接撤销它。如果电脑已经安装了开头提到的恶意客户端，还需要清除恶意软件，并检查其他凭据是否泄露。
上游：按供应商和模型分别核验
模型核验需要按“供应商 + 模型”分别进行。比如说，一家供应商提供的 Sonnet 没有问题，但是 Opus 可能被注水了。
为此我们设计了五级探针，分别检查接口格式、token 计量、实际能力、签名和回答特征，并根据模型及接入渠道选择适用的检测项：
01 接口格式。 比对响应字段、消息标识、结束原因和错误格式，寻找协议转换留下的异常特征。例如，响应中出现另一家模型服务特有的字段，就会被记录为核查线索。对于云平台封装的接口，按对应渠道的格式比对，避免把正常的协议差异判为异常。
02 token 计量。 用一组固定的中文、代码、空白和数字内容发起测试，将返回的 token 数与可信渠道的基线比较，同时对照相同条件下流式与非流式请求的用量。基线按模型和接入渠道匹配，用于发现计数偏差，以及只在某一种请求方式下出现的异常。
03 实际能力。 根据模型声明支持的能力，分别测试思考过程、提示缓存、工具调用和图像输入。例如，重复发送满足缓存条件的请求，检查是否命中缓存；指定工具调用，检查返回的工具名和参数是否符合约定。检测结果列出未通过的项目及响应证据，供管理员定位能力缺失、配置或协议适配问题。
04 签名往返。 对支持思考签名的接口发送两组请求：一组原样传回模型返回的思考块，另一组修改其中的签名，再比较上游是否接受。以 Claude 为例，signature 字段承载加密后的完整思考内容。探针按对应接口的校验规则比对结果，检查原始内容能否正常使用、篡改是否被识别。
05 回答特征。 向待测服务和可信渠道发送同一组固定提示，比较回答与参考输出的差异。考虑到模型输出的波动和版本变化，将这项结果作为辅助证据，与前几项检测结果一并展示，不单独据此判定模型身份。
但如果中转站将测试请求原样转发给官方服务，同样可能通过签名检测。因此这些测试结果只代表本次测试中上游对签名的校验情况，而不能反应中转站是否留存请求，也没法检测出日常调用实际使用的模型。
我们计划在供应商页面展示各级检测结果和依据，并提供手动核验与定期核验功能。发现异常后，由管理员调查原因，决定是否联系供应商或停用服务，系统不自动切换路由。
操作：检查模型返回的工具调用
模型通常以结构化数据返回工具调用，其中包含工具名和参数。如果响应经过网关，且网关支持解析对应协议，就可以在客户端收到工具调用前检查这些内容。
我们在网关返回工具调用前加入分类器，结合用户请求和待执行操作，检查下载脚本后直接运行、敏感数据外发、破坏性删除、生产变更、权限提升和凭据暴露等风险。
例如，开发者要求 AI 清理测试数据，但模型返回的命令包含已知的生产数据库地址。配置相应规则后，网关会将这次操作交给分类器判断；如果判定需要拦截，网关将停止向客户端返回该工具调用，并向模型说明原因，要求重新生成方案。
模型重新生成的操作仍需接受检查。按当前设计，一次响应最多重试三次，达到上限后仍未通过检查，则停止重试并提示用户。分类器超时或不可用时，系统按管理员配置的故障策略处理。分类和重新生成都会产生额外调用及费用。
管理员还可以配置内部域名、仓库、存储桶等信息，帮助分类器识别操作涉及的系统。即使目标是内部系统，也需要检查操作是否越权，例如接收数据的系统是否有权保存这些敏感信息。
操作检测在服务端执行，不受开发者本地审批设置的影响，检查范围限于经过网关、命中规则且能够解析的工具调用。客户端自行执行的操作和绕过网关的请求不在检查范围内，分类器也无法使用请求中未提供的本地环境信息。
内容与记录：按策略检查，按调用追溯
管理员可以通过策略检查请求中的敏感信息，并选择脱敏()或阻断。模型响应也可以纳入检查，具体范围受协议和输出方式限制，部分规则仅支持非流式响应。
通过调用记录、路由记录和用量数据，可以查询谁调用了哪个模型、请求是否成功、消耗了多少 token。
将检测结果与调用记录关联后，管理员可以根据敏感信息命中记录查询调用方、上游和处理结果，也可以从应用费用追溯到具体调用。
05 / ENTERPRISE DEPLOYMENT
网关如何接入企业环境
网关放在哪里？
Zentrix Gateway 支持私有化部署，调用记录保存在企业自己的机房或云环境中。模型请求发送给管理员配置的上游服务，操作检测所需的上下文则发送给所选分类器。相关数据是否离开企业环境，取决于这两类服务的部署位置。
会增加多少延迟？
真伪核验旁路独立运行，业务请求无需等待检测完成，但检测本身会消耗上游调用额度。操作检测设计了两种模式：「仅记录」模式异步检查，响应返回不等待检测结果；「拦截」模式先检查再放行，发现风险时会要求模型重新生成方案。后者会增加分类器判断和模型重试的耗时，具体延迟随分类器响应速度、工具调用数量和重试次数变化。
会不会成为单点？
网关的可用性由转发服务、负载均衡、存储和上游服务共同决定。多副本部署()可以降低单个网关实例故障的影响，但存储和上游服务仍有各自的故障风险。控制台故障期间能否继续转发请求，则取决于数据面是否能够独立使用已有配置。
怎么让开发者实际走网关？
对于支持自定义模型接口的客户端，开发者使用网关地址和公司分发的访问密钥接入，上游供应商的密钥由网关统一保管。模型调用、流式输出和工具调用通过网关支持的协议转发，具体覆盖范围随客户端功能和登录方式而有所不同。
个人订阅和其他直连渠道不经过网关，也不受网关策略约束。这部分访问由企业的终端策略和网络出口规则控制。
国产模型能不能一起管理？
国产模型同样使用统一的供应商配置、路由策略和用量统计。内容护栏按接口支持的协议生效；在模型核验方案中，各类模型采用对应的参考基线，签名检测仅用于支持该机制的模型。
06 / UNIFIED MANAGEMENT
从个人接入到企业统一管理
接入网关后，开发者使用各自的访问密钥，管理员统一配置上游和访问权限。发现异常调用时，管理员可以查记录、撤销凭据，再决定是否调整供应商或规则。
开头的假 Claude 案例中，用户购买模型服务，却安装了窃取凭据的恶意软件。风险同时存在于客户端、模型供应商和请求传输过程，仅确认模型能够正常调用，很难发现这些问题。
AI 网关将分散的模型接入纳入统一管理，企业可以查询调用方、上游、用量和检测结果，也可以集中调整凭据与访问策略。网关负责模型调用的管理和检查，终端防护负责识别恶意软件，操作系统和数据库负责限制执行权限，各自处理不同环节的风险。
Zentrix Gateway 提供企业模型接入、凭据管理、路由策略、内容护栏和调用记录。模型真伪核验与操作检测将按上述方向继续推进。欢迎联系我们，了解接入方式与演示。
文章来源：从“能用”到“可信”：企业 AI 接入的治理跃迁https://news.zol.com.cn/1249/12491628.html
