> ## Documentation Index
> Fetch the complete documentation index at: https://cloud-docs.orbi.build/llms.txt
> Use this file to discover all available pages before exploring further.

# 安全

> Orbi Cloud 能访问什么，我的模型 key 存在哪，边界在哪里?

Orbi Cloud 的访问范围限于你在 GitHub 上授权的仓库，每一项授权你都能从 GitHub 撤销。

这一页把边界说清楚，包括不好听的那些。如果这里有哪条对你的组织是问题，在连接仓库**之前**知道，比之后知道好。

## Orbi 能访问到什么

**只有你 GitHub App 安装范围内的仓库。** Orbi 不会自己发现仓库，同一时间只在你连接的那一个仓库里处理 Issue。安装范围之外的仓库根本访问不到 —— API 调用本身就会失败。

**你的身份，通过 OAuth。** 登录只申请一个 scope：`user:email`。它确认你是谁，本身不授予任何仓库访问权。

App 的仓库权限在 GitHub 的安装页面上会在你批准前完整列出，逐条解释见[安装 GitHub App](/zh/install-app)。这些权限加起来，就是一个 agent 干你要它干的活所需要的：读你的 Issue、打标签、评论、推分支、提 PR、评审后合并。

## 撤销访问

从 GitHub 卸载 Orbi GitHub App —— **Settings → Applications → Installed GitHub Apps → Orbi → Configure → Uninstall**。访问权立即终止。

这才是真正的控制点，而且它在 GitHub 上、不在 Orbi 自己的界面里，这是刻意的：切断它不需要 Orbi 配合。

## 你的模型 key 存在哪

如果你[配置了自己的 key](/zh/model-configuration)，它以 **AES-256-GCM** 加密存储。它：

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

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

## 租户之间的隔离

每个租户的交付环境是一个独立的操作系统用户，有自己的 home 目录和凭据。不同环境之间读不到对方的文件，每一次数据库读取都带租户维度的限定。

跨租户访问、共享可写工作区、凭据泄漏，都被当作发版阻断项处理，而不是留待以后排查的缺陷。

## 交付环境**没有**什么

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

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

这既是安全性质，也是对「你能要求什么」的实际约束 —— 见[写 Issue 的方式](/zh/first-issue)。

## Orbi 会往你仓库里写什么

Orbi 推它为这次交付创建的分支，并把评审过的 PR 合进你的基础分支。除了那次经过评审的合并之外，它不会直接推你的基础分支，也绝不会 force push 共享分支或移动已存在的 tag。

它做过的所有事，完整记录都在你的仓库里：Issue 的标签和评论、PR、评审轮次，以及发版时带着门禁证据的 tag 与 GitHub Release notes。

## 分支保护

分支保护和 Orbi 的相互作用有一个必须知道的点：**如果你的基础分支要求 approving review，每次交付都会卡在合并这一步** —— 因为 Orbi 用同一个 App 身份创建并合并 PR，而 GitHub 不允许 PR 作者批准自己的 PR。

连接页面会就此给出警告，并[给出三种改法](/zh/connect-repository)。要求每次交付都有人工批准是完全正当的选择，你只需要知道自己在做这个选择。

## 你的 CI 保证了什么

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

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

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

## 升级不会打断交付

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

## 报告安全问题

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

<Note>
  这一页讲的是 Cloud 产品的边界。引擎自己的安全边界 —— 它永远不推哪里、永远不合并什么 —— 在 [docs.orbi.build/zh/security](https://docs.orbi.build/zh/security)。
</Note>