8.0
热点
AI SCORE
技术实践2026-08-20 05:20
AI应用威胁建模：从架构到可测试攻击路径
dev.to · AI#AI安全#威胁建模#安全工程
Editor brief · 编辑速览
系统性阐述AI应用特有的安全风险——文档→上下文→模型行为改变、输出→工具调用→真实影响，区别于传统应用的风险结构，提供可操作的威胁建模方法。
在传统应用中，安全分析通常可以沿着熟悉的结构展开：用户发送输入，业务逻辑处理输入，数据库提供或存储信息，最终产生结果。AI 应用初看起来与此类似，同样有前端、后端、数据库、身份和 API。但关键区别在于信息在系统内部如何改变其角色。
一份文档最初只是内容。检索后，该文档的摘录成为模型上下文的一部分。在上下文中，它不仅能提供知识，还能影响模型的行为。模型输出最初只是概率生成的文本或结构化输出。如果它转化为工具调用、SQL 查询、工单或电子邮件，就会产生真实的效果。正是在这些转换点上，决定了一个 AI 系统是偶尔产生一些无意义的内容，还是攻击者真正侵犯了受保护资产。
因此，一个好的 AI 威胁模型不会简单地描述"提示词注入"、"幻觉"、"数据泄露"和"工具滥用"。那不过是风险宾果游戏罢了。一个有用的威胁模型是一个工作机制，能建立一条可追溯的链条：
系统 → 资产 → 数据流 → 信任边界 → 攻击者目标 → 滥用场景 → 攻击路径 → 控制措施和测试
这条链条才是真正的目标。它将关于"AI 风险"的抽象讨论转化为具体的安全分析，并与工程、架构、测试和运维相连接。
图 1：AI 威胁建模过程从理解整体系统出发，经过资产、安全目标、数据流和信任边界，最终到达具体的攻击者目标、滥用场景和攻击路径。控制措施和可重复的安全测试则从这些攻击路径中推导得出。因此，威胁建模将架构理解与可测试的安全假设直接联系起来。
威胁模型既不是装饰性图表，也不是一般性安全规则的集合。它应该帮助你充分理解一个系统，使可信的安全问题变得可见且可验证。
为此，它至少需要回答六个问题：
系统是什么？ 应用程序提供什么功能，谁在使用它，涉及哪些 AI 组件？
什么值得保护？ 哪些数据、权限、控制机制、身份和输出不能被泄露、操纵或滥用？
信息和决策如何在系统中流动？ 哪些输入、上下文块、工具结果和模型输出在组件之间流转？
信任、控制或效力在哪里发生变化？ 在哪些点上，不受信任的内容获得更多信任、被拉入特权上下文，或被转化为真实操作？
谁可能追求什么目标？ 存在哪些现实攻击者，他们有什么能力，想实现什么效果？
由此产生哪些具体的攻击路径？ 在什么前提下，攻击者可以通过哪些组件和边界来侵犯资产？
当可以从威胁模型推导出具体的审查、控制措施和测试用例时，这个威胁模型就成功了。如果它停留在"可能发生提示词注入"这样的句子，模型仍然过于浅薄。
仅列出"前端、后端、向量存储、LLM、工具"等组件并不能描述安全模型。没有数据流，就无法清楚哪个组件处理了哪些内容，以及信任在哪里发生变化。
仅列出控制措施也不算威胁模型。像"我们使用 RBAC、输入验证和护栏"这样的陈述描述的是防御措施，而不是它们保护什么或背后有什么假设。
特别危险的是只盯着模型本身。许多实际问题并不在"LLM 内部"，而在检索逻辑、提示词组合、租户隔离、工具授权、输出处理或摄取管道中。模型通常是最显眼的节点，但未必是事故的真正现场。
传统应用与 AI 应用之间的核心区别在于，系统内的文本和其他数据不仅仅是经过处理——它们经常成为控制面本身。
简化的经典处理链如下：
输入 → 业务逻辑 → 数据库 → 输出
RAG 系统的工作方式更像：
输入 → 检索 → 上下文选择 → 提示词组合 → 模型 → 输出
智能体系统进一步延伸了这条链：
输入 → 模型决策 → 工具调用 → 工具结果 → 新模型决策 → 操作或响应
在这些架构中，多个信息源对行为产生影响：
这些来源的信任度并不相同。它们也不是同等特权的。然而它们经常最终聚集在一个模型上下文中，在那里技术上的分离远不如经典程序逻辑那样清晰。
由此产生两个特别重要的原则。
原则 1：上下文可以是间接控制
文档文本可以包含事实，但同样容易包含操作指令。如果文本被检索器选中并被提示词构建器拉入模型上下文，其内容可以影响优先级、答案和工具决策。
因此，相关问题不仅仅是：
模型看到了什么数据？
而是什么数据可以影响模型相信什么、优先考虑什么、或做什么？
原则 2：模型输出不是可信的控制机制
模型输出是概率性的。如果它被直接用作工具决策、操作参数、HTML、SQL、代码或 shell 命令，系统就跨越了一条关键界限。一个不安全的建议可能变成真实操作。
模型可以产生建议。然而真实操作的授权应该通过模型外部的确定性、可验证的逻辑来完成。
在进一步的分析中，我们将使用一个内部 AI 支持助手。
员工通过聊天前端提问。后端使用 RAG 从内部知识库确定匹配的内容。提示词构建器将系统指令、用户请求、聊天历史和检索到的文档块组合在一起。LLM 生成响应或提议使用工具。通过工具代理，应用程序可以创建支持工单。
后端 / 编排层
认证与会话层
文档摄取管道
向量存储 / 知识库
日志与监控
这个描述故意比"带 AI 的聊天机器人"更具体。它命名了功能、组件，以及上下文被组装或效力被产生的地方。只有这样才可能确定资产和攻击路径。
资产是任何其泄露、操纵、丢失或滥用会产生相关安全影响的东西。在 AI 系统中，这不仅包括传统数据，还包括控制机制、能力和上下文。
图 2：AI 应用保护的内容远不止传统的业务数据。相关资产不仅包括数据，还包括系统提示词和策略等控制机制、检索块和工具结果等上下文、能力和权限、生成的输出，以及身份、会话和租户信息。每个资产类别都需要自己的安全目标和控制措施。
数据资产包括但不限于：
典型保护目标是保密性、完整性、可用性和租户隔离。
控制资产决定系统应该如何运作：
retrieval selection rules
context composition logic
prioritization between instruction sources
这些资产首先需要完整性、机密性和控制保真度。篡改可能导致系统追求不同目标、绕过边界或处理不允许的内容。
4.3 权限与能力资产
智能体不仅能查看信息，还能执行操作。因此能力本身就是一种资产：
CRM 及数据库访问权限
插件和 API 权限
最重要的目标是授权、最小权限、完整性和可追溯性。
不可靠的模型令人烦恼。拥有广泛权限的不可靠模型则是危险的。
上下文资产在 AI 系统中尤为关键：
流回模型的工具输出
最终组装好的模型上下文
上下文是决策和间接控制的基础。因此上下文的完整性、来源、机密性以及用户或租户之间的正确隔离是独立的安全目标。
4.5 输出也是一种资产
生成的工单内容
SQL、代码或 shell 输出
HTML 和 Markdown 内容
建议或决策
会被自动进一步处理的结构化数据
输出需要完整性以及安全的下游处理。它不能触发不允许的操作，且在渲染或执行前必须经过验证或消毒。
4.6 身份与会话资产
多用户和多租户系统需要在用户、会话、租户、检索范围和工具执行之间建立正确的绑定：
租户或范围上下文
代表其调用工具的身份
这种绑定中的错误可能导致模型在技术层面正确运行，但使用了错误的上下文或以错误的名义运行。
资产与保护目标必须匹配
"数据"这个分类太粗粒度了。一份内部手册、一个系统提示、一项发送邮件的权限和一个检索到的片段都与文本或数据相关，但在安全层面完全不同。
一个实用的启发式方法：
如果这个元素被泄露，会发生什么？
如果它被篡改，会发生什么？
如果它在错误的名称或范围下被使用，会发生什么？
它是否会影响模型看到、优先处理或被允许做的事情？
一旦这些问题中有一个显示出真正的安全影响，你很可能就是在面对一个资产。
数据流描述了信息如何以什么角色、在什么控制下从何处移动到何处。安全问题通常不是出现在单个组件内部，而是出现在组件之间的过渡处。
信任边界是以下任一条件发生变化的地方：
数据跨越到不同的信任区域
控制假设发生变化
内容以更高权限被处理
信息转化为决策相关的上下文
模型输出被转化为真实操作
跨不同用户或租户使用共享基础设施
核心问题是：
为什么从这一点开始，我们比之前更信任这个内容？
图 3：基于 RAG 的支持助手的数据流图，展示了用户输入、检索、模型上下文、工具使用和输出之间的主要信任边界。特别关键的转换发生在：不受信任的内容进入决策相关的模型上下文、模型输出成为现实世界的行动，或工具结果被反馈到 LLM 上下文中。因此，信任边界不仅存在于外部系统边界，还存在于 AI 应用程序内部的多个点上。
5.1 支持助手的典型数据流
用户 → 前端：用户请求
前端 → 后端：请求加上会话和身份上下文
后端 → 检索器：检索查询
检索器 → 向量存储：相似性搜索和过滤文档查找
向量存储 → 检索器：相关片段
检索器 → 提示构建器：检索到的上下文
提示构建器 → LLM：系统提示、用户请求、历史和片段
LLM → 后端：响应或工具意图
后端 / 工具代理 → 工单工具：经过验证的工单调用
工单工具 → 后端 / LLM：工具结果
后端 → 前端：最终响应
各组件 → 日志记录：审计、错误和操作数据
5.2 关键信任边界
不受信任的用户输入进入内部处理。风险包括直接提示注入、资源滥用、上下文操纵和策略绕过尝试。
文档、网站、邮件或文件被摄取后用作上下文来源。风险包括被污染的内容、被操纵的片段和间接提示注入。
文档文本获得对模型响应的直接影响，并可能影响工具决策。这个边界是最重要的 AI 特定转换之一。
概率性输出转化为真实行动。风险包括未授权的工具使用、参数注入、混乱副手问题和多阶段滥用。
工具结果被反馈到模型中。这创建了第二个输入向量，可能包含敏感的、被操纵的或具有指示性的内容。
模型输出被显示、复制、执行或传递给其他系统。风险包括不安全的 HTML 或 Markdown、有害查询、代码执行以及对生成内容的盲目信任。
共享的向量存储、内存层或工具服务不得导致共享可见性。在检索、上下文包含和工具执行之前，必须应用范围和身份检查。
每条边应该记录什么
一个有用的数据流模型不只是记录"后端与 LLM 通信"。对于每条边，应该捕获三件事：
接下来可能会发生什么？
只有在将架构和资产与现实对手联系起来时，威胁模型才真正有用。
6.1 攻击者目标描述的是效果
"提示注入"、"越狱"或"RAG 攻击"不是攻击者目标。它们描述的是技术或风险类别。
目标描述的是预期效果：
泄露机密数据
查看另一个租户的数据
未授权触发工具
绕过护栏或策略
操纵检索或上下文
破坏回答完整性
滥用资源或成本
欺骗用户或影响流程
经验法则：
目标描述的是要实现什么，而不是如何实现。
6.2 典型攻击者
他们对应用程序有常规访问权限，可以发送请求、上传文件或迭代观察行为。
他们控制着系统读取或摄取的文档、网站、邮件或文件。这个角色与间接提示注入和上下文污染尤其相关。
他们拥有合法访问权限，但试图扩大其可见性、改造内部工具或绕过策略。
他们在自己的租户内使用系统，并试图使外部片段、会话、记忆或工具结果可见。
他们不攻击聊天本身，而是影响后来到达模型上下文的 API 响应、工具返回或外部数据源。
6.3 从目标到滥用场景
滥用场景是对角色如何将预期功能反用于系统的一个可信描述。
滥用的功能或边界
示例：角色：外部用户 目标：泄露内部支持内容 前提条件：检索范围过广 被滥用的边界：检索 → 模型上下文 预期影响：机密信息出现在响应中
另一方面，"可能发生提示注入"这样的句子毫无价值：角色、目标、前提条件、系统引用和影响都缺失。
6.4 安全、可靠性和混合案例
并非每个不正确的模型行为都是安全问题。
图 4：并非每个 AI 系统的故障都自动成为安全问题。当可靠性问题影响到受保护资产、权限或信任边界时，它才变得与安全相关。混合案例尤为重要：当与自动化、特权工具或破损的访问控制相结合时，普通的模型或检索故障可能获得真正的安全影响。
系统运行不佳或不可靠，但没有违反任何受保护资产。
hallucination with no connection to real confidential data
irrelevant retrieval results
wrong tool selection with no security-relevant effect
An asset, a permission, or a trust boundary is affected.
another tenant's data appears in the response
a tool executes an unauthorized action
sensitive information gets disclosed from context or logs
manipulated content influences a real action
A quality error becomes security-relevant because it's coupled to rights, assets, or automated downstream processing.
faulty retrieval leads to cross-tenant leakage
a faulty tool selection triggers a real action
a faulty output structure gets automatically processed and produces an effect
The decisive sentence:
Not every act of stupidity is a security incident. It becomes dangerous the moment assets, rights, or trust boundaries are affected.
An attack path is a concrete, plausible sequence of steps through which an attacker reaches their goal. It connects:
An abuse scenario says which function gets abused. The attack path shows how that happens technically.
7.1 Attack Path for Faulty RAG Retrieval
Goal: Disclose confidential content Actor: External user Entry Point: Chat request Precondition: Retrieval is scoped too broadly, or not bound to user rights Components: Frontend, Backend, Retriever, Vector Store, Prompt Builder, LLM Critical Boundaries: User → System; Retrieval → Model Context
The user sends deliberately crafted requests.
The backend generates a retrieval query.
The retriever insufficiently enforces the scope or tenant filter.
Disallowed document chunks get selected.
The prompt builder pulls them into the model context.
The model uses the content in its answer.
Confidential information gets disclosed.
Impact: Violation of confidentiality and tenant separation
Controls: ACL-bound retrieval filters, scope enforcement before search, post-retrieval authorization, context minimization, disclosure tests
7.2 Attack Path for Indirect Prompt Injection
Goal: Manipulate model behavior or tool use Actor: Malicious content supplier Entry Point: An ingested document Precondition: The attacker can place content into a source the retriever considers Components: Ingestion, Chunking, Vector Store, Retriever, Prompt Builder, LLM Critical Boundaries: Content Source → Knowledge Base; Retrieved Context → Model Context
The attacker plants a semantically relevant document.
The document contains manipulative instructions.
The ingestion pipeline chunks and indexes the content.
A matching user query leads to retrieval of the manipulated chunk.
The prompt builder pulls the chunk into the model context.
The model inappropriately treats the contained instruction as actionable.
The response, a tool intent, or a downstream process gets influenced.
Impact: Policy bypass, data disclosure, goal redirection, or tool abuse
Controls: source classification, ingestion governance, context isolation, untrusted-content labeling, tool gating, human approval for sensitive actions
7.3 Attack Path for Tool Abuse
Goal: Trigger a disallowed ticket action Actor: External or internal user Entry Point: A manipulatively phrased request Precondition: Tool calls are not authorized independently of the model Components: Frontend, Backend, LLM, Tool Broker, Ticket System Critical Boundaries: User → Model Context; Model Output → Tool Call; Tool Output → Model Context
The user phrases a seemingly legitimate task.
The model produces a ticket intent and parameters.
The tool broker accepts the model's decision without sufficient policy checking.
The ticket system executes the action within the scope of the service identity.
The tool result flows back into the model.
The model produces further content or follow-on actions.
A ticket gets created with disallowed content, recipient, or scope.
Impact: Process abuse, data handoff, unauthorized action
Controls: external policy engine, least privilege, parameter allowlisting, per-call authorization, confirmation step, audit logging
![The attack chain shows how a malicious document can progress through ingestion, retrieval, and model context until it influences a security-relevant tool call. The impact is not caused by a single "malicious prompt," but by multiple control failures across the system. Source governance, retrieval and scope controls, context isolation, external tool authorization, least privilege, and audit logging interrupt the attack path at different stages.(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/3qnp28lvhd9t80h03dbj.png) Figure 5: The attack chain shows how a malicious document can progress through ingestion, retrieval, and model context until it influences a security-relevant tool call. The impact is not caused by a single "malicious prompt," but by multiple control failures across the system. Source governance, retrieval and scope controls, context isolation, external tool authorization, least privilege, and audit logging interrupt the attack path at different stages.
Why Attack Paths Matter So Much
AI security problems often arise from several small weaknesses:
external or manipulated content enters the system
prompt composition makes it decision-relevant
the model produces a tool intent
an external layer doesn't authorize it sufficiently
the tool output gets processed again without scrutiny