• AI 技能
• 应用安全

本篇技术指南讲解 skills/security-audit/AI-AND-LLM.md 这份面向「模型参与信任敏感决策」场景的专项攻击类文档：它定义了一组区别于传统 Web 攻击类的上下文注入、记忆投毒、工具参数注入、动作绑定、MCP 身份混淆与输出泄露攻击类别，并给出统一的验证规则。阅读本文后，你可以在 coding-agent 的六阶段安全审计工作流中，把该文档当作 companion block 原样注入 hunter/verifier 提示词，对聊天机器人、RAG 流水线、持久化 Agent 记忆、工具调用循环、MCP 服务器与客户端等目标执行「有边界、有结果、可验证」的 LLM 专项审计。

这份文档解决什么问题

在 SKILL.md 定义的 security-audit skill 中，ATTACK-CLASSES.md 提供了适用于普通 Web 应用、库、CLI、服务的基础攻击类（注入、访问控制、资源与文件处理、密码学与秘密、业务逻辑、功能滥用与数据泄露、链式漏洞与信任边界、通配符、显而易见的问题）。但当目标代码中有语言模型参与信任敏感决策时——例如模型输出被当作 SQL、shell、文件路径、URL 或特权 API 的输入；检索结果进入他人会话上下文；工具描述或 MCP 响应被当作策略——传统攻击类就不够了。AI-AND-LLM.md正是为此补充的模型专属委托层（model-specific delegation layer）。

它的适用范围（文档原话）覆盖：聊天机器人与助手、RAG 流水线、持久化 Agent 记忆、Agent/工具调用循环、MCP 服务器与客户端、用不可信输入拼装提示词的代码、以及消费模型输出并据此采取动作的代码。核心关注的数据流始终是：

untrusted content → model or memory → capability, authority, or sink

即：不可信内容 → 模型或记忆 → 能力、权威或 sink。

文档明确要求与ATTACK-CLASSES.md配合使用而非替代它：传输、访问控制、查询构造、文件系统使用、输出渲染仍然是普通信任边界，本文件只覆盖模型委托这一层；大型目标建议按「检索 / 记忆 / 工具分发 / MCP / 输出处理」切分给不同 hunter。

在六阶段审计工作流中的位置

这份文档不是独立运行的流程，而是被 HUNTING.md（Phase 2 覆盖引导的猎捕波次）和 RECONNAISSANCE.md（Phase 1 侦察与 companion 选择）编排的 companion block：

• Phase 1：侦察代理在架构摘要中记录「需要该 companion 的源可见信任边界」；选择依据是侦察发现目标存在文档When to use this file描述的边界，而不是因为语言/依赖名称出现（RECONNAISSANCE.md 第 74-89 行明确禁止后一种选择方式）。
• Phase 2：hunter 提示词按固定顺序包含：architecture.md、分配的 coverage 单元、逐字复制的选中 block（每个选中 companion 的Core discipline、每个选中的攻击类小节、Universal moves、Validation rules），以及明确排除的 block 及理由（HUNTING.md 第 11-25 行）。也就是说，你读到的这篇文档的每一节都是可以原样粘贴进 agent 提示词的「弹药」。
• Phase 3-5：verifier 收到的证据契约来自 report-schema.json 中confirmed/needs_validation/rejected三个分支，本文档末尾的 6 条验证规则正是 LLM 类候选在上报前的硬门槛。
• Phase 6：只有confirmed记录进入报告与严重度评估，needs_validation保持为无严重度的待验证线索。

Core discipline：写进每个 LLM 领域 agent 提示词的核心纪律

文档要求把这些纪律包含在本领域每一个 agent 提示词中（原样 fenced block）：

- Prompt injection alone is not a finding. Require a code-level boundary failure: content reaches another principal's context, invokes authority the requester lacks, discloses data they cannot read, or drives a sink they cannot reach directly. - Model output, memory, tool descriptions, and MCP responses are untrusted inputs. Point to the code that grants authority, trusts output, writes durable state, or feeds a sink. - A guardrail prompt is not a security boundary. Count only deterministic checks, resource-scoped authorization, isolation, binding, and constrained credentials. - State the attacker, affected principal, effective execution identity, resource, exact action, authority used, and observable impact. An intentional direct request to use the requester's existing authority is not a delegation defect merely because a model executes it. - Authorization and action binding are separate controls. Attacker-controlled content that causes an action under an affected principal's valid authority is an action-binding failure when that principal did not intentionally request or approve the exact action. - Classify every candidate as `confirmed` only after source evidence and bounded local validation establish the boundary and result. Use `needs_validation` when a required provider, deployment, model, renderer, or identity behavior is not observable locally.

