核心要点
攻击面已从代码扩展到信任链：AI Agent 供应链攻击不只发生在代码逻辑里，更发生在"信任关系的传递"上——你信任了模型 Hub、信任了第三方工具、信任了分享功能，就把风险一并接了进来。
三类典型攻击面：模型分发渠道投毒（Hugging Face 事件，poolId 3）、工具/MCP 来源不可信与描述污染、对话数据信任边界泄露（Claude 共享对话，poolId 2）。
防御核心是信任链管理：来源可核验、信任动态评估、不可信组件隔离、数据分级与边界治理，而非单纯的代码扫描。
运行时持续评估：组件今天可信不代表明天被接管后仍可信，信任必须是运行时动态评分而非一次性"已审核"标签。
简要回答
AI Agent 供应链攻击的本质是"信任链失守"，防御要围绕三个攻击面系统设防：（1）模型供应链——从 Hub 拉取权重时校验发布方身份、权重哈希、模型卡片完整性，把模型当 npm 依赖一样治理（对应 OpenAI/Hugging Face 事件）；（2）工具/MCP 供应链——建立可信工具注册表、对工具描述做完整性校验防止"描述投毒"、参数级策略拦截；（3）数据信任边界——禁止凭证/源码进入可分享对话、组织级默认关闭分享（对应 Claude 共享泄露）。贯穿三者的原则是：信任必须来源可核验、运行时动态评估、不可信组件沙箱隔离。
标准回答
一、重新定义攻击面
传统软件供应链攻击污染的是代码依赖（如 npm 包）。AI Agent 把攻击面扩张到三个新环节：模型分发渠道、工具/MCP 生态、数据与对话信任边界。共同特征是——攻击不发生在"代码逻辑"里，而发生在"我因为信任某个上游，于是把风险接了进来"。所以防御的第一性原理是信任链管理，不是代码扫描。
二、攻击面一：模型分发渠道（对应 OpenAI/Hugging Face 事件，poolId 3）
Hugging Face 是 AI 时代的"npm 仓库"。风险包括：来源伪造、权重投毒、恶意模型卡片/配置、依赖混淆。防御：①来源核验——校验发布方身份与权重哈希；②模型卡片与配置完整性校验；③入库安全审查 + 运行时行为监控；④把模型纳入与代码依赖同级的 SBOM（软件物料清单）管理。
三、攻击面二：工具/MCP 供应链
当 Agent 通过 MCP 连接成百上千第三方工具，工具来源真实性、描述合法性、调用可追溯性都成问题。风险：工具来源不可信、工具描述投毒（篡改自然语言描述诱导 Agent 误用）、权限聚合。防御：①可信工具注册表白名单；②工具 schema/description 完整性校验；③参数级策略拦截（允许查询但禁 DROP）；④调用速率与预算熔断；⑤全量调用审计。
四、攻击面三：数据信任边界（对应 Claude 共享泄露，poolId 2）
"分享对话"功能让本应私密的内容越过信任边界被第三方索引。防御：①对话数据分级——明确禁止凭证/密钥/核心源码进入可分享对话；②组织级默认关闭分享，需显式审批；③敏感内容检测——对将要分享的内容做敏感信息扫描。
五、贯穿性原则：动态信任 + 隔离
供应链信任最大的误区是"入库审查通过 = 永久可信"。组件会被接管、依赖会被投毒，信任必须是运行时持续评估的动态评分。对新接入或低风险组件用沙箱隔离执行、限制网络与权限、观察后逐步放权。检测到组件行为突变（异常权限请求、异常数据访问）即降低信任评分并告警。
六、事件响应
预设响应剧本（隔离→取证→回滚→通知），依赖委托链记录与全量审计日志做取证，检测到确认入侵时自动吊销凭证、冻结可疑工具。复盘驱动策略演进。
常见误区
⚠️ 常见踩坑
误区一：供应链安全 = 扫依赖漏洞。AI Agent 的主要供应链风险在模型分发、工具生态、数据信任边界，传统 SCA 扫描覆盖不到这些。误区二：入库审查通过 = 永久可信。组件会被接管、依赖会被投毒，信任必须是运行时动态评分。误区三：只防模型不防工具和数据。模型安全固然重要，但工具调用链投毒和对话数据泄露往往是更现实的攻击路径。误区四：把"分享"当无害功能。分享对话实质是数据外泄通道，需要数据分级和审批治理。
追问
追问 1：模型权重投毒为什么比传统依赖投毒更难发现？如何检测？
追问 2：MCP 工具描述投毒是什么？怎么防？
工具描述投毒指攻击者篡改 MCP 工具的自然语言描述（schema/description），诱导 Agent 误用工具——比如把一个看似无害的工具描述成能处理敏感操作，或在描述里嵌入 Prompt Injection 指令。防御：①完整性校验——对工具 schema/description 做签名或哈希校验，运行时验证未被篡改；②白名单注册表——只允许调用经审查入库的可信工具，不允许 Agent 动态发现并信任任意 MCP Server；③描述审查——入库前对工具描述做安全审查，检测可疑的指令性语言；④参数级策略——即使工具被误调用，参数策略仍能拦截越权操作。本质是把工具当"出站请求"治理。
追问 3：如果企业已经大量使用对话分享功能，如何补救？
分三步补救：①先止血——组织级临时关闭或收紧分享权限，对历史已分享对话做敏感信息扫描（凭证、密钥、源码、内部架构），发现泄露立即轮换相关凭证；②建治理——制定对话数据分级规则，明确哪些内容绝不允许进入可分享对话，分享改为默认关闭 + 显式审批；③技术兜底——在分享出口部署敏感内容检测（DLP），对将要分享的内容自动扫描并拦截敏感信息，同时保留分享审计日志支撑事后追溯。关键是先切断正在发生的泄露，再建长效机制。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习