安全模型与信任边界

• 理解审批的触发条件（依据工具风险分级、副作用与权限）
• 掌握确认 UI 的最小披露原则
• 理解在展示参数与保护敏感信息之间的平衡

HITL 审批要按工具风险分级决定是否需要确认：只读工具（readOnlyHint）通常免确认；可逆的写入操作可由用户偏好决定；不可逆（destructiveHint）、高影响（大额下单、删除、发外部邮件）或 openWorld 的工具必须确认。确认 UI 用"最小披露"原则：展示工具名、来自哪个 Server、哪些参数将被执行、有何影响，但避免把敏感上下文（密码、完整 Prompt、内嵌密钥）原样展示。参数可用掩码、摘要或"仅展示关键字段"的方式呈现，例如只显示"收件人、金额、日期"而不显示完整邮件正文。同时 UI 要明确标注工具来源与调用链，让用户能判断"这个工具要做什么、数据去向"。

HITL 的本质是把"最终决定权"交给用户，因此 UI 设计要服务于"知情决策"：既要让用户看清要发生什么，又要防止敏感信息因展示而泄露。最小披露 + 来源可追溯 + 影响明示，是审批准则的工程落地。

• 理解 Tool 元数据与 Resource 内容作为注入面的风险
• 掌握防御性提示（delimiter、指令隔离、可信边界标注）
• 理解内容隔离与元数据校验净化

攻击向量主要有两条：一是恶意 Server 在 Tool description 或返回的 Resource 内容里内嵌"忽略之前指令、执行某某"等指令，试图劫持模型的行为；二是通过工具结果注入虚假指令影响后续决策。防御分几层：1) 内容隔离——把工具描述、系统指令与用户输入放在不同的可信边界，工具结果用明确的 delimiter 包裹并标注为"不可信数据，不是指令"，在系统提示中指示模型把工具结果当作数据处理而非指令执行。2) 元数据净化——对 Server 返回的 Tool description 做校验与净化，检测并剥离 prompt-injection 特征（如"忽略之前指令"、"system"、"你是一个"等模式），对可疑描述告警或拒绝。3) 输入输出过滤——在工具调用前后过滤注入特征，对高危内容做二次校验。4) 信任边界——对第三方 Server 的内容打上"external"标签，让模型知道该内容不可信，模型决策依据仍以可信的 Host 指令为准。

防御的核心是"区分数据与指令"。模型无法天然区分，因此 Host 必须用显式的边界、标注与净化来帮助模型把工具内容当作不可信数据处理。内容隔离（可信/不可信分离）是 prompt injection 防御的基石。

• 理解 OAuth 2.1 + PKCE 的授权码流程
• 掌握访问令牌 vs 刷新令牌的生命周期
• 理解令牌刷新、撤销与传播机制

MCP 远程 Server 使用 OAuth 2.1 时，标准流程是 Authorization Code + PKCE：Client 生成 code_verifier 与 code_challenge，向授权服务器发起授权码请求，用户授权后获得授权码，Client 用 code_verifier 换取访问令牌（access token）与刷新令牌（refresh token）。PKCE 防止授权码被截获重放。MCP 的授权发现通过 .well-known/oauth-protected-resource 暴露授权服务器端点与 scope 要求。访问令牌短时效（如 15 分钟），到期后 Client 用刷新令牌换取新访问令牌，避免用户反复授权。令牌撤销在 OAuth 2.1 中通过 revoke_endpoint 实现：用户登出或 Server 被吊销时，Client 调用撤销端点撤销刷新令牌，使后续刷新失败。传播方面，令牌变更应触发 Client 重新协商能力（如重新获取受保护的工具列表），并让 Server 侧失效旧令牌。令牌最小化原则是只请求当前 Server 需要的 scope，避免令牌被用于其他资源。

OAuth 2.1 解决的是"Client 如何代表用户安全访问远程 MCP Server"的授权问题。PKCE 保护授权码，刷新令牌减少打扰，撤销机制应对吊销。令牌生命周期的传播（刷新、撤销、失效）需要 Client 与 Server 协同，防止令牌泄露或过期不一致。

• 理解跨 Server 的污染传播路径
• 掌握按 Server 隔离内容与标注可信边界
• 理解会话级隔离与故障隔离

