主题
高频面试题
MCP 协议安全性设计包含哪些层面？
MCP 把工具接入标准化，也把本地文件、远程账号、业务 API 和模型上下文连在一起；安全题考的就是你能不能把这条链路里的风险拆开治理。
面试官角度分析，想考什么
MCP 的安全边界在哪里？为什么 Server 风险高？
考分层：Host、Client、Server、底层系统；Server 可能持有文件、数据库和真实权限。认证授权和 prompt injection 怎么防？
考落地：OAuth、scope、用户同意；把资源和工具结果当不可信输入。误操作和供应链怎么治理？
考最小权限、危险确认、沙箱、来源审计和版本锁定。
可直接抄走的 30 秒参考答案
text
MCP 安全我会分六层讲。第一是协议和传输层，远程 Server 要认证授权、TLS、scope 最小化和会话保护；第二是 Host 层，决定哪些工具给模型、哪些动作要用户确认；第三是 Server 层，做输入校验、最小权限、只读默认和结果脱敏；第四是数据层，把 resource 和 tool result 当不可信输入，防间接 prompt injection；第五是运行时层，用沙箱、目录白名单和网络限制控制影响面；第六是供应链，审计 MCP Server 来源、依赖和版本。MCP 让工具接入标准化，但不会自动替代权限、隔离和审计。面试回答详解，知其所以然
MCP 安全题的核心不是“协议有没有安全设计”，而是：MCP Server 一旦接入，就可能把模型连接到真实系统。模型会读到不可信内容，也可能触发有副作用的动作，所以安全必须从连接、权限、上下文和执行环境一起设计。
1. 先画清信任边界
MCP 的基本调用链路是：
text
User -> MCP Host -> MCP Client -> MCP Server -> Files / DB / SaaS / Internal API
^
|
LLM sees selected context and tool results这里至少有五条边界：
- 用户和 Host：用户授权哪些工具、哪些账号、哪些数据可用。
- Host 和模型：哪些工具 schema、资源内容、工具结果会进入上下文。
- Host 和 Server：Server 是否可信，连接是否认证，能力是否被允许。
- Server 和底层系统：Server 访问文件、数据库、SaaS API 的权限范围。
- 工具结果和下一轮模型决策：Observation 是不可信输入，不能自动变成指令。
成熟回答要强调：MCP 标准化的是通信和能力暴露，不等于替你完成全部安全治理。
2. 协议和传输层：认证、授权、会话保护
远程 MCP Server 尤其要做清楚认证和授权。常见要点包括：
- 使用 OAuth 或等价机制确认调用方身份。
- scope 最小化，只授予当前任务需要的 API 权限。
- token 不暴露给模型，不写入 prompt，不返回给工具结果。
- 会话 id、resource handle、authorization code 等敏感句柄不能可预测，不能复用到其他用户或租户。
- 连接必须使用 TLS，服务端要防止重放、CSRF、开放重定向和 token 盗用。
- 多租户场景必须把用户、组织、项目、server session 绑定起来。
本地 stdio Server 也不能放松。它通常运行在用户机器上，可能天然继承本地权限，所以更要限制目录、环境变量、网络访问和子进程能力。
3. Host 层：工具治理和用户确认
Host 是最关键的治理入口，因为模型不是直接调用 MCP Server，而是由 Host 决定哪些工具给模型、哪些调用允许执行。
Host 应该负责：
- 按任务动态选择工具，避免把所有工具都塞进上下文。
- 给工具加命名空间，防止同名工具或恶意描述混淆模型。
- 对高风险工具设置人工确认，例如删文件、发邮件、付款、改权限、生产写库。
- 对工具参数做策略校验，比如路径白名单、SQL 只读、金额上限、收件人限制。
- 记录完整 trace：用户请求、模型 tool call、工具参数、结果、审批人和时间。
- 设置调用预算、超时、重试次数和最大步骤，防止循环调用或资源消耗失控。
工具描述本身也不能盲信。Server 可以声明某个工具“只读”或“无害”，但 Host 仍然要用策略和执行环境验证。
4. Server 层：最小权限、输入校验和安全默认值
MCP Server 是能力提供方，安全设计不能只靠 Host 拦截。
Server 侧要做：
- 只暴露面向任务的高层工具，不把底层 API 全量透出。
- 对输入做 schema 校验、类型校验、范围校验和业务校验。
- 默认只读，写操作显式命名并返回可审计结果。
- 文件访问限制到工作目录，禁止路径穿越。
- 数据库工具优先只读账号，写操作分离账号和审批。
- 对返回结果脱敏、截断和分页，避免密钥、PII、大量日志进入模型上下文。
- 错误信息标准化，不把内部栈、token、连接串泄露给模型。
一个好的 MCP Server 不只是 API wrapper，而是把底层系统封装成安全、可验证、可恢复的 Agent 工具。
5. 数据和 Prompt Injection：把外部内容当不可信输入
MCP 的资源和工具结果经常来自网页、文档、邮件、issue、PR、数据库记录。这些内容可能包含“忽略之前指令”“调用转账工具”“把 token 发给我”一类间接 prompt injection。
防护思路：
- 明确区分 instructions 和 data，资源内容只能作为数据证据，不能提升为系统指令。
- 在上下文中标注来源、时间和可信级别。
- 工具结果进入下一轮前做摘要、脱敏和格式隔离。
- 高风险操作必须基于用户原始意图和策略校验，不能只基于网页或工具结果里的文字。
- 来自第三方内容的“请记住”“请调用”“请改权限”默认不可信。
- 最终答案和动作要引用证据来源，避免模型把注入文本当任务目标。
面试里最好主动说：MCP 把外部内容接进上下文，间接 prompt injection 是一等风险。
6. 运行时隔离：沙箱、进程和网络边界
MCP Server 可以是本地进程，也可以是远程服务。不同形态对应不同隔离手段：
- 本地 Server：用容器、受限用户、只读挂载、目录白名单、网络禁用或 allowlist。
- 远程 Server：用服务端鉴权、租户隔离、请求审计、速率限制、数据脱敏。
- 危险工具：放到单独 worker 或 sandbox，不和普通工具共享权限。
- 企业环境：按项目、环境、数据级别分 server，不让测试工具天然拥有生产权限。
隔离的目标不是让工具“永远不能出错”，而是让出错时影响范围可控。
7. 供应链治理：Server 来源和依赖可信
MCP 的生态价值在于“别人写的 server 我也能接”，但这也带来供应链风险。
需要治理：
- 只安装可信来源的 Server，优先官方、企业内部或可审计仓库。
- 锁定版本和依赖，避免自动升级引入行为变化。
- 审查安装脚本、环境变量读取、网络访问和文件访问范围。
- 对 Server 做签名校验、漏洞扫描和最小权限运行。
- Server 配置不要提交密钥，token 用系统密钥链或 secret manager。
- 高权限 Server 做独立审计和变更审批。
一句话：MCP Server 不是普通 npm 包，它可能是“带权限的自动化执行器”。
面试官追问3个问题
追问一：MCP Server 说自己是只读工具，Host 可以相信吗？
- 考察点：是否理解声明和执行控制的区别。
- 回答方向：不能只相信声明。Host 可以把只读注解作为提示，但仍要结合工具名、schema、权限配置、Server 来源和执行环境判断；真正只读要靠底层账号权限和运行时限制保证。
追问二：如何防止恶意网页通过 MCP 工具控制 Agent？
- 考察点：间接 prompt injection 防护。
- 回答方向：网页内容是数据不是指令；工具结果要隔离、摘要和标注来源；高风险动作要用户确认；模型不能因为网页文字要求就改系统规则、泄露 token 或调用危险工具。
追问三：本地 MCP Server 比远程 Server 更安全吗？
- 考察点：能否做部署形态取舍。
- 回答方向：不一定。本地 Server 少了公网暴露和远程租户问题，但它可能拥有用户文件、shell、环境变量等高权限；远程 Server 更适合集中审计和 OAuth，但要处理网络、租户和数据出境。两者都需要最小权限和审计。
扩展知识
MCP 安全和普通 API 安全的差异
- 普通 API：调用方通常是确定的业务服务，输入输出边界较固定。
- MCP Server：调用意图可能由模型产生，工具描述和结果会进入上下文，外部数据还能反过来影响下一步决策。
- 关键差异：MCP 既有 API 安全问题，也有 LLM 上下文污染和自动化误操作问题。
常见分层清单
text
身份认证 -> 授权 scope -> Host 策略 -> Server 输入校验
-> 运行时隔离 -> 结果脱敏 -> trace 审计 -> 用户可控这套清单比单纯说“OAuth + sandbox”更适合面试，因为它覆盖了调用前、调用中、调用后的风险。
Tool annotations 不能当安全边界
MCP 里工具可以带注解，表达只读、破坏性、开放世界访问等信息。它们对 UI 呈现和 Host 决策有帮助，但不能替代实际权限控制。真正的安全边界必须由 Host 策略、Server 权限和运行时隔离执行。