安全

Orbi Cloud 的访问范围限于你在 GitHub 上授权的仓库，每一项授权你都能从 GitHub 撤销。 这一页把边界说清楚，包括不好听的那些。如果这里有哪条对你的组织是问题，在连接仓库之前知道，比之后知道好。

​

Orbi 能访问到什么

只有你 GitHub App 安装范围内的仓库。 Orbi 不会自己发现仓库，同一时间只在你连接的那一个仓库里处理 Issue。安装范围之外的仓库根本访问不到 —— API 调用本身就会失败。 你的身份，通过 OAuth。 登录只申请一个 scope：user:email。它确认你是谁，本身不授予任何仓库访问权。 App 的仓库权限在 GitHub 的安装页面上会在你批准前完整列出，逐条解释见安装 GitHub App。这些权限加起来，就是一个 agent 干你要它干的活所需要的：读你的 Issue、打标签、评论、推分支、提 PR、评审后合并。

​

撤销访问

从 GitHub 卸载 Orbi GitHub App —— Settings → Applications → Installed GitHub Apps → Orbi → Configure → Uninstall。访问权立即终止。 这才是真正的控制点，而且它在 GitHub 上、不在 Orbi 自己的界面里，这是刻意的：切断它不需要 Orbi 配合。

​

你的模型 key 存在哪

如果你配置了自己的 key，它以 AES-256-GCM 加密存储。它：

• 回显时只显示掩码 —— ••••1234，永远不显示完整值。
• 永远不写进日志，也不会进入任何支持用的证据包。
• 不会出现在任何可能被投屏或分享的界面里。

在模型配置页面填它，别的地方都不要填。不要发邮件，不要贴进 Issue、PR 或评论 —— 那些内容对任何能读你仓库的人都是公开的，而且贴进 Issue 正文的 key 会留在编辑历史里。

​

租户之间的隔离

每个租户的交付环境是一个独立的操作系统用户，有自己的 home 目录和凭据。不同环境之间读不到对方的文件，每一次数据库读取都带租户维度的限定。 跨租户访问、共享可写工作区、凭据泄漏，都被当作发版阻断项处理，而不是留待以后排查的缺陷。

​

交付环境没有什么

跑交付的那个环境有你的仓库和它的测试套件。它没有：

• 你的生产凭据或部署流水线。
• 你的第三方服务账号。
• 对着你线上站点的浏览器。
• 你其他仓库的访问权。

这既是安全性质，也是对「你能要求什么」的实际约束 —— 见写 Issue 的方式。

​

Orbi 会往你仓库里写什么

Orbi 推它为这次交付创建的分支，并把评审过的 PR 合进你的基础分支。除了那次经过评审的合并之外，它不会直接推你的基础分支，也绝不会 force push 共享分支或移动已存在的 tag。 它做过的所有事，完整记录都在你的仓库里：Issue 的标签和评论、PR、评审轮次，以及发版时带着门禁证据的 tag 与 GitHub Release notes。

​

分支保护

分支保护和 Orbi 的相互作用有一个必须知道的点：如果你的基础分支要求 approving review，每次交付都会卡在合并这一步 —— 因为 Orbi 用同一个 App 身份创建并合并 PR，而 GitHub 不允许 PR 作者批准自己的 PR。 连接页面会就此给出警告，并给出三种改法。要求每次交付都有人工批准是完全正当的选择，你只需要知道自己在做这个选择。

​

你的 CI 保证了什么

Orbi 的合并门禁和发版门禁读的是你仓库的 check runs。也就是说，保证的强度就是你测试套件的强度：

• 有像样的单元测试 → 合并门禁保证你的代码逻辑。
• 有业务流程 e2e → 它保证这条流程能走通。
• 完全不跑 CI → 两个门禁都会带着明确的「无 check runs」证据通过，改动仅凭评审的判断就发出去。

不跑 CI 是 Orbi 允许并如实记录的一种选择，而不是假装做出了它给不出的保证。

​

升级不会打断交付

平台的部署和升级在结构上就不可能重启一个正在执行的交付。额度守卫也不能 —— 它们只对刚刚派发的 Issue 生效。在途的交付会跑完。

​

报告安全问题

用状态页技术支持卡片里的 Telegram 群。报告里不要包含凭据、token 或 key。