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

# 安全 Profile

> 定义可复用的 Devin 安全 Profile，以限制网络、MCP、git 和 GitHub CLI 访问，并将其绑定到组织、自动化和会话。

安全 Profile 可让你定义可复用的安全限制组合——网络访问、MCP 访问、git 访问和 GitHub CLI 凭据——并将其应用到你的组织中的 Devin 会话。你无需逐个会话配置限制，管理员只需一次创建具名 Profile，再按合适的层级附加：设为组织级默认值、用于特定 自动化，或用于单个会话。Enterprise 还可以在所有组织之间共享 Profile，并将其强制设为任何下级都无法放宽的硬性下限。

<div id="restrictions-in-a-profile">
  ## Profile 中的限制
</div>

Profile 是一组命名的限制条件。每项限制都是可选的——Profile 只会约束其所配置的设置。

<div id="network-policy">
  ### 网络策略
</div>

网络策略是一个目标允许列表，会话所使用的机器只允许访问其中列出的目标。所有其他出站连接都会被阻止。允许列表条目可以是：

* **主机名**，支持 `*` 通配符 (例如 `*.github.com`、`registry.npmjs.org`) 。`*` 可匹配任意字符序列，包括点号。
* **IPv4 / IPv6 CIDR 范围** (例如 `10.0.0.0/8`) 。

