6.8 理解执行授权边界

开发扩展时，既要检查工具的自身边界，也要检查 Teloa 在派发与执行期间的授权。声明一个“只读”标记不能替代访问控制。

分层检查

层次	应验证什么
资料与业务范围	调用者可见的来源、锁定版本和关联范围
岗位工具授权	当前员工是否获准使用这个完整工具名
当次动作	参数和审批是否仍适用于实际要执行的动作
Harness	工作区、文件、子进程与网络执行策略
外部系统	服务账号、只读凭据、对象权限及写入保护

MCP 的实际限制

参考服务用 readOnlyHint 标注只读意图。无论客户端是否保留这个标注，服务端都应校验身份、对象和参数，Teloa 仍需核对员工工具授权。

上网与文件

员工上网受总开关、岗位授权和具体执行策略约束。搜索和网页读取会产生外部请求；跳转链等边界必须按实际实现逐项测试，不能用一句“已拦截所有域名”概括。

默认组合使用专用工作区与 workspace-write 策略。第三方工具、会话权限和外部凭据仍需要单独核验。Docker 部署没有默认挂载宿主全盘或 Docker socket，也不意味着任何插件行为都自动安全。

员工 API 例外： 业务系统发起工作时可以按请求指定 permissionMode；未指定时新工作默认 danger-full-access，续做默认继承上一轮。这个模式只改变本轮的沙箱与审批边界，不扩大员工的工具授权，也不能绕过集成的 execute 权限或工作台审批。调用方应显式选择满足业务需要的最小模式，见员工 API 的执行模式。

最小验收矩阵

同一任务分别测试：未授权拒绝、授权后成功、授权撤回后拒绝、来源不可用、参数不合法、执行中停止。记录实际工具回包与业务结果，不能只看模型说“操作成功”。