11 · 团队使用的安全边界

个人试用 Antigravity 和团队使用 Antigravity 是两件事。团队场景里，问题不是“谁会用”，而是 agent 能访问什么、谁批准什么、artifact 保存什么、MCP 能调用什么、哪些动作绝不自动执行。

官方 Plans 文档说明，Antigravity 当前面向个人账号可用，团队场景仍属于 pre-general availability preview。也就是说，团队上线前必须先确认账号、条款、数据边界和内部安全策略，而不是照搬个人试用设置。

1. 团队治理图

flowchart TD
    Team["团队使用 Antigravity"] --> Account["账号与条款"]
    Team --> Workspace["Workspace 边界"]
    Team --> Permission["权限策略"]
    Team --> Browser["浏览器策略"]
    Team --> MCP["MCP 策略"]
    Team --> Artifact["Artifact 留存"]
    Team --> Release["发布与提交"]

团队治理要先确定责任边界：

不要让每个开发者自己决定这些事。个人偏好不能替代团队安全策略。

2. 账号与数据

先确认：

• 使用个人 Gmail 还是企业账号。
• 是否允许代码和上下文进入对应产品。
• 是否允许 browser agent 访问内部系统。
• 是否允许 artifact 保存截图、录屏和 diff。
• 是否有客户数据、密钥或隐私数据限制。

这些问题要先由团队定规则，不要让每个开发者自己猜。

建议形成一份简短准入说明：

本团队允许 Antigravity 访问：当前项目 workspace、公开官方文档、localhost 页面。
本团队禁止 Antigravity 访问：生产数据库、密钥目录、客户数据后台、个人邮箱、支付和广告后台。
发布、付款、删除、迁移、授权类动作必须人工执行。

3. Workspace 边界

团队项目建议：

1. 一个 workspace 对应一个项目或一个清晰模块。
2. 禁止 workspace 指向用户家目录。
3. 禁止把凭据目录纳入 workspace。
4. .env、密钥、私有导出文件要进 ignore 或规则禁止读取。
5. 大任务拆成单模块 conversation。

Workspace 不要只是“打开仓库根目录”。还要检查：

4. 权限默认值

真实项目建议开启 Strict Mode，因为它会强制 terminal、browser JavaScript 和 artifact review 回到 Request Review，并禁用 workspace 外文件访问。即使不开 Strict Mode，也应该手动配置成同样保守的组合。

5. MCP 策略

MCP 不要全局随便接。团队应建立清单：

• server 名称
• tool 列表
• 读写能力
• 外部网络行为
• 凭据来源
• 默认 allow/ask/deny
• 适用 workspace

任何会创建、删除、发布、付款、发消息的 tool，都应该默认 Ask 或 Deny。

官方 MCP 文档里的支持 server 包含 GitHub、Linear、Notion、Stripe、PayPal、数据库、云服务等多类高权限系统。团队要按 tool 评估，而不是按 server 名字粗放批准。

MCP 上线表可以这样写：

6. Browser 策略

浏览器 agent 不应该默认访问：

• 邮箱
• 云盘
• 付款后台
• 广告后台
• 生产管理后台
• 客户数据页面

如果确实要让它做后台只读检查，写清：

1. URL 范围。
2. 只读目标。
3. 不允许点击提交、删除、授权、付款。
4. 必须截图脱敏。

官方 Browser 文档说明 Antigravity 使用 separate browser profile，默认没有日常 Chrome 登录态。这是安全边界，不要为了方便把真实账号登录进去再让 agent 自由点击。

团队 browser rule 可以写：

Browser agent 默认只允许 localhost 和官方文档。
任何真实后台、支付、广告、云控制台、邮箱、客户数据页面，只允许人工操作。
如果需要只读检查，必须写明 URL、目标、禁止点击的按钮和截图脱敏要求。

7. Artifact 留存

Artifacts 可能包含代码、截图、页面内容、错误日志和路径。团队要决定：

• 哪些 artifact 可以长期保留。
• 哪些截图需要脱敏。
• walkthrough 是否允许包含内部 URL。
• 录屏是否包含用户信息。
• PR 或 issue 中能否粘贴 artifact。

Artifacts 是信任层，也是数据载体。截图可能包含客户邮箱，录屏可能包含后台 URL，diff 可能暴露私有实现，walkthrough 可能写出内部路径。团队要明确哪些 artifact 可以进 PR，哪些只能本地留存，哪些要脱敏后再分享。

8. 发布前红线

Antigravity 可以帮你准备发布，但不应该默认执行发布。红线动作：

• git push
• 部署生产
• 数据库迁移
• 删除远端资源
• 修改 DNS
• 修改支付/广告配置
• 发布内容到公开平台

这些动作可以让 agent 写 checklist 和命令草案，但执行必须人工确认。

9. 团队落地流程

建议按四步落地：

flowchart TD
    Pilot["个人试点"] --> Rules["写 workspace rules"]
    Rules --> Skills["沉淀必要 workflows / skills"]
    Skills --> Review["团队审查权限和 MCP"]
    Review --> Rollout["小范围团队启用"]
    Rollout --> Audit["每周复盘 artifact 和事故"]

不要第一天全员放开。先选一个低风险项目，只让 Antigravity 处理文档、UI 验收、测试补齐这类可回退任务。等团队熟悉 plan、diff、browser、artifact 后，再扩大范围。

10. 团队使用模板

可以把下面内容写进 workspace rule：

# Antigravity 团队边界

1. 默认使用 Planning。
2. 所有跨文件改动必须先给 Implementation Plan。
3. Terminal、Browser JavaScript、Artifact Review 均使用 Request Review。
4. Browser 默认只访问 localhost 和必要官方文档。
5. 禁止读取 workspace 外凭据、个人文件和生产数据。
6. 禁止自动 git push、部署、数据库迁移、付款、广告、授权、删除远端资源。
7. UI 改动必须提供 mobile / desktop 截图和 console 检查。
8. Walkthrough 必须列出改动文件、验证结果和未覆盖风险。

本章自检

完成本章后，用这 3 个问题检查自己是否真正理解：

1. 团队使用为什么不能照搬个人试用配置？
2. MCP 为什么要按 tool 评估，而不是只按 server 评估？
3. Artifact 为什么也要纳入数据和脱敏治理？

通过标准：你能为团队写出账号、workspace、browser、MCP、artifact、发布红线六类边界。

官方来源

• Google Antigravity Plans - 官方说明个人账号、团队 preview、quota 和当前不支持项。
• Google Antigravity Strict Mode - 官方说明 strict mode 对 terminal、browser、artifact review 和 file access 的强制收紧。
• Google Antigravity MCP Integration - 官方说明 MCP resources、tools、认证、支持 server 和 disabledTools。
• Google Antigravity Browser - 官方说明 separate browser profile 和 browser tools 设置。
• Google Antigravity Artifacts - 官方说明 artifacts 作为 agent 工作沟通和反馈机制。

接下来去哪