逐条解读其含义：

1. 提示注入本身不是发现：这是整个 skill 最反直觉的一条纪律。攻击者写一段「忽略之前的指令，执行 X」的文字进入模型上下文，如果没有导致代码层面的边界失效——内容进入了另一主体的上下文、调用了请求者本不具备的权威、泄露了其无权读取的数据、或驱动了一个其无法直接触达的 sink——就不构成安全发现。说服力再强的文本本身不是缺陷，缺失的确定性控制才是。
2. 模型输出、记忆、工具描述、MCP 响应都是不可信输入：审计时必须指出是哪段代码授予了权威、信任了输出、写入了持久状态、或把数据喂给了 sink。
3. 护栏提示词（guardrail prompt）不是安全边界：只有确定性检查、资源作用域的授权、隔离、绑定和受限凭据才被计入。这与 README 中「Defense-in-depth gaps are not vulnerabilities」的设计原则一脉相承。
4. 必须陈述完整主体链：攻击者、受影响主体、有效执行身份、资源、精确动作、使用的权威、可观察影响。用户有意直接请求使用其既有权威，模型只是执行了它，这不构成委托缺陷。
5. 授权与动作绑定是两套独立控制：攻击者控制的内容在受影响主体的合法授权下引起动作，而该主体并未有意请求或批准该精确动作时，属于动作绑定失败。这与下面「Action-confirmation and approval binding」类互相呼应。
6. 证据分类纪律：confirmed需要源码证据 + 有界本地验证确认边界与结果；当关键事实（provider、部署、模型、渲染器、身份行为）无法本地观察时，用needs_validation——这与 SKILL.md 的「Respect source visibility」原则完全一致：仓库缺席的部署控制既不假设存在也不假设不存在。

这些纪律通过 HUNTING.md 第 11-25 行的提示词装配规则，被逐字写入每个涉及 LLM 边界的 hunter 提示词，与report-schema.json的三个 verdict 分支一起约束候选的输出形态。

上下文、检索与记忆攻击类别

这些类别聚焦一个问题：内容如何进入模型上下文，以及它在那里获得了什么权威。所有类别标注subagent_type: general，即由负责广泛调查与有界本地执行的general委托代理运行。

经由检索或摄取内容的间接注入（Indirect injection through retrieved or ingested content）

攻击者可以写入一份 RAG 文档、被索引的页面、文件、邮件、issue 正文、工具响应或元数据，使其进入另一主体的模型上下文。审计步骤：

• 追踪谁可以写每个来源（RAG 文档库、索引、邮箱、issue 追踪器）；
• 检索如何划定范围（是否按租户过滤、是否在查询中执行 ACL）；
• 谁的会话消费该内容；
• 在该会话中启用了什么能力。

隔离、资源授权、对消费主体意图的绑定要分别检查。缺陷是缺失的确定性控制，而不是有说服力的文本本身——这条与 Core discipline 第 1 条完全一致。

跨会话或跨租户上下文渗漏（Cross-session or cross-tenant context bleed）

对话历史、嵌入向量、检索结果或提示缓存按键过宽。例如：会话 ID 只包含会话而非用户；租户字段存于对象上但某个查询路径没带；共享缓存跨租户复用。验证要点：

• 租户和 ACL 过滤器必须存在于查询本身；
• 每一个缓存键都要检查（会话键、嵌入键、检索结果键、提示缓存键）；
• 对象上存了租户字段不等于强制实施——如果存在备选查询、共享缓存或批量路径漏掉了它，就是缺陷。

一个典型的审计路径是：找到所有读取检索结果/嵌入缓存的代码，比较其键空间与租户作用域，再核对批量/导出路径是否走同一套过滤。

持久化记忆投毒（Persistent memory poisoning）

攻击者控制的内容或模型摘要被写入记忆，之后塑造另一个任务、另一个用户或一个特权会话的决策。审查项：

• 谁可以创建、更新、合并、删除记忆条目；
• 记忆的来源（provenance）与租户范围；
• 低信任观察（low-trust observations）是否会变成持久的指令或事实；
• 检索时能否区分「用户偏好」与「工具策略」。

文档给出了重要的反例边界：用户有意保存、且仅用于该用户有意且被允许的请求的记忆，不构成跨边界发现。也就是说，记忆投毒类必须证明「攻击者可控的写入」+「后续跨主体读取或特权决策」两个环节都成立，单一环节不足以成文。

提示角色与来源混淆（Prompt role and provenance confusion）

