---
title: "11 · 團隊使用的安全邊界"
description: "Antigravity 團隊使用前的治理邊界：賬號、workspace、許可權、MCP、瀏覽器、Artifacts、資料、稽核和釋出流程。"
verifiedAt: "2026-05-07"
---

個人試用 Antigravity 和團隊使用 Antigravity 是兩件事。團隊場景裡，問題不是“誰會用”，而是 agent 能訪問什麼、誰批准什麼、artifact 儲存什麼、MCP 能呼叫什麼、哪些動作絕不自動執行。

官方 Plans 文件說明，Antigravity 當前面向個人賬號可用，團隊場景仍屬於 pre-general availability preview。也就是說，團隊上線前必須先確認賬號、條款、資料邊界和內部安全策略，而不是照搬個人試用設定。

> [!NOTE]
> **團隊預設值**：workspace-only（僅 workspace 內訪問）、Request Review（請求人工審閱）、artifact review required（artifact 必審）、browser allowlist（瀏覽器白名單）、MCP 最小開放、禁止自動部署和賬號後臺提交。

> [!TIP]
> **閱讀目標**：讀完本章，你應該能給團隊寫一份 Antigravity 使用邊界，而不是隻給成員一句“謹慎使用”。

## 1. 團隊治理圖

```mermaid
flowchart TD
    Team["團隊使用 Antigravity"] --> Account["賬號與條款"]
    Team --> Workspace["Workspace 邊界"]
    Team --> Permission["許可權策略"]
    Team --> Browser["瀏覽器策略"]
    Team --> MCP["MCP 策略"]
    Team --> Artifact["Artifact 留存"]
    Team --> Release["釋出與提交"]
```

團隊治理要先確定責任邊界：

| 邊界 | 負責人 |
| --- | --- |
| 賬號和條款 | 團隊負責人 / 法務 / IT |
| Workspace 和儲存庫規則 | Tech Lead |
| Browser / MCP / terminal 許可權 | Tech Lead + 安全負責人 |
| Artifact 留存和脫敏 | 專案負責人 |
| 釋出和生產操作 | Release owner |

不要讓每個開發者自己決定這些事。個人偏好不能替代團隊安全策略。

## 2. 賬號與資料

先確認：

- 使用個人 Gmail 還是企業賬號。
- 是否允許程式碼和上下文進入對應產品。
- 是否允許 browser agent 訪問內部系統。
- 是否允許 artifact 儲存截圖、錄屏和 diff。
- 是否有客戶資料、金鑰或隱私資料限制。

這些問題要先由團隊定規則，不要讓每個開發者自己猜。

建議形成一份簡短准入說明：

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

## 3. Workspace 邊界

團隊專案建議：

1. 一個 workspace 對應一個專案或一個清晰模組。
2. 禁止 workspace 指向使用者家目錄。
3. 禁止把憑據目錄納入 workspace。
4. `.env`、金鑰、私有匯出檔案要進 ignore 或規則禁止讀取。
5. 大任務拆成單模組 conversation。

Workspace 不要只是“開啟儲存庫根目錄”。還要檢查：

| 項 | 團隊標準 |
| --- | --- |
| `.gitignore` | 包含 `.env`、本地輸出、快取、私有匯出 |
| `.agents/rules/` | 寫入專案邊界和驗收要求 |
| `.agents/skills/` | 只放經過審查的專案 skill |
| MCP 配置 | 不進儲存庫，或只進無金鑰模板 |
| 大任務 | 按模組或檔案批次拆 conversation |

## 4. 許可權預設值

| 項 | 團隊預設 |
| --- | --- |
| Terminal command | Request Review |
| Artifact review | Asks for Review |
| JavaScript execution | Request Review |
| File access | Workspace only |
| Non-workspace access | 停用 |
| Browser URL allowlist | 白名單 |
| MCP write tools | Ask |
| Deploy / git push | 人工執行 |

真實專案建議開啟 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 上線表可以這樣寫：

| Server | 只讀資源 | 寫 tool | 預設策略 | 適用 workspace |
| --- | --- | --- | --- | --- |
| GitHub | issue / PR / code search | create / comment / merge | 寫操作 Ask | 當前儲存庫 |
| Stripe | payment / customer 資料 | refund / create link | 預設 Deny | 僅財務流程 |
| Notion | 文件搜尋 | 寫頁面 | 寫操作 Ask | 文件專案 |
| Database | schema / logs | mutation / migration | 寫操作 Deny | 開發環境 |

## 6. Browser 策略

瀏覽器 agent 不應該預設訪問：

- 郵箱
- 雲盤
- 付款後臺
- 廣告後臺
- 生產管理後臺
- 客戶資料頁面

如果確實要讓它做後臺只讀檢查，寫清：

1. URL 範圍。
2. 只讀目標。
3. 不允許點選提交、刪除、授權、付款。
4. 必須截圖脫敏。

官方 Browser 文件說明 Antigravity 使用 separate browser profile，預設沒有日常 Chrome 登入態。這是安全邊界，不要為了方便把真實賬號登入進去再讓 agent 自由點選。

團隊 browser rule 可以寫：

```text
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. 團隊落地流程

建議按四步落地：

```mermaid
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：

```markdown
# 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](https://antigravity.google/docs/plans) - 官方說明個人賬號、團隊 preview、quota 和當前不支援項。
- [Google Antigravity Strict Mode](https://antigravity.google/docs/strict-mode) - 官方說明 strict mode 對 terminal、browser、artifact review 和 file access 的強制收緊。
- [Google Antigravity MCP Integration](https://antigravity.google/docs/mcp) - 官方說明 MCP resources、tools、認證、支援 server 和 `disabledTools`。
- [Google Antigravity Browser](https://antigravity.google/docs/browser) - 官方說明 separate browser profile 和 browser tools 設定。
- [Google Antigravity Artifacts](https://antigravity.google/docs/artifacts) - 官方說明 artifacts 作為 agent 工作溝通和反饋機制。

## 接下來去哪

<Cards>
  <Card title="最佳實踐清單" description="用一張 checklist 收尾，確認 Antigravity 是否達到可上線使用狀態。" href="/zh-Hant/docs/antigravity/understanding/12-best-practices-checklist" />
  <Card title="MCP 與許可權查詢" description="查許可權資源、file access、browser allowlist 和 MCP 的官方說明。" href="/zh-Hant/docs/antigravity/official/05-mcp-permissions-security" />
</Cards>
