安全

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，永远不显示完整值。
• 永远不写进日志。
• 不会出现在任何可能被投屏或分享的界面里。

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

​

租户之间的隔离

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

​

交付环境没有什么

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

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

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

​

Orbi 会往你仓库里写什么

普通开发改动提交到交付分支，通过评审后的 PR 进入基础分支。发版不同：发布状态机可以直接提交并推送指定版本文件的更新，不经过 PR。连接空仓库时，也可以创建首个 README 提交。Orbi 不会对共享分支 force push，也不会移动已有 tag。 它做过的所有事，完整记录都在你的仓库里：Issue 的标签和评论、PR、评审轮次，以及发版时带着门禁证据的 tag 与 GitHub Release notes。

​

分支保护

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

​

你的 CI 保证什么

合并和发版门禁读取仓库在相关 commit 上实际报告的检查。检查覆盖什么，由你的 CI 决定；没有测过的行为，绿灯不能替它作保证。Orbi 的独立审查遵循目标仓库自己的测试与覆盖率要求。 检查待完成时等待，检查失败时不合并、不发版。普通 PR 没有检查记录时，仍可能通过独立审查和其余合并条件，但测试状态不会显示为通过。启用了人工验收门禁时，机器无法证明的部分放进检查单，由人确认。 从未观察到 CI 的仓库可以发版，并明确记录没有可检查的 CI；基础分支已经有 CI 时，新版本提交暂时没有检查需要等它注册，不能直接空过。见引擎的交付流程。

​

升级不会打断交付

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

​

报告安全问题

用获取帮助里列出的任一渠道。涉及敏感内容的，发邮件到 [email protected]，不要发在群里。报告里不要包含凭据、token 或 key。