提示词拼装让不可信文本伪装成系统消息、先前轮次、工具结果、策略或记忆记录。需要警惕的实现模式：

• 字符串拼接（system + user_content直接+拼接）；
• 无类型的历史记录（把不同类型的消息混在一个数组里）；
• 调用者可控的 role 字段（客户端传入role: "system"）；
• 序列化往返丢失来源标签（把消息 JSON 序列化再反序列化后 role 信息丢失）。

确认的前提：被伪造的来源标签改变了一个确定性信任决策，或触达了一个有意义的能力。如果伪造来源对代码决策毫无影响，则只是提示词工程问题，不是发现。

工具与动作攻击类别

工具参数注入到下游 sink（Tool-argument injection into a downstream sink）

模型产生的参数到达 SQL、shell、文件、URL 抓取或特权 API，而handler 侧没有验证。关键方法论（文档原话）：

• 把工具 schema 当作输入解析层，而不是安全控制；
• 从解码后的调用开始，逐个字段追踪到 sink；
• 结构化输出（structured output）只是收窄了形状（shape），它不建立授权、安全路径、安全 URL 或查询语义。

例如：一个run_sql(query: string)工具即使有 JSON Schema 约束，只要 handler 直接把query拼进 SQL 执行，模型输出（可能被检索内容污染）就能驱动任意查询。审计时要看 handler 是否在 schema 校验之后再次验证值语义。

过度代理与混淆代理权威（Excessive agency and confused-deputy authority）

Agent 使用服务身份或宽泛凭据，而工具 handler 没有在命名资源上重新检查请求主体的权限。验证两点：

• 有效执行身份（effective identity）是什么——是请求者的身份还是服务身份？
• 调用者能否通过正常产品界面执行该精确操作？

文档给出的反例：共享凭据 + 强制按用户查询范围（per-user query scope）不是缺陷。这条与 Core discipline 第 4 条配套：模型执行用户有权执行的既有动作不是缺陷；缺陷在于模型以超出请求者的权威执行了动作。

动作确认与批准绑定（Action-confirmation and approval binding）

用户批准了一个描述的动作，但执行可能使用了被更改的参数、不同的资源、不同的主体或后来的模型轮次。文档列举的绑定维度：

意图或确认必须绑定到：规范化后的工具名（normalized tool name）、完整参数对象（complete argument object）、请求者、目标、金额、过期时间、批成员资格（batch membership）。

两个必须审查的场景：

• 确认后的变异：用户批准「转账 100 给 A」，执行时参数对象里金额或收款人被改；
• 重试与恢复会话：一次批准不得授权一个被变异或重复的副作用——重试逻辑是否原样重放已批准的动作、恢复的会话是否继承旧批准。

此外，攻击者控制的内容在受害者合法授权下引起副作用，即使通用授权允许受害者执行该操作，只要受害者未有意请求或批准精确动作，就构成动作绑定缺陷。

工具 schema 与分发器不一致（Tool-schema and dispatcher disagreement）

schema 接受了别名、额外字段、重复键、强制转换、嵌套自由对象或越界值，而分发器/handler 对其解释不同。检查方法：

• 对比 schema 校验、规范化（canonicalization）、生成的绑定代码、handler 默认值四者；
• 在值变成资源选择器或安全相关选项的地方再次验证。

典型例子：schema 允许id字段为数字或字符串，handler 用字符串比较而校验用数字比较导致"1"与1走不同路径；或 schema 接受额外字段但 handler 把它们当作幂等键。

无界委托动作循环（Unbounded delegated action loops）

一个有界的请求可以排队发起重复的消费、发送、变更或外部 API 工作，而没有：

• 每请求预算（per-request budget）；
• 每动作授权（per-action authorization）；
• 取消机制；
• 幂等性控制。

审计重点是共享成本、配额、其他用户或持久状态的冲击。文档特别强调验证纪律：不要通过耗尽服务来测试，要用代码级核算（code-level accounting）和有界本地循环。

MCP 与子代理信任类别

子代理与 MCP 信任继承（Sub-agent and MCP trust inheritance）

委托任务收到的是完整会话、凭据、记忆或能力，而非完成任务所需的最小权威（least authority）。检查：

• 每次调用携带的主体与租户；
• 能力收窄（capability narrowing）是否存在；
• 凭据受众（credential audience）是否与目标服务匹配；
• 委托结果返回时是否被当作不可信输入。

这与 HUNTING.md 中的任务工具机制相关：skill 本身的委托就强调「独立的 scratch/ 与父级持有的 artifacts/」以及角色、写隔离、提示词、独立性边界——这条纪律在审计被审目标时同样适用。

