MCP可以让AI连接工具、资源和工作流，但“能调用”不等于“应该随时调用”。特别是文章发布、数据库写入、文件删除和外部通知等动作，如果没有权限边界和审计记录，自动化很容易变成安全隐患。
先区分只读工具和写入工具
查询文章、读取配置和获取公开资料，通常属于只读能力；创建文章、修改分类和上传文件，则属于写入能力。两类工具不应使用同一套权限和确认流程。
只读工具可以在较低风险下自动调用，写入工具需要更严格的参数校验、身份认证和结果记录。
工具描述要明确副作用
工具名称和描述不能只写“发布文章”“更新数据”。还应该说明会写入哪些表、是否会触发外部请求、失败后能否重试，以及调用成功后返回什么结果。
- 说明目标资源和操作范围；
- 说明必填参数和格式；
- 说明可能产生的副作用；
- 说明错误码和下一步处理方式。
参数校验必须放在服务端
模型生成的参数不可信，不能只依赖客户端或提示词检查。服务端应校验字符串长度、URL协议、分类ID、标签数量、文件类型和请求体大小，发现异常立即拒绝。
if ($payload['status'] !== 1 || mb_strlen($payload['title']) > 120) {
throw new InvalidArgumentException('invalid publish payload');
}高风险操作增加幂等键
网络超时并不代表服务端没有执行成功。发布文章时应携带幂等键，服务端保存处理结果，重复请求返回已有结果，而不是再次创建一篇相同文章。
不要把密钥放进工具描述
工具说明、错误信息和调用日志都可能被模型或管理员看到。密钥、签名原文和完整授权信息不应该出现在这些位置。服务端应从受控配置中读取密钥，并对日志做脱敏。
调用日志至少记录什么
- 调用时间和任务ID；
- 调用者身份和来源；
- 工具名称和参数摘要；
- 目标资源与返回状态；
- 耗时、重试次数和错误类型。
日志要足够支持排查，但不要保存完整文章中的敏感资料。可以使用内容摘要、哈希或截断后的字段进行关联。
异常告警要关注行为模式
单次失败不一定是攻击，但短时间大量调用、参数长度突然增大、频繁尝试不存在的资源和连续失败后成功，都应该进入告警范围。告警要带上任务上下文，避免只有一条“调用失败”的无效信息。
上线前做一轮反向测试
测试时不仅要验证正确参数，还要主动传入空值、超长文本、错误ID、外部URL、重复请求和过期签名。确认服务端不会越权、不会写入错误数据，并且错误响应不会泄露内部路径。
总结
MCP安全审计的重点，不是把工具全部禁用，而是把只读、写入和高风险动作分层管理。工具描述负责让模型理解边界，服务端校验负责真正守住边界，日志和告警负责让问题可追溯。
评论 0