MCP 写入工具的审批应该在哪里执行?
摘要
本文讨论了在 MCP 工具中对写入操作执行审批的位置,考虑了客户端和服务端方法,以及记录哪些内容以便与批准的操作进行核对。
一个 MCP 客户端可以连接到暴露只读工具和更改外部账户操作的服务器。我最近测试了一个本地的 Reddit MCP,其中浏览、搜索和帖子阅读工具与回复、发帖和投票工具一起可用。只有在有人审查了确切文本并明确批准该单个操作后,写入操作才感到安全。对于构建或使用具有副作用工具代理的人,你在哪里执行这一边界:客户端审批、服务端权限,还是两者兼有?你记录哪些内容,以便可以将执行的操作与批准的内容进行核对?
相似文章
有人在开发者安装MCP服务器之前实际进行安全审查吗?
这是一个关于在开发者安装MCP服务器之前是否有人进行安全审查的问题,突显了AI工具生态系统中的潜在漏洞。
你在安装 MCP 服务器之前实际上是如何审查它们的?
讨论在安装前缺乏对 MCP 服务器的审查,强调一项研究发现 5.5% 的工具被投毒,14.4% 存在已知漏洞模式,再加上 MCP SDK 中的一个系统性 RCE。
Azure DevOps MCP 与代理 PR 审查中的混乱代理问题
一份关于微软 Azure DevOps MCP 服务器的报告揭示了一种混乱代理攻击:隐藏的 PR 文本可以操纵 AI 审查代理(Copilot CLI、Claude Code)以用户的权限进行非预期的工具调用。建议包括使用只读身份并要求单独的审批步骤。
人工审批对于生产级智能体来说过于模糊
文章认为,智能体系统中的人机协同应从模糊的审批转向明确的、可审计的、每步签署的决策记录,包含详细证据、数据载荷、幂等键、回滚路径和职责归属。文章强调了批准黑箱故事而非具体操作的危险性。
今天你是如何安全地让 AI 代理 / MCP 工具更改生产数据的?“数据分支”会有帮助吗?
一场讨论,提出使用生产数据的 AI 代理应该采用数据分支——让代理写入克隆的数据库,然后审查最终的差异,而不是逐个批准每个操作。