先看一场九秒的事故
外部有一场被广泛讨论的企业 Agent 事故：智能体在执行任务时自己找到了超级后台入口，九秒之内删光了税务库数据，本地备份一并被清。当事团队的复盘结论只有一句——错不在 agent，是我们不该把删除权限给它，这一定是人的问题。
事后不少企业的反应是收紧：AI 看数据可以，碰业务系统不行。但企业级市场里真正的问题没有变：当竞争对手都在让 AI 直接干活，您靠"不让碰"守住的效率差距会越拉越大。真正该做的不是拒绝接入，是在接入之前把安全设计核到位。
麻烦在于，能力好不好演示里看得见，安全设计到位不到位，演示里看不见。这篇给一份检查清单。
为什么安全设计最容易被漏看
供应商演示 Agent，演的都是能力：自动下单、自动对账、自动出报表。这些环节的表现十分钟就能看清。
安全设计是反过来的——它的价值在没出事的时候显示为零，出了事才显示为无价。评估者天然没有动力深挖，供应商也天然没有动力多讲，两边合力把它漏掉。
所以需要一份不依赖供应商自觉的清单。以下四项，每一项都该在采购评估阶段当面验证，而不是写进合同附件了事。JBoltAI数字员工平台是一套企业级Agent管理平台，这四项也是它自己在管理层里逐条落地的做法，逐项来看。
第一项：授权模型怎么建
问一个直击要害的问题：数字员工的权限从哪来？
两种建法差别巨大。一种是给 Agent 新建独立服务账号，为了对接多系统把权限一次给足——这种账号的权限常常超过任何一个真人员工，九秒删库那场事故，根子就在这里。
另一种是权限跟随员工：数字员工挂载业务系统接口时，共享员工原系统的账号权限，原账号能查什么它就能查什么，原账号没有的权限它一个也拿不到。删除税库需要的超级权限不在任何员工的权限清单里，Agent 自然够不着。
验证方法：让供应商现场演示给数字员工配权限，看权限池的上限是独立账号还是员工账号映射。这一项不达标，后面三项都可以不用看了。
第二项：审计粒度到不到动作级
留痕这件事，几乎所有产品都声称支持，差别在粒度。
记到"登录过系统"这一级，出了事等于没记；要到动作级——每次接口调用、每条数据改动，时间戳、操作主体、变更内容齐全，事后才能还原完整链条。审计的价值分两段：事中管理者翻日志就能核查 AI 这一天动了什么，事后实名操作出了问题能追到人。
验证方法：让供应商现场查一条历史操作日志，看能不能定位到具体某一次调用改了哪个字段。
第三项：配额维度够不够算账
这一项防的不是安全事故，是财务事故。不少企业的 AI 试点死在月底账单上——效果还没验证，各部门的调用费用先失控。
要看配额管控的维度：按平台、部门、个人三个维度设上限，月底的账才拆得开——哪个部门花了多少、花在哪类任务上，一目了然。只有平台级总限额的方案，等于把糊涂账从系统间挪到了部门间。
验证方法：问供应商要一份按部门拆分的用量报表样例，看维度和明细够不够财务对账。
第四项：拦停机制是不是实时的
审计是事后追责，配额是旁路约束，只有拦停是在操作发生的瞬间起作用的实时防线。
要看三件事：删除类、批量改写类的高危操作是否默认拦截；例外情况走不走白名单管理而不是永久放行；终端上发现非法操作，能不能远程停止。三件齐了，高危动作才真正被挡在发生之前。
验证方法：演示环境里故意让数字员工执行一次删除类操作，看是当场被拦，还是执行完才在日志里看到。
清单之外的两句话
两件事不在产品能力覆盖范围内，值得提前想清。
拦得住越权，拦不住错误授权——管理员主动配了过大的权限，系统只能照办，最小授权原则的执行者始终是人。
审计日志的前提是有人定期看——留痕不等于管理，核查动作不落地，日志只是越攒越大的存储开销。
结语
四项检查走完，一家的安全设计是体系还是话术，基本能分辨：授权决定 AI 能碰什么，审计记录它碰了什么，配额限制它碰多少，拦停拦住不该碰的那一下。接入业务系统之前把这四道设计核到位，AI 直接干活这件事，才谈得上可控。
