---
title: "Cloud Agent 网络安全"
description: "基于 Cursor 官方 Security & Network 文档解释 Privacy Mode、secret protection、signed commits、egress、artifact host 和 IP allowlist。"
verifiedAt: "2026-05-09"
---

Cloud Agent 网络安全的核心不是“开或关网络”，而是明确代码、密钥、artifacts、外部访问和团队策略各自的边界。

> [!NOTE]
> **阅读目标**：读完本章，你应该能为 Cloud Agent 设置一套可审计的网络和安全策略，并能解释 artifact host、allowlist 和 team lock 的取舍。

## 1. Privacy Mode 和数据边界

Cloud Agents 可在 Privacy Mode 下使用。官方说明中，Cursor 不会用你的代码训练模型，只会为运行 agent 保留代码。

需要注意：

- 如果 Privacy Mode 关闭，Cursor 会收集 prompts 和 dev environments 用于改进产品。
- 如果启动 Cloud Agent 时关闭 Privacy Mode，运行中再开启 Privacy Mode，这个 agent 会继续按关闭状态跑完。
- 采购、法务和安全评审要看“agent 启动时”的配置，而不是只看当前 dashboard 状态。

## 2. Secret protection

提供给 Cloud Agents 的 secrets 会在 at rest 和 in transit 状态加密。

你可以把 secret 标记为 **Redacted**，获得额外保护：

| 保护 | 行为 |
| --- | --- |
| commit / file scan | commit message 和文件中如果包含该 secret，会被拒绝 |
| model redaction | secret 会从 model tool calls 中遮蔽，不展示给模型，也不进入 chat transcripts |

这能降低两类风险：凭据被写进版本控制，以及凭据进入模型上下文。

Redacted secret 不等于可以随意扩权。它只是一道保护层，仍然要控制谁能创建 agent、谁能 follow-up、哪些 MCP 可用、网络能访问哪里。

## 3. Signed commits

Cloud Agents 会用 HSM-backed Ed25519 key 给每个 commit 签名。GitHub 和 GitLab 上会显示 Verified badge。

实际意义：

- 团队能确认 commit 来自 Cursor Cloud Agent。
- 对要求 signed commits 的 branch protection rules，Cloud Agent PR 可自动满足。
- 不需要额外配置。

这解决的是“commit 来源可信”，不是“代码一定安全”。仍然要做 diff review、CI、security review 和产品验收。

## 4. 必须知道的风险

Cloud Agent 的执行边界和本地 foreground agent 不一样：

| 事项 | 边界 |
| --- | --- |
| Repo 权限 | 要给 Cursor GitHub App 对目标 repo 的 read-write 权限 |
| 运行环境 | 代码在 Cursor AWS infrastructure 的 isolated VMs 中运行，并在 agent 可访问期间存在 VM disk 上 |
| 网络 | 默认有 internet access，可用 egress controls 限制 |
| 命令执行 | terminal commands 会自动运行，便于迭代测试 |
| Prompt injection | 自动命令 + 网络访问会带来数据外传风险 |
| Privacy toggle | 运行中切换 Privacy Mode 不影响已启动 agent 的模式 |

所以，Cloud Agent 的默认能力比本地需要逐条审批命令的 foreground agent 更适合长任务，也更需要网络和权限边界。

## 5. Network access modes

在 Cloud Agents dashboard 的 Security 区域，可以配置 outbound network access。

| Mode | 行为 | 适合 |
| --- | --- | --- |
| Allow all network access | 不限制外部 host | 低敏 repo、快速试用、非生产环境 |
| Default + allowlist | 默认域名 + 自定义 allowlist | 大多数团队场景 |
| Allowlist only | 只允许显式加入 allowlist 的域名 | 高敏项目、企业锁定策略 |

即使在 Allowlist only 模式，仍会保留一小组必要域名，以保证 Cloud Agents 基本功能可用，包括 Cursor 自身服务和 SCM providers。

## 6. Artifact uploads

Cloud Agents 会把 screenshots、videos、log references 这类 artifacts 上传到：

`cloud-agent-artifacts.s3.us-east-1.amazonaws.com`

如果使用 Default + allowlist 或 Allowlist only，要把这个 exact host 加入 allowlist，否则 artifacts 上传失败。agent session 和其他 tool calls 仍会继续，但 PR embeds、dashboard previews 或通知附件会缺失。

