https://owasp.org/www-project-mcp-top-10/

1. 令牌管理不当与密钥暴露

OWASP 指出，在 MCP 系统里，token 和各类凭证是模型、工具、服务之间完成认证与授权的核心载体。但开发者很容易把这些 secret 放进配置文件、环境变量、prompt 模板，甚至让它们残留在模型上下文记忆和日志里。由于 MCP 系统常常是长会话、带状态、上下文持久化的，这些凭证可能在后续交互中被召回、被日志检索到，或者被攻击者通过提示注入方式套出来。

这类风险真正可怕的地方在于，泄露的往往不是一个“只读字符串”，而是能直接调用仓库、流水线、云 API、文件系统的执行令牌。一旦泄露，后果常常不是单点信息暴露，而是整个已连接环境被接管。OWASP 给出的防护重点也很清楚：短期 token、最小权限、按会话绑定、避免把 secret 存进上下文和日志，以及统一的凭证生命周期治理。

2. 权限范围蔓延导致提权

OWASP 把它描述为一种“慢性风险”：最初只是临时放开的权限，后来因为方便、历史兼容或配置漂移，一点点扩大，最后让 agent 拿到了远超任务本身的能力。尤其 MCP 往往会同时连接代码仓、云 API、工单系统、CI/CD，这种小幅度的权限膨胀会快速把一个低风险自动化能力变成高风险入口。

这类问题在 agent 场景里会被进一步放大。因为传统系统里，权限大不一定马上出事；但在 MCP 场景里，一个过权的 agent 会自动行动，它可能在没有人工复核的情况下改代码、发起部署、读取敏感数据，甚至创建新的凭证和身份资源。OWASP 建议这里必须坚持最小权限、自动 scope 过期和严格访问评审。

3. 工具投毒

这是很有 MCP 特征的一类风险。OWASP 这里强调的不是普通意义上的恶意插件，而是 schema、manifest、tool descriptor 以及工具输出本身被篡改，从而让模型在“表面合法”的情况下做错事。最典型的情况就是：一个看起来无害的操作名，实际却被映射到高风险甚至破坏性动作上。攻击者不是直接打代码漏洞，而是改写 agent 和工具之间的“契约”。

这类风险难防，是因为日志里看到的可能仍然是“合法调用”。表面上 agent 是按照 schema 在行动，但 schema 本身已经被污染了。OWASP 提出的重点缓解方向包括：对 schema 和 manifest 做签名校验、把 registry 做成不可变和可追溯、对 schema 变更实施多人审批，并把“archive 不能偷偷映射为 DELETE”这类语义约束写成 policy。

4. 软件供应链攻击与依赖篡改

OWASP 指出，MCP 环境高度依赖第三方组件，包括 SDK、连接器、协议服务、向量库客户端、插件和模型侧工具集成。这些组件通常运行在受信执行路径里，一旦依赖被污染，攻击者就能悄悄改变 agent 行为、插入后门、修改协议语义，甚至进一步影响下游工作流。

相比传统供应链攻击，MCP 场景的问题更重，因为被污染的不只是一个程序模块，而是“模型如何理解世界、如何操作外部系统”的整个能力边界。OWASP 推荐的做法包括：组件签名、来源校验、SBOM/CBOM 可见性、版本固定、内部镜像仓库、依赖扫描，以及对第三方插件实施隔离运行。

5. 命令注入与执行

OWASP 将其定义为：AI agent 使用不可信输入去构造并执行系统命令、shell 脚本、API 调用或代码片段，而这些输入没有经过充分校验和净化。这里的不可信输入，不只来自用户 prompt，也可能来自检索上下文、第三方数据源，甚至工具返回结果。

这类问题比传统命令注入更隐蔽，因为中间多了一层模型解释。攻击者不一定直接传入恶意命令，而是把诱导内容藏在文档、上下文或 prompt 里，让模型“主动”生成看起来语法正确、语义也似乎合理的执行命令。OWASP 特别提到，工具一旦封装了 shell、数据库操作或文件系统访问，而又直接把 agent 输出交给解释器执行，就会形成典型注入入口。

6. 意图流劫持

OWASP 用了一个很形象的说法：Intent Flow，也就是 agent 把用户的高层目标翻译成一系列工具调用和执行动作的关键路径。MCP 环境里，agent 会读取资源文档、schema 定义和工具输出作为上下文来制定计划；如果这些被取回的上下文里埋有恶意指令，agent 就可能在流程内部被带偏，从用户原本的目标转向攻击者想要的目标，而且表面上仍像是在完成原任务。

