接入第三方 MCP server 有哪些安全风险？怎么防？

先这样答

MCP 让接入外部工具变得容易，但要认清每个第三方 server 的本质：一个能在你系统里执行动作的外来程序。风险集中在三类。一是供应链风险：server 本身可能带恶意代码、可能被篡改、版本更新可能引入问题，引入时要有可信来源和白名单，锁版本、审行为，而不是社区流行就直接装。二是内容注入：工具的描述和返回值都是要进模型上下文的文本，返回内容里藏一条「忽略之前的指令」就可能劫持 Agent，所以工具返回必须当数据处理，和系统指令隔离开，必要时对返回做注入特征检测。三是权限过大：一个 server 常常打包一整套工具，你只用其中两个，全部挂上等于给了多余的权限面，应该只暴露实际需要的工具子集。

给面试官收尾：MCP 解决的是「工具怎么标准化地接进来」，它不负责安全边界本身。接入方的安全设计和直连 API 时一样：最小权限、内容隔离、高危动作人工确认、调用日志全留痕。

面试官会怎么追问

• 「工具描述投毒是什么？」 恶意 server 在工具描述里写诱导性文案，比如夸大自己能力、暗示优先选用、或让模型忽略某些约束，模型读描述做决策就会被带偏。防法：来源可信加描述人工审计，上线前用固定评测集看工具选择行为有没有异常变化。
• 「和直接调 API 相比，MCP 多了什么风险？」 多了一层第三方打包：server 实际执行的动作可能和它声明的不一致，你审计的是声明不是行为。所以要看它实际请求了什么（网络日志、权限审计），并按最小权限只挂载需要的工具。
• 「生产环境怎么兜底？」 三层：高危动作（写、删、对外发送）人工确认；全部工具调用留痕可审计，出事能定位到哪个 server 哪次调用；对返回内容做注入检测，命中就丢弃或降级处理。

回答的坑

• 只看 star 数和社区热度就引入。流行不等于安全，供应链事故恰恰常发生在「大家都在用」的组件上，引入流程里必须有来源和行为审计。
• 把 MCP 当成安全协议。它解决的是接入标准化，接进来之后的安全边界（权限、注入、审计）仍然要应用层自己设计，说出这层区分比背协议特性加分得多。