MCP 安全面试：用户点过同意，为什么仍不能执行？

用户点过同意，任务就能永远继续吗？MCP 安全指南讨论了同意、令牌处理与权限范围控制。下面把这些问题放进“排队导出期间权限变化”的练习中；这是一道设计推演，不代表所有 MCP 服务都有同样的实现。

先画出实际能力与身份边界

先盘点能力，再设计控制。列出 Agent 能读、写、执行和发送什么，区分指令和能力，并标明每个动作使用的身份。这样才能知道最小权限和审批门应该放在哪里。

把外部指令和用户授权分开

把提示词注入看成权威层级问题。检索到的文档可以包含指令，但不能凌驾于系统策略或用户确认。说明如何标记不可信内容、约束工具参数，并在越过权限边界时停止。

记录动作，也说明哪些无法撤销

让动作可观察、可回滚。记录工具、操作者、目标、参数、审批和结果；破坏性动作放在有界审批或可逆事务后面。没有回滚方案的治理回答是不完整的。

推演：报告导出获得同意，却还没有真正执行

假设 Agent 要导出一份项目报告。用户批准了一个项目和一个接收位置，但任务排队期间，用户被移出了项目，或 Agent 把目标改成另一个服务。数据库里一个“已批准”标记，无法证明现在仍然可以执行。

先拆开三个问题：调用方是谁？这个身份此刻能做什么？用户具体批准了哪一个动作？身份认证、权限校验和任务审批在流程中相互关联，但不能互相替代。系统 Prompt 写着“尊重用户权限”，也不能代替工具端检查。

审批应绑定实际动作

审批记录至少要能对应操作、资源、目标位置，以及相关内容或版本。实质变化需要重新判断。不能默认模型对工具参数的摘要完全准确，执行层应比较最终动作与被批准动作是否一致。

worker 还要在产生副作用的边界核实权限。仅在入队时检查，会留下时间差。如果资源服务无法把检查和写入做成原子操作，就要明确竞态，缩短间隔，并使用资源服务实际支持的授权保证。凭证如果到期前仍然有效，就不能宣称“撤权立即生效”。

用五个测试把安全方案讲实

至少覆盖：正常执行、批准后失去权限、目标被改、审批过期、成功动作被重放。预期结果不能全部写成“重试”：撤权应拒绝，动作变化需要新审批，已经成功的导出不能悄悄再造成一次披露。

审计也要覆盖拒绝路径。记录操作者标识、被检查资源、原因和关联编号，普通日志不要包含令牌或报告正文。如果审计服务不可用，说明哪些高影响动作必须等待，以及运营人员怎样看到积压。

口头可以这样回答：“审批针对某个具体动作。执行时仍要检查当前权限和目标是否一致，任一变化都不能沿用旧同意。”随后主动补充限制：数据已经送到外部收件人后，删除本地导出文件并不能收回所有副本。

这也是回滚问题最容易讲空的地方。取消排队任务能够阻止泄露，发送后删文件只是有限缓解。能区分这两件事，比笼统承诺“所有 Agent 动作都能撤销”更可靠。

常见问题

System prompt 算安全边界吗？

不算。它只是一个层次，工具和执行环境也必须真正执行权限控制。

审批页面应展示什么？

展示具体动作、目标、将改变的数据、风险和有效期，不要让用户审批一个含义模糊的“运行 Agent”按钮。

第三方 skill 怎么讲？

说明来源、版本、申请的能力、审核方式，以及如何撤销或隔离。

参考来源

• MCP Security Best Practices

下一步

接着阅读MCP 能力与工具边界指南。练习时可以把自己的案例整理进 Interview AiBox 面试档案，但工具不会自动替你核实项目成果。

• 功能全景
• 当前版本说明
• 产品路线图
• 下载 Interview AiBox