这类风险比直接 prompt injection 更麻烦，因为它不是用户明着“骗模型”，而是攻击者把指令藏进被模型信任的上下文里。你让 agent 总结日志，它却被日志里的隐藏指令诱导去外传日志；你让它查看仓库状态，它却被仓库文本里的恶意内容带去执行额外动作。OWASP 给出的关键思路是：锚定用户原始目标、把外部取回的自然语言上下文统一视为不可信、检测执行动作是否偏离原目标，并在高风险偏移时强制人工确认。

7. 认证与授权不足

OWASP 对它的定义很直接：当 MCP server、工具或 agent 在交互过程中没有正确验证身份，或者没有严肃执行访问控制时，就会暴露出关键攻击路径。典型表现包括：API key 校验可选、共享静态密钥、配置文件里硬编码凭证、token 没有过期机制、仅依赖客户端声明调用者身份，以及工具端不按用户或 agent 校验权限范围。

这类问题在 MCP 里会被放大，因为参与方往往不是单一用户和单一服务，而是多个 agent、多个工具和多个系统协同。只要身份绑定不严，就会出现“谁在以谁的名义做事”这件事彻底失真。最终结果就是未授权访问、权限升级和敏感数据泄露。OWASP 的方向很明确：更强的身份验证、短期且 scoped 的凭证、服务端强校验，而不是只靠前端或客户端自觉。

8. 审计与遥测缺失

OWASP 强调，MCP 系统经常会自动执行复杂工作流，包括取数、调工具和做决策。如果缺乏审计日志和遥测能力，组织就会失去可见性：不知道 agent 做了什么、访问了什么数据、为什么做出某个决定。没有全面日志，不仅会削弱事件响应和取证能力，也会让内部滥用、模型异常和合规问题长期处于盲区。

这类风险的可怕之处在于“静默性”。一个没有被监控的 agent，完全可能连续数周执行敏感操作或外传数据而不被发现。OWASP 明确建议，要记录工具调用、上下文变化、用户与 agent 的交互，并形成不可篡改的审计链。这其实是在告诉大家：MCP 安全不只是拦截能力，还包括“出事后能不能把链路讲清楚”。

9. 影子 MCP 服务器

OWASP 把它类比为 Shadow IT：未经批准、未经监管的 MCP 实例，被开发、研究或数据团队为了测试和便利临时搭起来，常常带着默认凭证、宽松配置或未加固 API，运行在组织正式治理体系之外。

这类影子部署的危险，在于它们往往直接暴露数据检索、工具执行甚至模型控制能力，却绕开了集中认证、监控和数据治理。它们会把企业环境里最敏感的能力，变成安全团队看不见的后门。OWASP 明确指出，这些未纳管的 MCP 节点会扩大攻击面，也会造成明显的合规风险。对企业来说，这类问题的第一步甚至不是“防攻击”，而是“先把所有活跃的 MCP 实例找出来”。

10. 上下文注入与过度共享

OWASP 把 context 定义为 agent 的工作记忆，里面会存放 prompt、检索文档、中间结果和交互历史。如果这些上下文被共享、被持久化、或者作用域划分得不够严格，那么一个用户、一个会话或一个 agent 的敏感信息，就可能泄露给另一个。与此同时，恶意内容一旦被写入这段共享记忆，又会持续影响后续任务，这就是所谓的 Context Injection。

这类风险在多租户、多部门和多工作流系统里尤其危险。OWASP 直接拿 Slack 机器人泄露私密频道、会议总结机器人暴露敏感对话、SaaS 多租户 session bleed 这类场景做类比。到了 MCP 场景，因为上下文是持久化的、会被复用的、还会继续反过来影响模型行为，所以风险会更快、更隐蔽地扩散。OWASP 给出的核心方向是：严格做 namespace 隔离、限制上下文生命周期、避免跨任务复用，并对进入上下文的数据做分类、脱敏和访问审计。

它和 Skill Top 10 有什么不同？

如果说 Skill Top 10 关注的是“装进 Agent 里的能力包本身有没有问题”，那 MCP Top 10 关注的就是“模型通过协议连接外部工具和上下文时，会不会在调用链上失控”。

前者更偏 skill 的打包、分发、权限声明、加载、隔离和治理；后者更偏 token、身份、工具契约、上下文、执行链路和运行时审计。简单说，Skill Top 10 管的是能力包本身，MCP Top 10 管的是能力包被调用、被连接、被执行时的风险。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。