从“能跑通”到“能上线”
企业做智能体，路径几乎都一样：先在沙箱里跑通一个演示——能查数据、能发邮件、能改工单——然后接到真实系统上。从演示到生产隔着三道坎，而且都不是模型能力问题：权限、工具、轨迹。
值得先接受的判断：智能体的安全边界＝权限 ∪ 工具 ∪ 可观测性，三者取并集。权限收得再紧，只要工具描述能被远程改写，就等于权限被远程改写；工具全是白名单，只要日志不记参数，出了事就无法归因与止损。
第一关：权限——把“能做什么”从提示词搬进代码
最常见的做法是在提示词里写“你只能查询，不能修改”。这不是权限控制，是建议——注入成功后模型可以完全忽略它，而系统没有任何一层会拦住。授权应当表达为代码与本体的约束：用户身份 → 可调用的工具集合 → 参数域与行级范围 → 执行身份。
另外两条同样重要：用任务级临时凭证取代长期凭证，由策略决策点签发分钟级、窄范围、与任务绑定的凭证；每个智能体要有独立身份，而不是共用服务账号——共用账号会同时损失权限收敛、单独熔断与责任区分三项能力。
第二关：工具——把攻击面收敛到可枚举
最反直觉的一条认识是：工具描述不是文档，是可执行语义的一部分。模型会读完整段描述并据此行动，而界面通常只显示简化版本——这个信息差就是攻击面。公开研究已演示三种手法：描述里藏指令以诱导智能体读取本地凭据并回传；批准之后静默修改描述；以及直接在描述里改写其他可信工具的行为，让所有邮件改投到攻击者地址。
第三种手法对审计的打击尤其致命：日志里出现的是可信工具名与正常参数范围，外泄完全隐形。这正是必须记录参数全文的原因。
对应的工程动作有四个：描述与全部参数对用户完整展示；对描述做签名并在调用前校验；不同工具与服务器之间做数据流隔离；所有调用经统一网关校验——网关至少承担白名单、参数校验、审计、限流、熔断五件事。供应链也要收紧：依赖只从已审计源拉取、锁版本并校验哈希。
第三关：审计——没有轨迹就没有责任
智能体的日志要求比传统应用高一个量级：传统应用里“谁做了什么”是确定的，智能体里“为什么做”也必须可还原——包括任务身份与委托链、外部内容的来源、模型的计划与被拒绝的动作、每次工具调用的参数全文。
记录只是第一步。检测也要做到机器速度：调用频率异常、动作序列异常（例如“读凭证 → 外发请求”从未出现过）、参数越界、成本突增。而检测之后的动作比检测更重要——默认应阻断当前动作并隔离该智能体，而不是仅记录后继续。
把这套实践压成一句话：不要追求“模型不会上当”，要追求“上当之后做不了大事”。
三条底线
- 权限不写在提示词里：业务意图用提示词，授权边界用代码；
- 工具描述就是代码，日志必须记参数全文；
- 执行必须有隔离与约束：沙箱执行、出口白名单、破坏性动作人工审批。
如果改造资源有限，按这个顺序投入：先建统一的工具网关（投入最小、覆盖面最广），再做权限收敛，最后补参数全文审计。