不要用 `*.s3.us-east-1.amazonaws.com` 代替 exact host。wildcard 会放开该 region 的所有 bucket，给 prompt-injected agent 留出外传路径。

My Machines 和 Self-hosted Pool 上传 artifacts 也走同一个 host。自托管部署时，要确保 worker 到公网之间的防火墙允许它。

## 7. User、team 和 Enterprise lock

network access 可以由个人用户和团队管理员配置。

| 层级 | 行为 |
| --- | --- |
| User-level | 用户设置应用到自己创建的所有 Cloud Agents |
| Team default | 用户没有设置时，团队默认生效 |
| Enterprise lock | 管理员锁定后，团队设置覆盖所有用户，用户不能改 |

优先级：

1. Enterprise lock 最高。
2. 未锁定时，user setting 优先于 team default。
3. 用户没有设置时，team default 生效。

团队级 allowlist 和 desktop Agent sandbox default network allowlist 是同一套 allowlist，没有第二份列表要维护。

## 8. Sandbox network policy 关系

Default + allowlist 中的 default domains 和 desktop Agent sandbox 的 default network allowlist 相同。

团队管理员在 dashboard 配的 allowlist 同时影响：

- Cloud Agent network access。
- desktop Agent sandbox network policy。

这有好处：统一治理。也有风险：不要只为了某个 Cloud Agent 放开一个域名，却忘了它也影响 sandbox 默认网络策略。

## 9. Egress IP ranges

Cloud Agents 从特定 IP ranges 发起网络连接。官方提供 JSON endpoint：

`https://cursor.com/docs/ips.json`

响应包含：

| 字段 | 含义 |
| --- | --- |
| `version` | schema version |
| `modified` | IP ranges 更新时间 |
| `cloudAgents` | 按 cluster 分组的 Cloud Agent CIDR |
| `gitEgressProxy` | git egress proxy IPs |

这些 IP ranges 可用于 clone / push、下载依赖、访问外部 API 和 web resources。

官方不建议把 IP allowlist 当作主要安全机制。如果必须这样做，要定期监控 JSON endpoint，因为 Cloud Agent IP 会因扩容和运维变化。

## 10. Git egress proxy

Git host 场景优先使用 Cursor 的 git egress proxy allow list 配置。它会把 git traffic 通过更窄的一组 IP 路由，并支持 GitHub、GitLab 等 git hosts。

如果必须直接加入 allowlist，官方当前列出的稳定 proxy IP 是：

- `184.73.225.134`
- `3.209.66.12`
- `52.44.113.131`

这些 IP 变更时，使用 IP allow lists 的团队会提前收到通知。

## 商业级验收

上线前至少确认：

- Privacy Mode 是否在 agent 启动前符合团队要求。
- secrets 是否使用 dashboard 管理，并对关键 secret 启用 Redacted。
- GitHub / GitLab branch protection 是否接受 Cloud Agent signed commits。
- 网络模式是否从 Allow all 收敛到 Default + allowlist 或 Allowlist only。
- artifact exact host 是否加入 allowlist，且没有用 S3 wildcard 放大出口。
- team allowlist 与 sandbox network policy 的共享影响已评估。
- Enterprise team 是否需要 Lock Network Access Policy。
- IP allowlist 不是唯一防线，且有监控 `ips.json` 的机制。

## 官方来源

- [Cursor Cloud Agent Security & Network](https://cursor.com/docs/cloud-agent/security-network.md) —— 官方 Privacy Mode、secret protection、signed commits、network access、artifact uploads、IP ranges 和 git egress proxy。
- [Cursor Cloud Agent Capabilities](https://cursor.com/docs/cloud-agent/capabilities.md) —— 官方 artifacts 背景。
- [Cursor My Machines](https://cursor.com/docs/cloud-agent/my-machines.md) —— 官方 self-hosted worker networking。
- [Cursor Self-Hosted Pool](https://cursor.com/docs/cloud-agent/self-hosted-pool.md) —— 官方 pool networking。

## 接下来去哪

<Cards>
  <Card title="Cloud Agent Settings" description="继续学习 workspace admin 设置、summary、team follow-ups 和权限风险。" href="/docs/cursor/official/04-cloud-agents/60-settings" />
  <Card title="Cloud Agent Best Practices" description="回看环境、工具和验收清单。" href="/docs/cursor/official/04-cloud-agents/58-best-practices" />
</Cards>