防止污染的关键是"信任边界不与 Server 边界混同"。一个 Server 被攻陷后，其返回内容可能携带恶意指令，若这些内容被注入到模型上下文并影响后续对可信 Server 的调用，就会横向扩散。因此要在 Host 层按 Server 建立内容隔离与标注：每个 Server 的返回内容都打上明确的来源标签与可信度级别，模型在处理可信 Server 的调用时只依据可信上下文，恶意 Server 的内容即使被注入，也被显式标记为"不可信数据"，不能作为指令或影响其他调用的依据。同时配合运行时隔离（独立进程/容器）、能力级最小化（攻陷 Server 不能越权调用其他 Server 工具）与注入检测，把单点攻陷的爆炸半径限制在单个 Server 内。

信任隔离的核心是"把不可信内容当作数据而非指令"，并让"哪些 Server 可信"成为模型明确感知的边界。多 Server 场景下，隔离既是内容层的（标注可信度），也是运行时层的（进程/容器隔离），两者共同把攻陷的横向影响压缩到最小。

• 理解命令执行沙箱的多个维度
• 掌握路径、网络、环境变量与 syscall 的隔离
• 理解沙箱组合与纵深防御

对执行命令的 MCP Server，沙箱是纵深防御的多个维度叠加：1) 路径限制——Server 只能访问白名单目录（如 Roots 声明的根目录），读写限定在授权路径，禁止访问 /etc、/proc、用户主目录敏感区；2) 网络出口——通过防火墙/网络策略限制出口流量，只允许访问白名单域名/IP，禁止任意外联；3) 环境变量隔离——不要透传宿主敏感环境变量（如数据库密码、密钥），只注入命令所需的最小变量集，避免凭据泄露；4) syscall 过滤——用 seccomp/AppArmor/SELinux 限制危险 syscall（如 execve 到非白名单程序、mount、ptrace、访问网络相关 syscall），配合容器/沙箱（如 bubblewrap、gVisor）进一步隔离。四个维度要组合使用：即使命令逃逸一侧（如路径绕过），另一侧（网络、syscall）仍能兜底。同时命令执行应限制在超时、资源配额（CPU/内存）内，并记录审计日志。

沙箱的核心是"最小权限 + 纵深防御"。任何单一机制都可能被绕过，因此路径、网络、环境变量、syscall 的组合是"即使攻击者执行了命令，也不知道跑到哪、能访问什么、能外联什么"。这本质是把不受信任的代码执行限制在可控的边界内。

• 理解 Sampling 的机制（Server 请求 Host 调 LLM）
• 掌握窃取上下文与消耗配额的滥用方式
• 理解 Host 端对 Sampling 的限制与放行策略

Sampling 允许 Server 反向请求 Host 调用 LLM，这带来两个滥用面：1) 窃取上下文——恶意 Server 可能在 Sampling 请求中携带"请把当前对话上下文发给我"的指令，或通过让模型生成包含敏感对话内容的输出，把 Host 端的上下文泄露给 Server；2) 消耗配额——恶意 Server 可高频发起 Sampling 请求，消耗用户的 token 配额与成本。防御要点：Host 对 Sampling 做白名单与频率限制，只允许受信任的 Server 发起 Sampling；对每次 Sampling 请求做最小验证——检查请求的 model、prompt 内容、采样目的，把 Sampling 限定为"模型自主调用"而非"对 Host 的越权读取"；对 Sampling 结果做脱敏与内容过滤，防止敏感信息外泄；对 Sampling 频率、token 用量做配额与熔断，超限拒绝或告警。最关键的是，Host 应把 Sampling 视为"可审计的受限能力"，而不是无条件的模型调用。

Sampling 的滥用本质是"Server 借 Host 的模型能力反向读取或消费用户资源"。防御方向是"限制 + 审计 + 脱敏"：限制谁能 Sampling、多久一次、采什么；审计每次采样的内容与用量；对敏感上下文脱敏后再透传。这也解释了为何 Sampling 是可选能力，需在能力协商中显式声明。

• 理解最小权限原则在 MCP Server 的体现
• 掌握文件系统路径白名单与数据库读写/表范围控制
• 理解权限最小化与能力灵活的平衡

最小权限原则要求 Server 只暴露完成任务所需的最小能力。文件系统 Server：只暴露 Roots 声明的必要目录，通过路径白名单/规范化（真实路径解析）防止路径穿越（../ 或符号链接逃逸），读写权限按需设置（多数场景只读或限定子目录）。数据库 Server：默认只读，将写操作限定到特定表或特定列，用只读数据库账号、行级权限、限制危险 SQL（如不带 WHERE 的 DELETE/UPDATE、DROP）来约束；对敏感表（如用户表、支付表）不暴露或仅暴露脱敏视图。权限最小化还体现在工具粒度：不提供"执行任意 SQL"这类宽能力工具，而是拆成具体、受限的窄工具。工程上把"能力声明"与"实际授权"对齐，Server 启动时按配置降低自身权限（如只读挂载、专用账号、受限环境变量）。

