为Agent建立协议、运行防护与测试边界

Agent 能读文件、执行命令、调用 API 后，安全问题就从回答是否可信，延伸到了操作是否获准。dev.to 的这篇文章把防护拆成三层：MCP 负责接口契约，运行时防护检查调用与返回，测试验证工具和完整流程。现有节选给出了分层思路，也展示了一个刻意缺少防护的 MCP 服务示例。

目前能确认什么

作者区分了三类风险：网页或文件中的提示注入（Prompt Injection）、工具缺陷或依赖被入侵，以及多个看似合理的操作组合出破坏性结果。它们需要不同的防线，不能只靠模型判断。

MCP 为工具调用提供统一接口，工具参数可用 JSON Schema 描述，便于集中检查。但参数符合格式，只能证明它满足结构要求，不能证明操作已获授权。例如，路径是合法字符串，不代表 Agent 就能读取这个文件。

节选中的 Python 示例暴露了两个工具：读取文件、执行 shell 命令。前者没有限制可访问路径，后者使用 shell=True，两者都没有检查返回内容。作者用它们说明防护应该落在哪里，并非提供可直接上线的实现。

目录还列出了输入输出扫描、工具单元测试、MCP 集成测试、模糊测试和对抗测试，但具体实现尚未完整展示。

我的判断

这套分层最有用的地方，是把安全责任落到具体的执行边界。

对接 Agent 的程序员可以据此拆任务：工具层限制路径、命令和权限；运行时检查请求与返回；测试层覆盖越权读取、敏感信息返回、连续操作导致误删等场景。单个工具测试通过，仍然需要验证整个工作流。

不过，扫描器能否识别绕过手法、被入侵的工具如何受到约束、危险操作怎样被策略拦截，现有节选没有说清。输入输出扫描也不能替代沙箱和权限限制，尤其数据已经外传时，检查返回值可能为时已晚。

因此，我会把它当作防护架构的拆分方法；实际安全效果，还要看后文是否给出明确的权限边界、拦截规则和失败用例。