用 Rust 代理审查 MCP 工具执行

Agent 接上数据库和内部 API 后，模型误判就可能变成真实的业务操作。dev.to 上一篇文章披露，作者正在用 Rust 实验一个名为 Trust Gateway 的代理：把工具调用先当作待审查的提案，通过检查后才允许执行。目前披露的是本地实验，尚不能据此判断生产可用性。

目前能确认什么

MCP 为工具发现和调用接口提供标准，但接口标准化不等于每次操作都符合业务约束。作者关注的是：当执行端持有长期凭据，Agent 提交的错误参数或受提示注入影响的指令，可能直接改变业务状态。提示注入指外部内容诱导模型偏离原有任务。

他们团队将 Trust Gateway 放在 Agent 与下游执行端之间，并提供检查 CLI：trustctl。实验中，Agent 不接触原始 API 密钥，而是提交签名提案；网关检查身份和预签名的能力边界，再签发绑定具体参数的短期、单次授权。

作者还描述了两类处理：使用 Ed25519 签名在本地验证策略；对无法验证或高风险的操作暂存待审。演示环境中的破坏性操作需要两人签名批准。这些属于作者披露的实验设计与结果，节选不足以证明完整实现。

我的判断

最有价值的思路，是把「模型想调用工具」与「系统允许执行」拆成两个决定。

对接内部 API 的程序员，可以据此检查自己的权限链：退款金额上限、可操作账户、删除范围，是否由执行端独立约束，还是只写在提示词里。

但签名能证明提案和参数未被篡改，不能证明操作符合用户真实意图。错误金额也可能被完整签名。

还需要确认下游是否强制验证授权、是否存在绕过网关的路径，以及单次授权如何防止重复执行。原文节选没有完整交代这些机制；它们直接决定这个代理能否真正守住执行边界。