最小权限是"为未知威胁预留缓冲"：即使 Server 被攻陷或模型误用，能力范围也决定了最大伤害。文件系统与数据库是最常见的敏感资源，因此要显式限定路径、读写与表范围，并用实际校验（真实路径、账号权限）而非仅靠声明。

• 理解 stdio 的进程隔离安全模型
• 掌握 HTTP+SSE 的 TLS/mTLS 安全
• 理解内网与公网部署的差异

stdio 模式中，Server 作为 Host 的子进程运行，通过标准输入输出通信，安全边界是"进程隔离"——Server 与 Host 共享机器，但通过 OS 进程边界、环境变量隔离与文件系统权限约束来限制 Server 的能力。stdio 的信任模型是"本地可信"，不涉及网络，因此没有 TLS 的传输加密需求，但需要防止 Server 越权访问宿主资源。HTTP+SSE（Streamable HTTP）模式中，Server 是远程服务，传输层需 TLS 加密，企业级还可用 mTLS（双向 TLS）做客户端与服务端双向认证，防止未授权 Client 访问。部署差异：企业内网部署通常信任内网环境，可用 TLS 加密 + 内网认证（如 mTLS、内网 OAuth），网络边界由内网防火墙保护；公网部署则必须 TLS + 强认证（OAuth 2.1 + PKCE）、限流、WAF 与审计，且要处理 DNS rebinding、SSRF 等公网威胁。stdio 绝不应直接暴露到公网或反代后，因为那等于把宿主 shell 暴露给攻击者。

传输安全取决于"信任边界在哪"。stdio 的信任边界是本地进程，靠 OS 隔离；HTTP+SSE 的信任边界是网络，靠 TLS/mTLS 与认证。公网部署比内网多一层对抗性威胁，因此安全措施更重。关键原则是"匹配信任边界"：stdio 不暴露公网，远程用 TLS 与认证。

• 理解供应链安全的多个环节（代码、依赖、签名、来源）
• 掌握企业准入流程的设计
• 理解 SBOM、签名与持续审计

引入第三方/社区 MCP Server 前，供应链安全要覆盖多个环节：1) 代码审计——人工或自动化审查 Server 源码，重点看是否有异常网络访问、命令执行、敏感路径读取、硬编码凭据；2) 依赖扫描——用 SCA 工具扫描 Server 的依赖树，识别已知 CVE 漏洞，并生成 SBOM（软件物料清单）记录依赖；3) 签名验证——校验 Server 包/镜像的签名，确认来自可信发布者，防止被篡改或投毒；4) 来源验证——确认 Server 来自可信仓库/发布者，规避 typo-squatting。企业准入流程应把这些环节固化为"准入检查清单"：提交申请 → 代码审计 + 依赖扫描 + 签名验证 → 沙箱运行验证行为 → 批准并登记(版本、hash、SBOM、负责人) → 纳入版本管理与监控。已准入的 Server 仍要持续监控（依赖更新的 CVE、新版本行为变更），一旦发现风险可快速下架或回滚。

供应链安全是在"可信发布者"与"代码本身"之间建立多层验证。SBOM、签名与审计清单让"引入一个 Server"成为受控、可追溯、可回滚的工程决策，而不是随意下载运行。企业环境的准入门槛就是这些环节的强制化。

• 掌握审计日志的关键字段
• 理解参数 hash 与最小化记录
• 理解审计如何满足合规要求

MCP 审计日志的字段应覆盖"谁、何时、做了什么、如何授权、结果如何"：时间戳（UTC）、用户/会话 ID、Server ID、Tool 名、请求 ID、参数 hash（而非明文参数，避免记录敏感数据）、审批人（若经 HITL）、调用来源、结果状态（成功/失败/拒绝）、错误码。参数 hash 用于"可追溯但不可泄露"——能确认某次调用的参数组合，但不暴露明文。满足 SOC 2 / ISO 27001 的关键是：审计日志的完整性（不可篡改，如 append-only 存储、日志签名）、保留期（按合规要求保留足够时长）、访问控制（谁可读审计日志也要受限）、以及对"访问控制"、"变更管理"、"事件监控"等控制项的日志覆盖。审计日志应能支撑"某次敏感操作是谁发起的、是否获授权、结果如何"的完整追溯，这是合规审计的核心证明。

