让所有工具路径遵守同一限制

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

源码评审没有修改权限，却移除Edit后仍留通用Shell和HTTP写入。教学load-html还有setcontent别名，按工具字面名查权限会漏同一效果。

具体做法

盘点可到达的文件/远端修改路径，在许可查找、派发和审计前将支持别名规范化为效果，未知拼写拒绝。用真实只读文件/网络边界约束通用执行，不只是隐藏工具。验证Edit写、Shell写、HTTP写与别名写都被拒，允许读取仍成功；记录实际宿主能力及缺口。

反例

禁Edit就说只读，setcontent别名与Shell写任意执行。

改进写法

把load-html及setcontent规范到同一写效果，再查只读scope。编辑器、Shell和远端写也在宿主约束；用受控目标验证拒绝而不真的改生产。保持源码读取可用，未知别名不自动回落执行。

为什么这样改

工具别名和通用执行都可能到同一副作用。效果规范化与运行时约束共同保护边界，单个名字禁用只能覆盖一个入口。

如何验证

教学load-html与setcontent均拒绝，普通读允许；三个通用写尝试也无目标变化。只返回拒绝文本却已写文件不算成功。检查日志记录规范效果和原请求，不暴露秘密。

适用边界

全部路线需实际枚举，动态插件可能增加新入口。提示约束或别名表都不是完整隔离；网络规则也要按真实协议和环境处理。单个负例不证明全防绕过。