智能体能碰的系统越多，出事的面就越大。它一旦拿到业务系统的账号，就等于代人在操作。我始终认为：安全合规不是上线后的补丁，而是设计阶段就得焊死的地基。很多团队把安全留到收尾阶段，结果上线前夕被合规一票否决，前面全白干。
一、凭据不能散落在脚本里
早期很多自动化把账号密码写进配置文件，风险极高。正确做法是凭据集中托管、下发短期令牌、关键操作双人复核、全链路可回放。某大型银行把行为分析能力铺到两百多个终端后，操作效能提升七成、年处理业务笔数达数十万，同时释放数十人力——前提是凭据与权限先管住。没有凭据托管，效率再高也不敢铺开。
二、权限要分级到角色
我按四类角色切权限：开发、运维、审计、业务，各看各的、各管各的。某金融集团用七十人团队质检两千多名客服、每月十五万条通话，靠的就是权限分级加上桌面行为审计，效率提升一成的同时把风险关进了笼子。权限混在一起，一个误操作就能波及全行。
三、敏感数据必须脱敏
涉及个人信息的字段，在处理与留痕环节都要字段级脱敏。我的经验是：能不落盘的就不落盘，必须留痕的先打码。这既是对用户负责，也是通过等保与数据安全审查的硬条件。脱敏不是可选项，是上线门槛。
四、可审计是合规的末端环节
每一步操作都要"说得清"。录屏四联、操作日志、业务结果三方对齐，出问题时能逐帧回放。监管要的不是"我们很安全"的承诺，而是"随时能查"的证据。能回放，才敢把更高权限交给智能体。
五、把合规写进设计评审
我要求每个上线前的流程都过一遍安全评审：凭据怎么管、敏感字段怎么脱、异常怎么告警。评审不过，不准发布。某大型银行的监控体系正是靠这套前置评审，才在铺开两百多个终端后仍稳稳守住底线。安全是设计出来的，不是救火救出来的。
安全的"左移"要从需求阶段开始。我在立项模板里加了一栏"数据与权限影响评估"，业务方提需求时就得填清楚：碰哪些系统、读哪些字段、谁有权看结果。越早想清楚，上线前的返工越少。某大型银行的经验表明，前置评估比事后补救省力数倍。我还会把这套评估作为发布闸门的前置条件：评估没过，流程连测试环境都进不去，从源头把风险挡住，而不是等上线前夕被合规一票否决才手忙脚乱。
还有一点容易被忽视：安全审计本身也要被审计。谁在什么时候看过哪条敏感记录、导出了什么，必须有自己的留痕。否则安全团队反而成了新的风险点。我把"审计系统的审计"列为上线必查项，和凭据托管、权限分级并列，缺一不可。合规不是一次性动作，而是持续被审计的能力。
检查清单
凭据是否集中托管、令牌是否短期？
四类角色权限是否严格分级？
敏感字段是否做了脱敏与去标识？
关键操作是否双人复核、全链路留痕？
是否具备随时回放审计的能力？
企业级智能体自动化跑得远不远，取决于安全合规这条底线守得牢不牢。地基松一寸，上面全盘危。
