用权限代理隔离智能体密钥与执行

dev.to 上的一篇教程把智能体密钥安全落到了执行代码里：在模型与工具之间加入默认拒绝的权限代理，模型提交工具名称和参数，凭据留在执行侧。作者还给出了权限策略和对抗测试。不过，从现有节选看，设计思路与示例代码是否正确实现，需要分开判断。

目前能确认什么

作者划出了三个独立的信任边界：模型后端、工具执行和遥测日志。密钥一旦进入消息，就可能被重试记录、调试输出或服务端存储继续保留。仅靠 system prompt 要求模型保密，无法替代执行侧的权限检查。

权限代理采用「默认拒绝」：逐项开放工具、参数和访问范围。示例只允许读取 docs/ 下的文件，拒绝绝对路径、包含 .. 的路径和额外参数，并明确禁用 http_get。日志则只记录工具名、参数名和执行状态，避免保存参数值。

模型可以提出请求，但授权必须由执行代码决定。

节选列出了针对越权工具、路径穿越和夹带参数的测试，但没有展示实际运行结果。

我的判断

对正在接入 Agent 的程序员，这个方案最有用的地方，是把权限变成可以审查、可以回归测试的配置。新增工具默认不可用，能减少工具扩展时顺手扩大授权范围的问题。

不过，节选代码有一处明显疑点：tomllib 会把 [tools.read_repo_file] 解析为 tools 下的嵌套字典，示例却在顶层查找以 tools. 开头的键。按所示代码，工具表会为空，合法请求也会被拒绝；那些只验证拒绝行为的测试仍可能通过。

拒绝测试通过，不等于权限代理工作正确。

还需要合法调用测试，以及完整 Agent 循环验证：读取含恶意指令的文档后，系统是否仍能拦住后续越权调用。当前节选不足以确认这些行为，也不能据此认定凭据泄露问题已经解决。