此限制适用于会话中的所有网络访问——无论是 Shell 命令、浏览、软件包安装还是脚本。Devin 知道自己是否运行在受限网络策略下：它可以查看当前允许列表；当因目标未加入允许列表而被阻止时，它会请求访问权限。批准该请求后，该目标会被加入该会话的允许列表中 (但仍受任何强制性边界约束——参见[enforcement](#mandatory-vs-recommended-enforcement)) 。

Devin 运行所需的目标 (例如用于访问你已连接代码仓库的 git 代理) 会被自动允许。

<div id="mcp-access">
  ### MCP 访问
</div>

默认情况下，会话可以使用你的组织中安装的任何 [MCP 服务器](/zh/work-with-devin/mcp)。Profile 可以通过 **MCP 服务器允许列表** 对此加以限制——受该 Profile 约束的会话只能使用列出的服务器。

<Note>
  MCP 访问独立于网络策略进行管理：你**不**需要将 MCP 服务器的地址添加到网络允许列表中。Profile 允许的服务器会自动可访问，而被 Profile 排除的服务器无论网络策略如何都无法使用。
</Note>

<div id="devin-mcp-access">
  ### Devin MCP 访问
</div>

会话还可以通过内置的 Devin MCP 使用 Devin 自身的管理工具——创建子会话并向其发送消息、编辑 Knowledge 和 playbooks、管理计划等。Profile 可以通过 **Devin MCP 只读** 限制这部分能力：受该 Profile 约束的会话仍可读取 Devin 资源 (列出会话、查找 Knowledge、查看 playbooks) ，但不能执行创建会话或编辑 Knowledge 等写入操作。

<div id="git-access-level">
  ### Git 访问级别
</div>

控制当前会话对你已连接代码仓库的操作权限：

| 级别     | Devin 可执行的操作              |
| ------ | ------------------------- |
| **只读** | 克隆代码仓库并获取更新，但不能推送分支或创建 PR |
| **完全** | 正常进行克隆、获取更新、推送和创建 PR      |

<div id="github-cli-token">
  ### GitHub CLI 令牌
</div>

除 git 访问级别涵盖的基本 git 操作外，Devin 的机器还可以存储 GitHub CLI (`gh`) 令牌，让 Devin 能够通过 GitHub API 直接使用 GitHub 功能。Profile 可以从机器中**移除 GitHub CLI 令牌**：受该 Profile 约束的会话仍可通过 Devin 的 git 集成访问你的代码仓库，但无法直接发起 GitHub API 调用。

只有在同时授予 **完全** git 访问权限，且设置网络策略时允许访问 `api.github.com` 的情况下，Profile 才能保留该令牌。保存 Profile 时，系统会强制检查这两个条件。

<div id="where-profiles-live">
  ## Profile 的位置
</div>

Profile 存在于两个作用域：

* **组织级 Profile** 在 **Settings → 自定义 → 安全 Profile** 中创建，只能在该组织内使用。
* **企业级 Profile** (仅限企业账户) 在 **企业设置 → Devin → 安全 Profile** 中创建，企业中的每个组织都可使用。组织可以为其会话、自动化或组织默认值选择企业级 Profile，但只有 Enterprise Admin 可以编辑 Profile 本身。

Profile 名称在其作用域内必须唯一。每个 Profile 还带有一个[执行级别](#mandatory-vs-recommended-enforcement)，用于确定较低层级的设置是否可以覆盖它。

<div id="what-you-can-bind-a-profile-to">
  ## 你可以将 Profile 绑定到哪些对象
</div>

Profile 通过*绑定*到某个资源上生效。绑定关系构成一个层级，从范围最广到最具体依次为：

1. **企业默认值** — 适用于企业中每个组织内的新会话。
2. **组织默认值** — 适用于该组织中的新会话。
3. **自动化默认值** — 适用于由该组织中的[自动化](/zh/product-guides/automations)启动的会话，并覆盖这些会话的组织默认值。在同一 security-profiles 设置页面中设置。
4. **自动化** — 适用于由该特定自动化启动的会话，并覆盖自动化默认值。在该自动化的编辑器中设置。
5. **会话** — 可在创建单个会话时选择 (通过会话启动框中的选项菜单) ，也可稍后在会话的设置中更改。

在每一层，你都可以做出以下三种选择之一：

* **继承** (默认) — 不作指定；由上一级决定。
* **固定某个 Profile** — 这一层的会话使用所选的 Profile。
* **无 Profile** — 明确选择不使用，因此即使上一级设置了推荐的默认值，这一层的会话也会不受限制地运行。

当会话启动时，Devin 会自上而下检查这一层级：最具体的绑定优先生效，除非上层的强制 Profile 已将其锁定 (见下文) 。由其他会话生成的会话 (子会话) 遵循与其父会话相同的规则链，因此不能通过委派工作来规避限制。

<div id="when-changes-take-effect">
  ### 更改何时生效
</div>

会话会在启动时解析其生效的管控 Profile：首次创建时，以及每次从休眠中唤醒或重启时。无论是编辑 Profile 内容，还是修改任何绑定 (默认设置、自动化 pin 或会话选择) ，都**不会**自动应用到已在运行的会话——运行中的会话会继续沿用其上次唤醒时解析出的限制。更改会立即对新会话生效，而对现有会话则会在下次恢复时生效。

<div id="mandatory-vs-recommended-enforcement">
  ## 强制执行与建议执行
</div>

每个 Profile 都有一个执行级别：

<div id="recommended">
  ### 推荐
</div>

推荐的 Profile 是默认设置，并非强制要求。任何较低层级的人员 (具有相应权限) 都可以固定为其他 Profile，或完全选择不使用。使用推荐的 Profile，可以在保留灵活性的同时，为团队提供合理的起始配置。

<div id="mandatory">
  ### 强制
</div>

强制 Profile 是一个下限，低层级无法绕开：

* **选择退出无效。** 在强制 Profile 之下选择“无 Profile”会被忽略。
* **低层级的选择只能进一步收紧，不能放宽。** 如果低层级固定到另一个 Profile，这两个 Profile 会*取交集*：
  * 网络允许列表会收窄为 **两个** Profile 都允许的目标地址。
  * MCP 允许列表会收窄为两者都允许的服务器。
  * Git 访问取**最低**权限 (只读优先于完全访问) 。
  * 如果**任一** Profile 设为只读，Devin MCP 访问即为只读。
  * 如果**任一** Profile 移除了 GitHub CLI 令牌，则该令牌会被移除。
* **会话中途的编辑会被限制。** 在会话期间授予的网络访问 (例如批准 Devin 对新域名的请求) 会与强制 Profile 的策略取交集，因此会话获得的访问权限绝不会超出强制 Profile 允许的范围。

例如，企业可以将一个带有网络策略 (允许 `*.internal.example.com`) 的强制 Profile 绑定为企业默认值。随后，各组织可以在其上叠加自己的 Profile，进一步限制特定团队或工作流程——但任何组织、自动化或会话都不能将访问范围扩大到超出企业策略的程度。

<div id="permissions-and-governance">
  ## 权限与治理
</div>

Profile 管理由专门的 **管理安全 Profile** 权限控制，与常规设置管理分开。该权限分为两个级别，且分别独立授予：

| 权限级别         | 允许的操作                                                  | 默认授予给             |
| ------------ | ------------------------------------------------------ | ----------------- |
| Organization | 创建、编辑和删除组织 Profile；设置组织和 自动化 默认值；将 Profile 固定到 自动化 和会话 | Org admins        |
| Enterprise   | 创建、编辑和删除企业 Profile；设置企业默认值                             | Enterprise admins |

这两个级别的权限都可以授予给[自定义角色](/zh/enterprise/security-access/custom-roles)，这样你就可以将安全策略管理交给其他人 (例如安全团队) ，而无需授予完整的 Admin 权限。

没有该权限的成员无法查看、选择或更改 Profile——他们的会话只会遵循解析后的默认值——但任何人都可以看到自己的会话是否受某个 Profile 控制，以及它具有什么网络访问权限。

<div id="setting-up-security-profiles">
  ## 设置安全 Profile
</div>

1. **创建 Profile。** 前往 **设置 → 自定义 → 安全 Profile** (企业范围的 Profile 则前往 **企业设置 → Devin → 安全 Profile**) ，创建一个 Profile，并配置其安全设置和执行级别。
2. **设置默认值。** 将该 Profile 绑定为你的组织默认值 (或企业默认值) ，这样新会话就会自动采用它。
3. **按需固定。** 在特定 自动化 上覆盖默认值——例如，为会接触敏感系统的 自动化 使用更严格的 Profile——或在创建单个会话时进行覆盖。
4. **逐步收紧。** 先从推荐的 Profile 开始，观察其影响；等允许列表已覆盖团队的合理需求后，再将其切换为强制执行。

<div id="automations-and-profiles">
  ## 自动化 和 Profile
</div>

自动化 可使用各自的网络策略和 MCP 选择。这些是在适用 Profile 基础上叠加的**仅限缩层**——由 自动化 启动的 session 只能访问 自动化 和 Profile **均**允许的网络目标和 MCP 服务器。因此，自动化 永远无法扩大 Profile 的访问权限。

系统会在每次 session 启动和唤醒时实时解析 自动化 层，因此编辑 自动化 的网络策略会立即生效，无需重新创建其 session。

<div id="outposts-and-profiles">
  ## Outposts 和 Profile
</div>

在 [Devin Outposts](/zh/cloud/outposts/overview) 上运行的会话会通过与云端会话相同的绑定链确定其适用的 Profile。Devin 在云端实施的限制——MCP 允许列表、Devin MCP 只读、Git 访问级别以及移除 GitHub CLI 令牌——也会同样适用于 outpost 会话。

**网络策略**则有所不同。对于 Devin 管理的 VM，Devin 会在机器级别实施会话的网络 允许列表；但 outpost 工作器运行在由你运营的基础架构上，因此 Devin 不会在你的机器上安装防火墙规则。相反，每个排队会话的有效网络策略会通过 [Outposts API](/zh/cloud/outposts/reference) 以 `spec.network_policy` 字段发布给你的 orchestrator (包括策略是否启用，以及允许的主机名和 CIDR) 。该策略的实施——例如使用按会话配置的出口代理、Kubernetes `NetworkPolicy` 或 VM 防火墙规则——由 outpost 运营方负责。Devin 仍会照常识别 允许列表 中缺失的目标地址并请求访问权限，但批准请求只会更新 Devin 中的会话策略，本身不会改变你的网络。`spec.network_policy` 会在会话排队至 outpost 时记录，并在重新排队时刷新 (例如会话休眠后被唤醒) ，因此应从 API 中重新读取，而不要假定它是静态的。

<Warning>
  如果你将强制 Profile 的网络策略视为严格边界，请确保你的 outpost 基础架构会为其处理的每个会话实施 `spec.network_policy`。否则，outpost 上的会话将拥有你的机器具备的任何网络访问权限。
</Warning>