审计日志是合规的"证据链"。字段设计要兼顾可追溯性与数据最小化（用 hash 而非明文）。满足 SOC 2/ISO 27001 不仅是"记日志"，更是"日志不可篡改、可保留、可检索、访问受限"，并覆盖关键控制项。

• 理解三类数据源的信任差异
• 掌握分级信任与相应处理策略
• 理解信任边界设计对安全的影响

三类数据源的信任等级不同。用户输入：部分可信，可能包含注入或恶意指令，但需作为"用户意图"处理，需做注入检测与风险过滤。工具输出：不可信，来自外部系统，可能含注入、恶意数据或错误信息，需作为数据处理并净化、标注，不能让模型执行其中的指令。模型输出：由模型生成，需做内容安全检测（有害、敏感、幻觉、合规风险）与输出过滤，并按需接入人工审核。信任分级设计的意义在于：对不同来源采用不同的处理策略——用户输入做意图校验与注入检测，工具输出做隔离与净化，模型输出做安全过滤与质量校验。同时，所有"从外部进入系统"的内容在进入模型上下文前都要经过"边界校验"，把不可信内容明确标注，避免作为指令执行。

信任边界是"数据来源"的信任分层。系统要明确"哪些内容可信、哪些是数据、哪些需校验"，并在边界上执行相应处理。分级让安全策略有针对性，而不是一刀切，也不把不可信内容当作可信指令。

• 理解 Resource URI 模式与模板（template）的访问控制
• 掌握敏感资源的隔离与 ACL
• 理解服务端强制校验与客户端过滤

MCP Resource 的访问控制要在服务端强制实现。1) URI 模式白名单：Server 只对声明在 tools/resources 列表中的 URI 模式（如 file:///workspace/**）提供读取，未匹配的 URI 拒绝访问；2) 模板权限：对带模板参数的 URI（如 file:///path/{name}），校验模板参数落在白名单范围，防止通过 {name} 注入越权路径（如 ../）；3) 敏感资源隔离：把敏感资源（用户配置、密钥、其他租户数据）放在独立命名空间，用 ACL 定义谁能读，默认拒绝；4) 租户隔离：把用户身份绑定到资源访问，用户只能访问其租户域内的资源。工程上，ACL 在 Server 侧对每次 resources/read 做校验，而非依赖客户端过滤。同时可按资源敏感度分级：公开资源可读，敏感资源需授权或脱敏返回。还要处理 URI 规范化（真实路径解析）防止路径穿越。

Resource 访问控制的关键是"服务端强制校验"，因为客户端过滤可被绕过。URI 模式白名单 + 模板参数校验 + 敏感资源 ACL 三层，共同约束"谁能读什么 URI"。租户隔离确保跨租户数据屏障。

• 理解 Elicitation 的机制与滥用风险
• 掌握频率限制与内容白名单
• 理解敏感信息屏蔽与用户控制

Elicitation 允许 Server 向用户请求额外信息，恶意 Server 可能通过不断索要信息进行社工攻击（如反复询问密码、验证码、家庭住址），或通过诱导用户透露敏感信息。Host 端防御：1) 频率限制——限制每会话/每时间的 Elicitation 次数，超限拒绝或要求用户显式确认；2) 内容白名单——对可请求的信息类型做白名单（如"请提供订单号"），对敏感字段（密码、OTP、身份证号）做屏蔽或强制人工确认；3) 最小披露——展示 Elicitation 请求时明确标注"来自哪个 Server、为何需要、用于什么"，让用户知情；4) 用户控制——用户可拒绝、忽略或标记"不要重复询问"，Host 尊重用户选择并在后续抑制同类请求。Elicitation 结果应脱敏记录，且不能作为可信输入直接进 system prompt。

Elicitation 的滥用本质是"通过持续的、设计好的提问诱导用户泄露信息"。防御方向是"降频 + 白名单 + 透明 + 用户控制"，把 Server 的提问能力限制在可控、可审计范围内，防止利用人性弱点做社工。

• 理解检索层的数据访问控制
• 掌握租户隔离与行级权限
• 理解缓存命中的权限校验

