6.5 理解执行授权边界
开发扩展时,既要检查工具的自身边界,也要检查 Teloa 在派发与执行期间的授权。声明一个“只读”标记不能替代访问控制。
分层检查
| 层次 | 应验证什么 |
|---|---|
| 资料与业务范围 | 调用者可见的来源、固定版本和关联范围 |
| 岗位工具授权 | 当前同事是否获准使用这个完整工具名 |
| 当次动作 | 参数和审批是否仍适用于实际要执行的动作 |
| Harness | 工作区、文件、子进程与网络执行策略 |
| 外部系统 | 服务账号、只读凭据、对象权限及写入保护 |
MCP 的实际限制
参考服务提供 readOnlyHint 等标注,但当前 DSH MCP 注册路径并不完整保留这些标注。不要让产品仅凭标注自动降低权限要求,也不要把工具名字中的 read 当成安全保证。
上网与文件
同事上网受总开关、岗位授权和具体执行策略约束。搜索和网页读取会产生外部请求;跳转链等边界必须按实际实现逐项测试,不能用一句“已拦截所有域名”概括。
默认组合使用专用工作区与 workspace-write 策略。第三方工具、会话权限和外部凭据仍需要单独核验。Docker 部署没有默认挂载宿主全盘或 Docker socket,也不意味着任何插件行为都自动安全。
最小验收矩阵
同一任务分别测试:未授权拒绝、授权后成功、授权撤回后拒绝、来源不可用、参数不合法、执行中停止。记录实际工具回包与业务结果,不能只看模型说“操作成功”。