面试题库

7 天 MCP：把工具接进任何 Agent

D6 安全与治理：工具描述里的提示注入、混淆代理、最小权限、审计日志与工具白名单

• 为什么说 MCP 工具的描述是不可信输入？作为客户端作者，你会做哪些防护？Why is an MCP tool's description untrusted input, and what protections would you build as a client author?

  国内高频海外高频进阶#prompt-injection#client

  分析过程 · 先想清楚再作答

  1. 这题在筛「有没有把模型上下文当成一条数据入口来看」。答「加个过滤器拦关键词」会被追问到崩，因为基于文本的过滤挡不住改写。
  2. 先讲清为什么不可信。工具描述由服务端作者写，会原封不动进入给模型的工具表，和你自己写的系统提示处在同一个信任层级——没有引号、没有边界、没有来源标注。它的前置条件低到离谱：攻击者不需要凭证、不需要中间人、不需要用户点任何东西，只要能影响一段会被读进上下文的文本。三条现实路径是发一个服务端等人装、拿下已被信任服务端的发布权限在小版本里改一个字段、或者服务端本身干净但描述里嵌了从数据库读出来的内容。第二条最难防，因为用户只在安装时审过一遍，清单变更通知只说变了、不说哪句话变了。
  3. 顺手把注解也归进来：规范要求客户端必须把工具注解当成不可信输入，除非来自可信服务端。readOnlyHint 为真不是安全证明，只是服务端的自我声明。
  4. 然后是防护，关键是**给出顺序**：先挡后果，再挡入口。因为所有基于文本的防御都是概率性的，没有一条能保证挡住，而后果那一层是确定性的。
  5. 挡后果的三条：破坏性工具执行前一律向人确认，且确认框展示**实际参数**（规范建议把工具输入展示给用户，正是为了挡住工具名人畜无害但参数在外发数据这一类）；界面上必须显示每一次工具调用，否则注入里那句「不要告诉用户」是真的会生效的；判据用本地策略为主、注解为辅——注解只能用来多拦一个，不能用来放行。
  6. 挡入口的三条：把描述当外部数据渲染，加来源标注与边界标记，并把边界符本身转义掉；工具返回同样处理，还要加长度上限；服务端清单变更时把描述的 diff 展示给用户复核，而不是只提示「工具列表变了」。
  7. 可预期的追问一：那能不能干脆让模型别听描述里的指令？只能降低概率，不能保证，所以它不能是唯一防线。追问二：工具返回算不算同一类问题？算，而且更严重，因为它每次都不一样、量更大；多服务端场景里官方还专门说过，一个服务端的结果对另一个服务端来说是不可信输入。

  How to reason about it · think before answering

  1. The screen is whether you treat the model's context as a data ingress. Answering 'filter for keywords' collapses under follow-up, because text filters do not survive paraphrase.
  2. Establish why it is untrusted. The description is written by the server author and lands verbatim in the tool list handed to the model, at the same trust level as your own system prompt, with no quoting, boundary, or provenance. The precondition is absurdly low: no credentials, no man in the middle, no user click, just the ability to influence text that will be read into context. Three real paths are publishing a server and waiting for installs, taking over an already-trusted server's release rights and changing one field in a patch, or a clean server whose descriptions embed database content. The second is hardest to defend, since users audit only at install time and list-changed notifications say that something changed, not which sentence.
  3. Fold annotations in: the spec requires clients to treat tool annotations as untrusted unless they come from trusted servers. readOnlyHint being true is not proof of safety, only the server's own claim.
  4. Then the defenses, and the ordering is the point: block consequences first, entry second, because every text-based defense is probabilistic while the consequence layer is deterministic.
  5. Consequences: require human confirmation before destructive tools and show the actual arguments (the spec recommends showing tool inputs to the user precisely to catch an innocuous-looking tool exfiltrating via its arguments); render every tool call in the UI, or the injected 'do not tell the user' genuinely works; and decide what is destructive from local policy first, using annotations only to catch extra cases, never to waive one.
  6. Entry: render descriptions as external data with provenance and boundary markers, escaping the markers themselves; apply the same treatment plus a length cap to tool results; and on list changes show the user a diff of the descriptions rather than a bare 'the tool list changed'.
  7. Likely follow-ups: can you just instruct the model to ignore instructions in descriptions? That lowers the probability but cannot guarantee, so it must not be the only line. And do tool results count? Yes, and worse, because they change every call and are larger; official guidance also notes that one server's results are untrusted input to another.

  答题要点

  • 描述由服务端作者写、原样进上下文，和系统提示同一个信任层级，前置条件低到不需要任何凭证
  • 注解同样不可信：规范要求客户端把注解当不可信输入，readOnlyHint 不是安全证明
  • 防护顺序是先挡后果再挡入口：破坏性操作人工确认（展示实际参数）、界面显示每次调用
  • 入口侧给描述与返回加来源标注与边界标记并转义边界符；清单变更时展示描述的 diff

  Key points

  • Descriptions are author-written, land verbatim in context at system-prompt trust level, and need no credentials to exploit
  • Annotations are equally untrusted: the spec says treat them as such, and readOnlyHint proves nothing
  • Order matters: block consequences first with human confirmation showing actual arguments, plus visible tool calls
  • At the entry, wrap descriptions and results with provenance and escaped boundary markers, and diff descriptions on list changes