只读 MCP 很简单。当我们的智能体能够回写后，情况发生了这些变化

Reddit r/AI_Agents 工具
mcp agents security tooling write-access audit best-practices

摘要

作者分享了将 AI 代理的 MCP 访问权限从只读升级为可写（更新工单、编辑数据）后，安全与审计规则必须随之改变的实践经验：读写作用域分离、写操作前显示试运行差异、限制操作影响范围、记录审批与载荷、无撤销路径则保持人工参与。最令人意外的是，大多数事故并非模型犯蠢，而是作用域过宽和不可见的写操作。

几个月来，我们的智能体通过 MCP 只做读取操作：搜索、获取、总结。遇到的问题，重试一下就能解决。直到我们允许它们执行写入操作（更新工单、编辑数据行、发送内容），规则就必须改变了。我们最终采用了这些做法：为每个工具分别设置读取和写入权限范围。绝不让同一个令牌同时拥有两种权限。如果智能体只需要读取 CRM，就不能修改它。每次写入都先展示试运行的差异。人工审批前，能清楚看到究竟会有哪些变化，至少在该操作积累起无事故记录之前，都要如此。限制影响范围。为每次调用设置可操作的数据行或文件数量上限，超过上限就直接拒绝执行，而不是觉得“应该没事”。记录谁批准了什么，以及确切的操作载荷。出问题时，“是智能体干的”算不上解释。没有撤销路径，就不能无人值守地写入。如果无法一步撤销，就必须让人工参与。令人意外的是，我们的大多数事故并不是因为模型犯傻，而是因为权限范围太宽，以及写入操作无人能看见。你第一次允许智能体在无人值守的情况下执行的写入操作是什么？又是什么让你信任它？
查看原文

相似文章

Claude 搭配 MCP，正在从助手变成操作者

Reddit r/AI_Agents

作者分享了将 Claude 与 MCP（Model Context Protocol）连接后，使其从问答助手转变为能执行实际操作的 agent 的使用体验，讨论了数据拉取、费用管理等场景，并强调涉及资金操作仍需人工审批。

MCP 一直是个糟糕的主意吗？

Simon Willison's Blog

文章主张，尽管有观点认为全编程代理已使 MCP 过时，但 MCP 在 AI 代理系统中依然重要，能够提供控制、身份验证、用户界面和审计日志功能。