CompozyOS 权限与审批机制完整指南AI Agent 安全执行的权限模式与跨工作区访问边界【免费下载链接】compozyAn operating system for AI agents. Plug in the agent CLIs you already use (Claude Code, Codex, Gemini CLI, Cursor) and they become a team: they split the work, hand tasks to each other, run automated on jobs and loops, and share one project memory. You steer everything from the browser.项目地址: https://gitcode.com/gh_mirrors/co/compozyCompozyOS 是一个AI Agent 操作系统把你已在用的 Agent CLIClaude Code、Codex、Gemini CLI 等接入后它们能分工协作、自动跑任务而你通过浏览器掌控一切。那么如何让这些 Agent安全执行答案是 CompozyOS 的权限与审批机制三种静态权限模式deny-all、approve-reads、approve-all 交互式审批流 跨工作区访问边界。这篇指南帮你快速看懂这套 AI Agent 权限安全体系并知道如何为自己的项目配置最合适的权限模式。权限如何生效两层防线CompozyOS 的权限体系分为两层两者都限定在会话所在工作区范围内生效守护进程侧的静态策略对内置文件读写、终端操作等工具直接做允许/拒绝判定不经过 Agent 运行时交互式审批流当 Agent 通过 ACP 协议主动发起session/request_permission请求时由你在浏览器、CLI 或 API 侧手动批准。即使选择最宽松的approve-allAgent 的执行范围也始终受工作区边界约束所有路径都会先解析到会话的工作区根目录一旦逃逸出根目录CompozyOS 直接返回 path-outside-workspace 错误不会静默放行。三种权限模式deny-all / approve-reads / approve-allCompozyOS 提供三种静态权限模式一个模式同时决定工具风险和跨工作区两个维度的行为模式内置文件/终端操作跨工作区请求deny-all全部拦截读取也不自动放行处处拒绝且从不弹窗approve-reads仅自动放行文件读取在原生工具边界处弹窗询问其他边界拒绝approve-all自动放行读取、写入和创建终端直接放行 注意deny-all在两个维度含义不同——对工具它是不自动放行、改为询问对工作区边界它是绝不跨越、绝不询问。它是让会话锁死在自己工作区内的 lockdown 设置。内置默认是approve-all全局可通过~/.compozy/config.toml的[permissions] mode覆盖也可在单个 Agent 定义的AGENT.md中用permissions字段单独收紧。完整规则见官方文档permissions.mdx。交互式审批流4 种审批决策与 5 分钟超时当会话处于需要审批的模式时Agent 的敏感操作会变成一个待审批请求你在 Web 端的权限面板中直接作答审批接口统一接受 4 种决策决策含义allow-once仅允许这一次allow-always记住精确决策工作区 Agent 工具 输入摘要之后匹配调用直接复用且守护进程重启后依然有效reject-once仅拒绝这一次reject-always记住拒绝决策同样持久化几个关键细节超时即拒绝待审批请求默认最多等待5 分钟超时自动按reject-once处理Agent 不会无限挂起工作区外请求不进入待审批越界请求被直接立即拒绝审批入口全平台一致浏览器、compozy session approveCLI、HTTP/UDS API 驱动的是同一个审批面。上面是 CompozyOS 浏览器端界面右上角的红色铃铛数字就是待审批提醒点击即可进入审批流跨工作区访问边界单一策略漏斗每个会话只属于一个工作区。当 Agent 想越界——调用另一个工作区的原生工具、查询 Agent 身份、认领任务、派生子会话或执行工作区协调命令——请求会经过同一个策略漏斗policy.go 定义了 5 个边界identity、task、tool、spawn、catalog由该会话自己的权限模式裁决approve-all跨越放行不打扰你approve-reads仅在原生工具边界弹窗询问其余边界一律拒绝deny-all所有边界都拒绝连弹窗都不会出现。在approve-reads下跨工作区询问提供 4 个选项allow_once允许一次、allow_session本会话内全部放行、reject_once、reject_session本会话内全部拒绝。会话级答复只存在守护进程内存中会话停止或守护进程重启即消失不落盘、无列表、无撤销界面——停掉会话就是清空答复的方式。完整决策链可以在 default_policy.go 中看到先校验操作者身份人类操作者不受此策略约束再判断是否同工作区最后按权限模式分支并且每一次判定都会尝试写入审计事件。安全派生子会话的权限只能收窄Agent 可通过compozy spawn派生子会话协作但安全是默认值子会话的工具、技能、MCP 服务器、工作区路径必须是父会话权限集合的子集任何无法识别的权限项都视为扩大并直接拒绝派生派生深度默认上限 1 层、子会话默认上限 5 个且必须指定 TTL。跨工作区派生同样走上面的策略漏斗且派生边界从不弹窗——被拒就是被拒。详见safe-spawn.mdx。审计留痕每次允许与拒绝都可追溯策略漏斗的每一次评估无论允许还是拒绝都会尽力追加一条审计事件workspace.access_granted或workspace.access_denied载荷包含目标工作区、边界类型、判定来源和生效的权限模式。你可以用compozy logs --type event-type或GET /api/logs回放完整历史——这正是官方建议的看到到底发生了什么越界的方式。⚠️ 诚实的边界说明CompozyOS 处于 beta该机制约束的是 Agent 在运行时边界上的请求而不是 Agent 进程本身的操作系统级沙箱。拥有 shell 权限的 Agent 理论上仍能改磁盘上的配置文件会话级跨工作区答复在会话存活期间无法列出或撤销。需要绝对隔离的会话请设deny-all并配合事件历史复盘。详见resolver.mdx。快速上手3 步配置权限与审批第 1 步设定全局基线。在~/.compozy/config.toml中[permissions] mode approve-reads第 2 步按 Agent 收紧。在 Agent 定义的AGENT.mdfrontmatter 中加一行permissions: deny-all比如给纯代码评审型 Agent 上锁。第 3 步掌握审批入口。日常在 Web 端点审批铃铛处理脚本化场景用compozy session approveAPI 自动化则 POST 到会话的 approve 路由body 中传 4 种决策之一。总结CompozyOS 的权限与审批机制可以概括为一句话三种权限模式定基线工作区边界划地盘审批弹窗管例外审计日志留全痕。对新手最实用的建议是日常用默认的approve-all提效让 Agent 触碰真实敏感路径的会话切到approve-reads必须圈养的会话用deny-all。【免费下载链接】compozyAn operating system for AI agents. Plug in the agent CLIs you already use (Claude Code, Codex, Gemini CLI, Cursor) and they become a team: they split the work, hand tasks to each other, run automated on jobs and loops, and share one project memory. You steer everything from the browser.项目地址: https://gitcode.com/gh_mirrors/co/compozy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考