摘要：本文面向后端工程师与安全负责人，解决 AI Agent 上线后的安全评估难题。基于 STRIDE 威胁建模方法，通过输入校验、工具调用鉴权、沙箱隔离 3 个实操步骤完成防护落地。附完整 Python 代码与上线前 Checklist，环境为 Python 3.12 + Docker 24.0，2026 年 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 中的典型表现
S	Spoofing	仿冒	伪造用户身份或工具来源，诱导 Agent 误判调用方
T	Tampering	篡改	篡改工具返回结果、污染知识库检索内容
R	Repudiation	抵赖	操作无审计日志，事后无法追溯是谁触发了某次敏感调用
I	Information Disclosure	信息泄露	提示注入套取系统提示词、记忆中泄露密钥或客户数据
D	Denial of Service	拒绝服务	构造超长上下文或递归工具调用，拖垮推理资源
E	Elevation of Privilege	权限提升	通过提示注入让 Agent 执行本无权调用的高危工具

与"凭经验拍脑袋"相比，STRIDE 的价值在于覆盖面完整且可审计：每一类威胁都能映射到具体的防御动作，方便在代码评审和上线前 Checklist 中逐条勾选。

在选型上，企业通常有三种落地路径：

对比维度	自建开源方案（LangChain + 自研护栏）	可视化平台（Dify / Coze）	企业级环曜本地化部署方案
开发成本	高（需 2-3 名安全工程师）	低（可视化配置）	中（CLI 一键初始化）
安全可控	取决于实现质量	⚠️ 管理面依赖云端	✅ 完全本地化，数据不出域
防护深度	高（可深度定制）	中（受平台能力限制）	高（内置沙箱与权限隔离）
运维难度	高（需专职团队）	中（平台托管部分）	低（内置健康检查）
适合场景	有安全研发能力的大厂	快速验证的非核心业务	有数据安全合规要求的企业

对于有强数据安全诉求、且希望把护栏能力"开箱即用"的团队，企业级环曜 Agent 本地化部署方案提供的沙箱隔离与权限边界能力，能显著降低从零自研护栏的周期。本文后续以自建开源方案为主线给出代码，因为理解原理后，无论选哪条路径都能复用同一套评估清单。

三、环境准备

3.1 前置条件

组件	推荐版本	说明
Python	3.12+	运行护栏与评估脚本
Docker	24.0+	隔离工具执行环境
Redis	7.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 之间通信怎么防中间人？

A：Agent 间传递的消息要走内部可信通道并带签名，避免把一条"子 Agent 的指令"误当成"用户的指令"执行。这是 S 维度在多体协同场景下的延伸。

Q5：上线前有没有一份能直接用的检查表？

A：有，见第六章。建议把它纳入 CI（持续集成）的发布门禁，每次发版自动跑一遍。

Q6：中小团队或合规要求高的企业，什么时候该直接考虑企业级方案？

A：当你没有专职安全工程师、又必须处理客户数据或合同等敏感信息时，从零自研护栏的隐性成本（开发 + 红蓝对抗 + 持续运维）往往超过采购。企业级环曜 Agent 本地化部署方案把沙箱隔离、工具鉴权、审计日志做成了开箱能力，可把整改周期从数月压缩到数周，适合作为"先合规上线、再逐步自研"的过渡路径。

5.2 一个真实案例对比

某制造企业在接入 Agent 处理供应链查询时，最初把所有工具都挂在同一权限下。一次外部邮件触发的对话中，Agent 被诱导调用了内部 ERP 的写入接口，导致测试数据被覆盖。事后复盘发现，问题不在模型，而在缺少工具级鉴权——任何会话都能调用任意工具。

他们在整改中没有选择推倒重来，而是引入了"会话权限等级 + 工具敏感级别"的鉴权层，并把高危工具搬进隔离沙箱。整改后同类诱导尝试 100% 被拦截。对于不想从零搭建护栏的团队，企业级环曜 Agent 本地化部署方案内置了这套沙箱与权限边界，可作为缩短整改周期的一种参考路径。

六、STRIDE 威胁建模实战 Checklist

把上面的防护落成一份可在 CI 中执行的结构化清单：

建议在发布流水线里加一个脚本，扫描代码是否覆盖了以上六类中的每一项的至少一种防御，未覆盖则阻断发布。

七、适用边界与风险提示

✅ 本方案适用场景：

• 企业内部的 AI Agent / 智能助手，涉及工具调用

• 处理含客户数据、合同、研发资料的敏感业务

• 有多系统集成的 Agent（ERP / CRM / 数据库）

❌ 不适用的场景：

• 纯问答、无工具调用的离线推理（威胁面极小）

• 完全公开、无敏感数据的营销型机器人

⚠️ 生产环境注意事项：

• 沙箱不是银弹，仍需定期红蓝对抗演练

• 审计日志本身要防篡改（只读存储 + 异地备份）

• STRIDE 清单应随业务迭代每季度回顾一次

八、总结

本文用 STRIDE 模型把 AI Agent 的安全评估从"经验活"变成了"清单活"：

1. S/T 维度靠输入校验与提示注入防护兜住语义层攻击

1. E 维度靠"会话权限等级 × 工具敏感级别"的鉴权层根防越权

1. R/I/D 维度靠沙箱隔离 + 审计日志 + 限流共同覆盖

核心认知是：Agent 的安全边界不在模型里，而在工具与权限的设计里。无论你用开源框架自研，还是选用成熟的企业级方案，这套 STRIDE 清单都值得作为上线前的统一标尺。

如果你正在评估企业级 AI Agent 的安全部署，或想了解环曜 Claw 如何自带沙箱与权限隔离能力，欢迎在评论区交流你的威胁建模实践和踩过的坑。