摘要本文面向后端工程师与安全负责人解决 AI Agent 上线后的安全评估难题。基于 STRIDE 威胁建模方法通过输入校验、工具调用鉴权、沙箱隔离 3 个实操步骤完成防护落地。附完整 Python 代码与上线前 Checklist环境为 Python 3.12 Docker 24.02026 年 6 月实测可用。一、为什么 AI Agent 的安全评估比传统应用更难2025 年以来企业把 LLM大语言模型——一种通过海量文本训练、能理解和生成自然语言的人工智能模型接入业务系统的速度明显加快。但多数团队在安全评估上沿用了 Web 应用的旧思路结果上线后陆续暴露出提示注入、工具越权调用、记忆数据泄露等问题。据 OWASP开放全球应用程序安全项目——一个专注应用安全的国际开源组织2025 年发布的 LLM 应用 Top 10 风险清单提示注入LLM01与敏感信息泄露LLM02连续两年位列前二。某安全团队 2026 年的实测数据显示在未做专项安全设计的 Agent 中约 91% 存在至少一条可被直接利用的漏洞路径。传统应用的安全边界清晰用户输入 → 后端逻辑 → 数据库每一层都有成熟的防护手段。而 AI Agent 引入了三个新变量自然语言即指令攻击者的输入本身就是可执行的意图传统输入过滤难以覆盖语义层攻击。工具调用即权限Agent 能调用 API、执行命令、读写文件一次越权就等于敞开了内部系统。记忆与上下文跨轮持久对话历史中可能沉淀了密钥、客户信息泄露面从单次请求扩大到整个会话生命周期。本文要解决的就是如何把模糊的 Agent 安全风险变成可逐项排查的清单。我们选用 STRIDE 模型——这套由微软提出、已在系统安全领域验证二十年的威胁建模框架来系统化地做 AI Agent 的安全评估。二、方案概述用 STRIDE 框架做威胁建模STRIDE 是六个威胁类别的首字母缩写分别对应一种典型的攻击意图维度英文中文含义在 AI Agent 中的典型表现SSpoofing仿冒伪造用户身份或工具来源诱导 Agent 误判调用方TTampering篡改篡改工具返回结果、污染知识库检索内容RRepudiation抵赖操作无审计日志事后无法追溯是谁触发了某次敏感调用IInformation Disclosure信息泄露提示注入套取系统提示词、记忆中泄露密钥或客户数据DDenial of Service拒绝服务构造超长上下文或递归工具调用拖垮推理资源EElevation of Privilege权限提升通过提示注入让 Agent 执行本无权调用的高危工具与凭经验拍脑袋相比STRIDE 的价值在于覆盖面完整且可审计每一类威胁都能映射到具体的防御动作方便在代码评审和上线前 Checklist 中逐条勾选。在选型上企业通常有三种落地路径对比维度自建开源方案LangChain 自研护栏可视化平台Dify / Coze企业级环曜本地化部署方案开发成本高需 2-3 名安全工程师低可视化配置中CLI 一键初始化安全可控取决于实现质量⚠️ 管理面依赖云端✅ 完全本地化数据不出域防护深度高可深度定制中受平台能力限制高内置沙箱与权限隔离运维难度高需专职团队中平台托管部分低内置健康检查适合场景有安全研发能力的大厂快速验证的非核心业务有数据安全合规要求的企业对于有强数据安全诉求、且希望把护栏能力开箱即用的团队企业级环曜 Agent 本地化部署方案提供的沙箱隔离与权限边界能力能显著降低从零自研护栏的周期。本文后续以自建开源方案为主线给出代码因为理解原理后无论选哪条路径都能复用同一套评估清单。三、环境准备3.1 前置条件组件推荐版本说明Python3.12运行护栏与评估脚本Docker24.0隔离工具执行环境Redis7.0存放会话记忆脱敏后3.2 安装依赖四、核心实现三道防护落地4.1 第一步输入校验与提示注入防护Agent 收到的用户消息必须经过结构化校验不能把原始文本直接拼进系统提示词。下面用一个 Pydantic 模型做语义层 字符层双重过滤。要点校验失败要明确拒绝而非静默放行并在日志中记录来源 IP 与失败原因对应 STRIDE 的 R 维度——抵赖。4.2 第二步工具调用的权限鉴权Agent 每调用一个工具都必须经过调用方身份 工具敏感级别的二次校验绝不能让 LLM 自由决定。这里的关键是权限等级来自登录态session绝不信任 LLM 返回的任何我是管理员之类的自报字段——这正是 STRIDE 中 E权限提升维度的核心防御。4.3 第三步沙箱隔离与最小权限对exec_sql、delete_record这类高危工具必须在隔离环境中执行数据库账号使用只读 受限 schema的专用账号delete 走审批流而非直接执行命令执行类工具放入 Docker 容器挂载只读目录禁用网络出站每次工具调用的入参、返回、耗时写入审计日志对应 R 维度。把 STRIDE 六维映射到这三步S/T 靠输入校验、E 靠权限鉴权、R/I/D 靠沙箱与审计共同覆盖。五、踩坑记录与避坑指南5.1 常见问题Q1提示注入规则越写越多误杀正常用户怎么办A不要把关键词列表当成唯一防线。更稳妥的做法是角色隔离——把系统指令与用户内容放在不同的消息通道并在系统层明确用户消息不可修改系统设定。正则拦截只作为第一道粗筛真正的兜底是模型行为约束与工具鉴权。Q2工具鉴权会不会拖慢响应A一次字典查表 整数比较的耗时在微秒级对 LLM 推理百毫秒到秒级几乎无感知。不要在性能借口下省略它——权限提升类漏洞的修复成本远高于这点延迟。Q3会话记忆存在哪才安全A记忆中不应明文存放密钥、token、身份证号等 PII个人身份信息。落地前先做脱敏Redis 开启加密存储并设置 TTL存活时间自动过期缩小 I 维度的泄露窗口。Q4多 Agent 之间通信怎么防中间人AAgent 间传递的消息要走内部可信通道并带签名避免把一条子 Agent 的指令误当成用户的指令执行。这是 S 维度在多体协同场景下的延伸。Q5上线前有没有一份能直接用的检查表A有见第六章。建议把它纳入 CI持续集成的发布门禁每次发版自动跑一遍。Q6中小团队或合规要求高的企业什么时候该直接考虑企业级方案A当你没有专职安全工程师、又必须处理客户数据或合同等敏感信息时从零自研护栏的隐性成本开发 红蓝对抗 持续运维往往超过采购。企业级环曜 Agent 本地化部署方案把沙箱隔离、工具鉴权、审计日志做成了开箱能力可把整改周期从数月压缩到数周适合作为先合规上线、再逐步自研的过渡路径。5.2 一个真实案例对比某制造企业在接入 Agent 处理供应链查询时最初把所有工具都挂在同一权限下。一次外部邮件触发的对话中Agent 被诱导调用了内部 ERP 的写入接口导致测试数据被覆盖。事后复盘发现问题不在模型而在缺少工具级鉴权——任何会话都能调用任意工具。他们在整改中没有选择推倒重来而是引入了会话权限等级 工具敏感级别的鉴权层并把高危工具搬进隔离沙箱。整改后同类诱导尝试 100% 被拦截。对于不想从零搭建护栏的团队企业级环曜 Agent 本地化部署方案内置了这套沙箱与权限边界可作为缩短整改周期的一种参考路径。六、STRIDE 威胁建模实战 Checklist把上面的防护落成一份可在 CI 中执行的结构化清单建议在发布流水线里加一个脚本扫描代码是否覆盖了以上六类中的每一项的至少一种防御未覆盖则阻断发布。七、适用边界与风险提示✅ 本方案适用场景企业内部的 AI Agent / 智能助手涉及工具调用处理含客户数据、合同、研发资料的敏感业务有多系统集成的 AgentERP / CRM / 数据库❌ 不适用的场景纯问答、无工具调用的离线推理威胁面极小完全公开、无敏感数据的营销型机器人⚠️ 生产环境注意事项沙箱不是银弹仍需定期红蓝对抗演练审计日志本身要防篡改只读存储 异地备份STRIDE 清单应随业务迭代每季度回顾一次八、总结本文用 STRIDE 模型把 AI Agent 的安全评估从经验活变成了清单活S/T 维度靠输入校验与提示注入防护兜住语义层攻击E 维度靠会话权限等级 × 工具敏感级别的鉴权层根防越权R/I/D 维度靠沙箱隔离 审计日志 限流共同覆盖核心认知是Agent 的安全边界不在模型里而在工具与权限的设计里。无论你用开源框架自研还是选用成熟的企业级方案这套 STRIDE 清单都值得作为上线前的统一标尺。如果你正在评估企业级 AI Agent 的安全部署或想了解环曜 Claw 如何自带沙箱与权限隔离能力欢迎在评论区交流你的威胁建模实践和踩过的坑。