11 · 團隊使用的安全邊界
Antigravity 團隊使用前的治理邊界：賬號、workspace、許可權、MCP、瀏覽器、Artifacts、資料、稽核和釋出流程。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 團隊邊界 | team scope | 多人用 agent 的安全邊界。 |
| 集中治理 | governance | 統一許可權和審批。 |
| 審計 | audit | 操作可追溯。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你給團隊用 Antigravity 劃好安全邊界和治理規則。
你是 Antigravity 團隊安全顧問。
【角色】
Antigravity 團隊安全顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。
【輸入】
- 團隊規模和角色：___
- 合規要求：___
- 最擔心的風險：___
- 敏感系統範圍：___
- 經驗水平：___
【工作流程】
1. 梳理團隊安全邊界
2. 設計集中治理和審批
3. 限定許可權和敏感區
4. 說明審計怎麼做
5. 給落地順序
【輸出規範】
▌一、安全邊界
▌二、集中治理
▌三、許可權 / 敏感區
▌四、審計 + 落地
【硬約束】
- 敏感系統嚴格控許可權
- 操作可審計追溯
- 策略變更留痕
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述個人試用 Antigravity 和團隊使用 Antigravity 是兩件事。團隊場景裡，問題不是“誰會用”，而是 agent 能訪問什麼、誰批准什麼、artifact 儲存什麼、MCP 能呼叫什麼、哪些動作絕不自動執行。
官方 Plans 文件說明，Antigravity 目前面向個人賬號可用，團隊場景仍屬於 pre-general availability preview。也就是說，團隊上線前必須先確認賬號、條款、資料邊界和內部安全策略，而不是照搬個人試用設定。
團隊預設值：workspace-only（僅 workspace 內訪問）、Request Review（請求人工審閱）、artifact review required（artifact 必審）、browser allowlist（瀏覽器白名單）、MCP 最小開放、禁止自動部署和賬號後臺提交。
閱讀目標：讀完本章，你應該能給團隊寫一份 Antigravity 使用邊界，而不是隻給成員一句“謹慎使用”。
1. 團隊治理圖
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。
- 是否有客戶資料、金鑰或隱私資料限制。
這些問題要先由團隊定規則，不要讓每個開發者自己猜。
建議形成一份簡短准入說明：
本團隊允許 Antigravity 訪問：目前專案 workspace、公開官方文件、localhost 頁面。
本團隊禁止 Antigravity 訪問：生產資料庫、金鑰目錄、客戶資料後臺、個人郵箱、支付和廣告後臺。
釋出、付款、刪除、遷移、授權類動作必須人工執行。3. Workspace 邊界
團隊專案建議：
- 一個 workspace 對應一個專案或一個清晰模組。
- 禁止 workspace 指向使用者家目錄。
- 禁止把憑據目錄納入 workspace。
.env、金鑰、私有匯出檔案要進 ignore 或規則禁止讀取。- 大任務拆成單模組 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 不應該預設訪問：
- 郵箱
- 雲盤
- 付款後臺
- 廣告後臺
- 生產管理後臺
- 客戶資料頁面
如果確實要讓它做後臺只讀檢查，寫清：
- URL 範圍。
- 只讀目標。
- 不允許點選提交、刪除、授權、付款。
- 必須截圖脫敏。
官方 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 個問題檢查自己是否真正理解：
- 團隊使用為什麼不能照搬個人試用設定？
- MCP 為什麼要按 tool 評估，而不是隻按 server 評估？
- 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 工作溝通和反饋機制。