MCP 服务器与工具身份混淆（MCP server and tool identity confusion）

调用或结果按攻击者可影响的名称路由：服务器名、工具名、请求 ID、资源 URI 或模型选择的别名，而不是按认证连接和未决请求路由。需要确认：

• 两个服务器能否声明同一工具或资源身份；
• 重连（reconnect）是否改变绑定关系；
• 一个服务器的响应能否满足另一个服务器的未决调用（pending call）。

例如：如果客户端用工具名作为键存储「未决请求 → 回调」，而两个 MCP 服务器注册了同名工具，攻击者服务器就能抢先应答受害者的未决调用。

MCP 元数据与 schema 当策略（MCP metadata and schema as policy）

MCP 对等端提供的工具描述、资源元数据、提示词、补全提示或 schema 被当作策略或授权信任。文档的定位很精确：这些字段可以引导模型，但不能授予能力。审计时找到当元数据与策略冲突时仍然权威的确定性元素：

• 确定性允许列表（deterministic allowlist）；
• 服务器身份检查（server identity check）；
• handler 授权（handler authorization）。

输出与泄露攻击类别

不安全的输出渲染（Insecure output rendering）

模型输出到达正在执行的 HTML、Markdown、模板、URL 或命令 sink，而没有该 sink 要求的编码与策略。对浏览器渲染：

• 验证自动加载资源（auto-loaded resources）与 CSP 或净化措施——具体检查项在 CLIENT-SIDE.md（该文件是浏览器源的 companion）；
• 渲染器行为在仓库之外时，候选标记为needs_validation——因为浏览器是否执行某标签/协议取决于渲染器版本与配置，这属于「无法本地观察」的关键事实。

敏感上下文提取（Sensitive context extraction）

组装好的上下文包含凭据、另一用户的数据、私有源码或本身就授予访问权的策略值，而用户可影响的输出暴露了它们。审计方法：读提示词组装代码和数据抓取代码。文档的反例：泄露不跨越数据边界的通用指令或行为不是发现。

Universal moves：适用于上述所有类别的通用动作

文档给出三组通用打法，可以注入任何 LLM 类 hunter：

1. 先画四张图：每个执行身份、每个能力、每个可写的上下文或记忆来源、每个输出目的地。然后把起点的主体连接到终点的权威。
2. 反向追溯：从有副作用的工具出发，向后经过分发器、schema、确认、模型上下文、检索、摄取；从持久记忆读取出发，向前追踪每个写入者。
3. 比较路径差异：对同一动作比较直接、队列、重试、恢复、批量、委托六条路径。最强的门禁（gate）必须在参数定稿之后、每个副作用发生之前生效——重试/批量路径漏掉最强门禁正是动作绑定类的高发根因。

Validation rules：上报任何发现前的 6 条硬性验证规则

文档规定，在 LLM 领域上报任何发现之前必须应用以下规则（这是 hunter 提示词的一部分，也是 Phase 3 verifier 的复核依据）：

1. 命名被跨越的边界与可观察结果：攻击者、受影响主体或共享资源、执行身份、目标、未授权或未请求的动作/泄露。
2. 混淆代理权威主张：证明工具缺少请求者+资源的授权，且攻击者无法正常执行同一动作；动作绑定主张则相反：证明攻击者控制的内容在受影响主体权威下引起了该主体未有意请求或批准的动作——有效的通用授权不构成意图证据。
3. 记忆或检索主张：同时引用攻击者可控的写入和后来的跨主体读取或特权决策；没有可达消费者的共享记录不够。
4. 动作绑定：确立有意请求或规范化后的已批准对象（如有），与 handler 实际使用的对象对比；确认本地可观察的未请求动作、变更、重复或权威变化，且不把测试扩展到有害执行；schema 不一致则对比规范化校验对象与 handler 对象。
5. MCP 身份主张：验证认证连接、请求关联、工具命名空间、有效凭据；需要外部服务器身份或部署路由时标记needs_validation。
6. 分类纪律：confirmed只用于完整源码追踪 + 有意义结果；needs_validation用于某个未解决的具体边界事实，且必须说明解决它所需的有界本地或 owner 观察检查。

这些规则与 VALIDATION-AND-REPORTING.md 的 verifier 契约一致：verifier「从仓库源码和有界本地证据出发试图反驳候选」；needs_validation永远不是投机想法的停车场，而是「具体未解决的阻塞事实」。

与结构化输出 schema 的衔接

