“Agent调个API也能出事？”——直到我看了那六道关
上个月团队复盘一个生产事故：一个客服Agent在回答用户问题时，顺手把带身份证号的对话日志贴进了境外大模型的上下文。日志里查不到谁干的——IAM显示是“研发账号”在调，可研发那天根本没上线。
当时觉得是个别案例，补个日志就完事了。
直到8月初看到新闻：国家标准化管理委员会正式下达了《智能体应用安全基本要求》强制性国家标准计划（计划号：20263116-Q-252），全球首部面向智能体安全的强制性国标。18个月倒计时。归口中央网信办，中国移动、中国电子技术标准化研究院、国家计算机网络应急技术协调中心牵头起草。
文件列了六项必须达标的安全能力：资产盘点与管理、身份认证与权限、知识库与数据管控、多模态内容防护、全链路审计追溯、应急处置与熔断。
我对照自己的代码仓库一条条看过去——六关里至少四关是空的。
第一关：资产盘点——你根本不知道公司有多少个Agent在跑
41号文要求“全域调用可见可盘点”。
听起来简单？真动手试试。API Key散落在代码仓库、配置文件、聊天记录、共享文档里。内部部署的开源模型三四个团队各跑各的。还有员工自费买的第三方AI工具账号——企业完全不知情，但发出去的数据是企业自己的。
人工填表？今天填完明天又变了。
我们现在的做法：把所有AI调用收口到一个统一入口，从流量侧自动发现所有调用关系。入口上线那一刻，资产图谱自动生成。之后每次新增调用自动注册——不需要任何人填表。
第二关：身份权限——IAM管人，谁管Agent？
大多数企业有成熟的IAM。但这些系统设计的时候，调用方是“人”。
现在调用AI的不只是人——还有Agent、自动化脚本、CI/CD流水线。
前面说的那个事故就是这样：研发部署了一个Agent，Agent调用大模型时用的是申请人的身份，但发起任务的其实是运营的自动化工作流。出了事，日志显示研发在调——研发根本没操作过。
解法不是换IAM，是在IAM上叠一层AI调用身份映射。真人员工走SSO，Agent走服务账号或虚拟凭证。每种身份的权限粒度打到模型、操作、环境和额度级别。“最小权限”不是口号：某个Agent只能调DeepSeek V4，日上限500次，只能在生产环境用。
架构层面怎么做——一张表说清楚
第三关是最疼的——数据管控
员工把客户身份证号、手机号直接贴进对话框——比你以为的普遍得多。有团队在一家200人的公司摸底，一周内检测到47次包含个人信息的AI调用，其中12次发往境外模型。
41号文要求在数据进入外部模型之前完成识别和管控。事后审计没用——数据一旦发出去了就发出去了。
工程做法：调用出口做实时检测——PII自动识别、敏感词过滤、按数据密级决定放行、脱敏还是阻断。身份证号自动打码、银行卡号直接拦截、内部项目代号做关键词白名单。
这些不是概念。我们已经在生产环境跑了两个月，拦截率从最初的30%提到了92%。剩下8%还在跟“多模态越狱”斗智斗勇。
说点实在的，18个月看上去不短。但对照六关自查一遍，你会发现差距比想象中大。而且这是强制国标，不是推荐性标准。
我的建议：别等。先把第一关和第二关做起来——资产盘点和身份映射是基础，不做这两步，后面的数据管控和审计追溯都是空中楼阁。
安全从来不是锦上添花——是活下来的前提。
讨论：
你们团队目前Agent调用的身份认证是怎么做的？IAM能覆盖Agent级别的权限粒度吗？评论区聊聊踩过的坑。