检索层的数据访问控制要防的是"越权读到他人数据"。1) 租户隔离：检索请求必须携带租户上下文，所有查询都限定在租户域内，防止跨租户访问；数据存储按租户分区或用租户 ID 作为强制过滤条件。2) 行级权限：在查询层注入行级安全过滤（如 WHERE owner_id = current_user），即使模型构造了宽泛查询，也只会返回授权行。3) 缓存命中校验：缓存的 key 必须包含租户/用户维度，且命中缓存前校验当前用户对缓存数据的权限，防止用户 A 命中用户 B 的缓存结果。4) 检索后过滤：对返回结果做二次权限校验与脱敏（如敏感字段在展示前脱敏）。工程上，权限过滤应在数据访问层（ORM/查询层）强制注入，而非依赖应用层拼参数，避免漏加。

数据访问控制的核心是"权限在数据查询的每一层都强制存在"。租户隔离管"跨租户"，行级权限管"跨用户"，缓存校验管"缓存共享不越权"。权限过滤应在检索/查询层强制注入，保证"即使模型乱查，也查不到越权数据"。

• 理解生成后输出安全处理
• 掌握敏感信息脱敏、合规过滤与品牌口径改写
• 理解过滤与改写的顺序与兜底

输出内容安全在模型生成后、返回用户前执行过滤与改写。1) 敏感信息检测——用 PII 识别（正则、实体识别、LLM 分类）检测模型输出中的身份证号、手机号、密钥等，按规则脱敏或拦截；2) 合规过滤——检测输出是否含政治敏感、违法、有害、歧视性内容，命中则拦截、替换或标记；3) 品牌口径——用品牌/口径规则或意图改写，确保输出符合品牌语气与话术，避免不当表述。执行顺序建议：先做安全检测（拦截高危），再做合规过滤，再做品牌口径改写，最后做质量校验（如是否符合指令）。对高风险输出要人工兜底。过滤与改写应保留审计（哪些输出被拦截/改写），且改写逻辑要可配置、可回滚，避免误伤正常输出。

输出安全是"生成后的最后一道闸门"。模型可能生成合规内容，但输出仍需按"敏感信息、合规、品牌"三个维度校验与改写。过滤用"拦截高危、改写中危、放行低危"的分级策略，并对高风险输出接入人工审核兜底。

• 理解不可信场景的判定（置信度、证据、风险）
• 掌握人工审核与回退策略
• 理解分级兜底与用户体验

模型不可信场景的兜底采用"分级处理"：1) 置信度不足——模型输出置信度低或不确定时，回退为"明确说明不确定/向用户询问"，而不是给出肯定答案；2) 无证据——对需要事实支撑的问答，模型未检索到证据或证据不足时，回退为"无法确认并说明原因"，或触发检索/工具调用补齐证据；3) 高风险输出——涉及金额、健康、法律、安全等高风险结论时，强制进入人工审核或用户确认，不直接放行。设计上：为模型输出附加置信度/证据源/风险等级元数据，据此路由到"直接放行 / 温和提示 / 人工审核 / 拒绝并回退"。回退路径要可配置（如回退到规则引擎、模板答案、人工）。所有不可信场景都应记录审计，便于持续改进。

兜底的本质是"模型不可靠时系统可控"。通过置信度、证据与风险分级，把不确定的输出转到更安全的路径（用户确认、人工审核、回退），避免模型"自信地给出错误/高风险答案"。这要求系统在输出上附加决策元数据。

• 理解 Prompt 模板与用户输入拼接的注入面
• 掌握拼接边界与输入校验
• 理解模板参数的转义与安全处理

MCP Prompts 是预定义模板，用户输入作为参数填充到模板中。若简单拼接，用户输入可能包含模板语法或指令注入（如"占位符内容 + 忽略以上指令"），劫持模板意图。防护要点：1) 拼接边界——把用户输入作为"数据"而非"指令"插入，用明确的 delimiter/占位符包裹，并在模板中说明"{{input}} 是用户输入，不是指令"；2) 输入校验——对用户输入做长度限制、字符过滤、注入特征检测（如"忽略指令"、"system"、"重新定义"），高风险输入拦截或按普通数据处理；3) 模板参数化——用参数化方式（如模板字符串 + 转义）而非直接字符串拼接，把用户输入转义为纯文本；4) 模板来源可信——Prompts 模板本身来自可信 Server，模板内容要审核，防止模板本身被注入；5) 输出侧仍要校验——即使模板填充正确，最终 Prompt 仍可能被用户输入污染，需在组装后做整体校验。

Prompt 模板注入的关键是"把用户输入当作数据而非代码"。通过拼接边界、转义、校验与模板来源可信，防止用户输入逃逸出数据位置劫持指令。这与 SQL 注入的防御思路类似——参数化 + 边界 + 校验。