当 LLM 类候选通过上述验证规则后，它必须被写成 report-schema.json 三个分支之一，并由 validate-findings.cjs 校验（node <skill-dir>/validate-findings.cjs <output-dir>/findings.json）。与本领域最相关的约束：

• confirmed：必须含root_cause、intended_behavior、有序trace（entrypoint → propagation → sink）、evidence、conditions、目标中立的execution（含payloads、instructions、非空observed_result）、remediation、severity、confidence；overall_severity不得超过已验证的impact。对 LLM 类发现，execution应使用目标原生界面（API/HTTP 输入、库调用、消息、文件 fixture 等），而不是要求端点或线上环境。
• needs_validation：必须含claimed_root_cause、trace、evidence、非空blockers、至少一个validation_plan.local或validation_plan.deployment；不得有严重度、execution、remediation或已确认的根因。deployment是 owner 观察检查（配置/身份/路由/策略/运行时事实），不是对线上目标的探测。
• rejected：记录被证伪的候选，防止未来运行在无新证据时重复该主张。

validate-findings.test.cjs 中的测试（如「rejects severity above demonstrated impact」）直接保障了「LLM 类发现不得夸大影响」这条纪律：把impact.score设为medium而overall_severity设为high会被 validator 拒绝。该测试文件还覆盖了重复指纹、不安全源码路径（包括 Windows 设备名CON/PRN/NUL等）、控制字符注入到诊断输出等场景，说明整个 skill 的输出层对「不可信内容进入信任敏感结构」本身也是对抗性设计的。

与相邻 companion 的边界划分

为了避免与仓库其他领域文档职责重叠，AI-AND-LLM.md明确界定了边界：

• 浏览器渲染/客户端：模型输出到达 DOM、postMessage、浏览器存储等浏览器侧 sink 时，具体检查在 CLIENT-SIDE.md——AI 文档只负责指出「输出进入渲染 sink」这一环节并引用该文件，浏览器执行行为超出仓库时标记needs_validation。
• 传输/访问控制/查询构造/文件系统/输出渲染：这些仍然是普通信任边界，归 ATTACK-CLASSES.md 管理。例如检索 SQL 的查询构造走普通注入类，模型上下文/记忆/工具委托这一层才走本文档。
• 原生/webview 桥：webview 桥的原生侧由 DESKTOP-MOBILE-AND-LOCAL-IPC.md 覆盖，服务端 CSRF/会话/认证回调由 WEB-PROTOCOL-AND-AUTH.md 覆盖（其提问角度是「HTTP/身份层能否混淆操作所属的主体、请求、保证级别或令牌」）。

审计一个 LLM 系统的完整操作路径

结合本文档与 skill 六阶段流程，对 LLM 目标发起专项审计的可执行路径是：

1. 侦察（Phase 1）：用 RECONNAISSANCE.md 的 Agent 1c 清单「模型上下文/工具参数」入口面，盘点模型输入来源（检索、记忆、工具响应、MCP）、输出 sink（SQL、shell、文件、渲染、命令）与并行路径；按「检索 / 记忆 / 工具分发 / MCP / 输出处理」拆分 coverage 单元。
2. 猎捕（Phase 2）：把本文档的Core discipline、命中的攻击类小节、Universal moves、Validation rules逐字复制进对应 hunter 提示词，与 HUNTING.md 的核心猎捕方法一起执行；hunter 只写自己的scratch/，返回结构化 JSON。
3. 验证（Phase 3-5）：fresh verifier 从源码与有界本地证据反驳每个候选；只有完整源码追踪 + 本地可观察结果的才能confirmed，关键部署/渲染器事实未决的保持needs_validation。
4. 上报（Phase 6）：报告区分已确认发现与待验证线索，needs_validation不分配严重度。

关键要点速查

• 提示注入不是发现：必须有代码级边界失效（进入他人上下文 / 调用无权权威 / 泄露不可读数据 / 驱动不可达 sink）。
• 模型输出、记忆、工具描述、MCP 响应 = 不可信输入。
• 护栏提示词 ≠ 安全边界：只认确定性检查、资源作用域授权、隔离、绑定、受限凭据。
• 授权与动作绑定是两套控制：合法授权下的未批准副作用 = 动作绑定失败。
• schema 是输入解析，不是授权：每个字段从解码调用追踪到 sink。
• 记忆投毒需成对证据：攻击者可控写入 + 可达的跨主体读取/特权决策，缺一不可。
• MCP 按认证连接与未决请求路由，不能按可影响的名称路由。
• confirmed需源码证据 + 有界本地验证；needs_validation是具体未决事实，无严重度。

• AI 技能
• 应用安全