課堂
開始
開始學習
CodeGym /課程 /ChatGPT Apps /限制與政策：沙盒、權限、內容

限制與政策：沙盒、權限、內容

ChatGPT Apps
等級 1, 課堂 4
開放

1. 簡介

如果你是從傳統的 Next.js 世界進入 Apps SDK，腦中常會想著：「這就是一般的網路用戶端：我有 window、有 fetch，可以在頁面上貼上任何東西，並呼叫任何 API。」在 ChatGPT 的生態系中並非如此。

關鍵想法：你的小工具是 ChatGPT 的房客，而不是相反。平台要為數以億計的使用者負責，因此你所做的一切都被包裹在多層沙盒、政策與權限之中。對開發者來說，起初可能覺得束手束腳，但之後你會欣賞：有大片的安全與合規已替你先想好。

在本講裡，我們關注三個大塊：

  1. 小工具沙盒：前端執行環境的技術性限制。
  2. 權限模型：你的 App 宣告了什麼、ChatGPT 如何向使用者詢問，以及哪些動作被視為「風險較高」。
  3. 內容與資料政策：哪些主題、資料與行為模式被禁止或嚴格限制。

部分內容在 OpenAI 文檔中有正式描述，包含 App developer guidelines 與 security/privacy-guide。 但我們的目標不是重述法律條文，而是建立工程師的心智模型。

2. 小工具沙盒：圍繞你的 React 程式碼的玻璃盒

小工具作為 iframe 沙盒

從技術角度看，你的 Apps SDK 小工具是一個在 ChatGPT 專用沙盒中渲染的 React 元件。物理上它類似於具有「嚴格」 Content Security Policy 且縮減瀏覽器 API 的 iframe。

如果試著比較：

環境 你能控制什麼 主機控制什麼
一般的 Next.js 頁面、head、導覽、網路存取、storage 瀏覽器/作業系統（但你幾乎可以為所欲為）
ChatGPT App 小工具 只有自己小工具的 DOM 與對 window.openai 的互動 其餘全部：外部 UI、網路、CSP、生命週期

比喻：一般網站是你的公寓。小工具則是在大型共用辦公室裡的一個房間，有嚴格規則：不能敲牆、不能鑽天花板、也不能更換 Wi‑Fi 路由器。

DOM 與環境的限制

小工具的程式碼不能：

  • 修改 ChatGPT 的父層 DOM；
  • 存取 window.top 或 parent 並嘗試操控主機的介面；
  • 在自身容器之外注入全域事件監聽器；
  • 操控使用者的導覽超出 API 所允許的範圍，例如 openExternal。

事實上，你只能控制小工具容器內部所繪製的內容。 主機可在任何時刻調整大小、隱藏、重繪或卸載你的元件。

示意如下：

+-------------------------------------------+
|        ChatGPT UI（主機，你無權操作）     |
|  +-------------------------------------+  |
|  |   你的小工具（iframe 沙盒）         |  |
|  |  +-----------------------------+   |  |
|  |  |  你的 React/Next.js 程式碼  |   |  |
|  |  +-----------------------------+   |  |
|  +-------------------------------------+  |
+-------------------------------------------+

Content Security Policy 與受限的 Web‑API

沙盒施加了嚴格的 CSP：禁止 eval、任意的 inline 腳本，以及大多數經典的 XSS 招式。只有 ChatGPT 管理的、事先定義的指令碼與樣式來源被允許。

此外，許多敏感的瀏覽器 API 也被停用。例如：

  • window.alert、 prompt、 confirm 不可用；
  • 存取剪貼簿（navigator.clipboard） 可能被禁止，或只能透過特定途徑運作；
  • 無法存取檔案系統、瀏覽器的系統設定等。

平台的邏輯很簡單：ChatGPT 內的任何應用都不應該像「惡意網站」那樣行事，不該竊取焦點、刷視窗或混淆使用者。

網路存取限制

現在來到對網頁開發者最痛的部分：fetch。

預設情況下，小工具不能任意對網際網路上的 URL 發出請求。大致理念如下：

  • 小工具中的 React 程式碼不該變成萬用的 HTTP 用戶端，例如掃描使用者的內部網路，或拉取使用者從未同意互動之網站的資料；
  • 所有敏感操作應該經由你的 backend/MCP 伺服器來進行；它活在熟悉的「伺服器」世界中， 有日誌、驗證、rate limit 等等；
  • fetch() 會運作，但僅限於事先同意的網域清單。 如果列入太多不可信網域，你可能無法通過審查。
C++

官方指南中這樣描述：「Widgets run inside a sandboxed environment. External network access is restricted; use your MCP server for integrations」。

實務結論：重量級整合—只透過 MCP 工具。小工具是薄用戶端，而非巨石式應用。

資源限制：時間、記憶體、資料大小

由於 ChatGPT 是眾多應用共同的家，你的小工具不能無限制地：

  • 播放無止盡的動畫；
  • 在記憶體中保留巨大結構；
  • 一次渲染數 MB 的 DOM 與 JSON。

平台會限制：

  • 小工具的生命週期；
  • 每個實例的記憶體上限；
  • 你雙向傳遞的訊息/結構的最大尺寸。

精確數字會隨平台演進而變動，因此在架構層級你應遵循原則：「UI 要輕；所有重活在伺服器上」。

關於 window.openai 與 openExternal

在沙盒中你還有一個相當好用的工具— window.openai 以及其上的 Apps SDK 包裝。透過它你可以：

  • 取得小工具的輸入資料；
  • 觸發像 openExternal(url) 之類的動作，開啟使用者瀏覽器中的外部連結；
  • 與 ChatGPT 溝通（例如傳送事件，讓模型可用於後續追問）。

以下是類 TypeScript 的示意程式碼（我們暫時用「假」的，第三模組會拆解真正的 API 與基於 window.openai 的 Apps SDK hooks）： 

// 假例：我們的教學專案 GiftGenius
window.openai.openExternal("https://my-gift-store.example/checkout");

這裡再次重要的是：openExternal 不是「靜默」的重新導向。ChatGPT 會明確告知使用者即將開啟外部頁面。這是透明度政策的一部分：

  • 首先，使用者會看到對話視窗，告知小工具想在新視窗中開啟連結；
  • 連結必須屬於白名單中的網域之一。

3. 權限：從誠實描述到使用者的明確同意

若沙盒是「哪些絕對不行」，則權限就是「哪些可以，但需要授權」。

兩類權限：隱含與明確

問題：你的 App 哪些動作可在不額外彈窗的情況下執行，哪些需要使用者明確確認？

我們可粗分為兩級。

隱含（implicit）權限——由使用 App 本身即合乎直覺會允許的事。例如：

  • 讀取觸發 App 的使用者訊息文字；
  • 讀取模型傳給小工具或工具的參數；
  • 顯示 UI 元件並處理小工具內部的點擊。

明確（explicit）權限——會改變外部世界或碰觸個資的動作：

  • 存取使用者在外部服務的帳號（OAuth 登入、讀取其檔案、行事曆、訂單）；
  • 在外部系統中建立、修改或刪除實體（建立文件、下單、取消預訂）；
  • 涉及真金白銀的操作（購買、訂閱、轉帳）；
  • 存取 PII、醫療資料、財務資訊等使用者個人資料。

對於此類動作，平台要求明確授權與清楚易懂的描述。

工具描述與 securitySchemes

在 MCP 伺服器層級，你會註冊工具並同時描述其所需的安全機制。 來自 Apps/MCP SDK 官方文檔的範例可能如下： 

server.registerTool(
  "create_doc",
  {
    title: "Create Document",
    description: "Make a new doc in your account.",
    inputSchema: {
      type: "object",
      properties: { title: { type: "string" } },
      required: ["title"],
    },
    _meta: {
      securitySchemes: [
        { type: "oauth2", scopes: ["docs.write"] }
      ],
    },
  },
  async ({ input }) => {
    // ...
  }
);

這裡 securitySchemes 以宣告式的方式告訴 ChatGPT：「這個工具需要 OAuth2 授權，並具備這些 scope」。之後 ChatGPT 會處理登入 UI、權杖的保存與更新，而你在 MCP 端檢查權杖是否有效且具備所需權限。

核心原則：描述要誠實。如果你的工具實際能刪除檔案，但描述寫著「只讀取文件清單」，那在審查與上架商店時都會有麻煩。

Just‑in‑time 同意與使用者確認

當 ChatGPT 準備呼叫需要「有風險」動作的工具時，可能有兩種作法：

  • 明確詢問使用者：「應用 X 想要執行 Y。是否允許？」；
  • 若使用者已同意並選擇「永遠允許此 App」，則使用先前給出的授權。

這很像行動裝置的權限：相機、定位、推播通知。平台力求最小化彈窗數量，但嚴格遵守「所有敏感操作—必須有明顯同意」的政策。

從架構角度看：

  • 你描述工具能做什麼；
  • ChatGPT 決定在呼叫前插入多少 UX 摩擦；
  • 使用者擁有最終控制權。

開發模式與上架 Store 時的權限差異

在 Dev Mode 中，ChatGPT 仍會套用安全政策，但 UX 可能稍微「偏向開發者」。 然而到了你要上架 Store 的時候，就得通過完整的檢查清單：

  • 描述 App 收集哪些資料、如何儲存與使用（Privacy Policy）；
  • 明確列出所需權限；
  • 證明你沒有索取多餘的資料（「資料最小化」）。

如果你在點子階段就以「最小權限與誠實描述」的思維來做，後續會容易很多。

小情境：我們的教學範例 GiftGenius

我們延續虛構的 App「GiftGenius」——送禮助手。假設我們想加入一個工具，能在使用者的外部電商帳號中建立「願望清單」。

在 MCP 伺服器註冊的工具大致如下：

server.registerTool(
  "create_wishlist",
  {
    title: "Create wishlist",
    description: "Create a gift wishlist in the user's shop account.",
    inputSchema: {
      type: "object",
      properties: {
        title: { type: "string" },
        items: { type: "array", items: { type: "string" } },
      },
      required: ["title", "items"],
    },
   _meta: {
      securitySchemes: [
         { type: "oauth2", scopes: ["wishlist.write"] }
      ],
    },      
  },
  async ({ input, security }) => {
    // 這裡我們會檢查權杖，並在商店端建立清單
  }
);

如此一來，你從一開始就宣告：「此操作需要使用者帳號的存取權，且需具備 wishlist.write 權限」。 ChatGPT 會負責引導使用者登入並同意這些 scope。

4. 內容與資料政策：哪些可以、哪些不該

第三根支柱是內容。即使你沒有違反沙盒、也沒有索取多餘權限，如果你的 App 產生或鼓勵被禁止的內容，或不當處理敏感資料，仍可能被封鎖。

Usage policies：基本禁令

OpenAI 公布了 usage policies——使用規範，列舉了被禁止或嚴格限制的內容類別：從露骨暴力與仇恨，到煽動有害行為與製作惡意軟體。

對 ChatGPT Apps 而言，這意味著：

  • 你的 App 不該專門用於規避法律、製作惡意軟體、入侵他人帳號等；
  • 不得以 NSFW 內容作為 App 核心（至少在有專門的年齡限制與驗證機制之前；指南中把它視為未來方向）；
  • 你的 App 的描述、提示與 system‑prompt 不得鼓勵繞過 ChatGPT 的規則。

實務表述：使用者在一般聊天中或許能用「灰色」提示達成的事情，不該變成你的 App 正式宣示的功能。

符合 13+ 受眾要求

現行規則指出，Apps 應對廣泛受眾可接受，包含 13–17 歲的使用者；專門面向 13 歲以下兒童的應用被禁止。 18+ 內容被視為未來可能方向，會搭配獨立的年齡驗證。

這表示，即便你的 App「面向成年人」，也不應在沒有額外 UX 與年齡驗證（平台目前可能尚未提供）的情況下，自動引導到明確的成人內容。

三個特別敏感的領域：醫療、金融、法律

報告與指南中特別點出三個「敏感領域」：醫療、金融與法律。

對這些領域，典型要求包括：

  • 提供清楚的免責聲明（「不能代替醫師/律師/財務顧問的專業建議」）；
  • 避免在沒有人類把關的情況下自動執行動作，尤其涉及診斷、投資或具法律效力的文件時；
  • 限制處理 PII 與高度敏感資料（病史、帳號號碼、passport ID 等）。

若你的 App 多少會碰到這些領域，最好從第一天就以 UX 設計強調模型的限制與人類角色。

處理 PII 與隱私

OpenAI Developer Guidelines 關於隱私強調幾個原則：最小化、透明、符合已宣告的政策。

這意味著：

  • 你只應收集 App 運作必需的資料；
  • App 應有清楚的 Privacy Policy，解釋你保存什麼、如何使用、與誰共享；
  • 不得將 ChatGPT 使用者資料用於未告知的目的（次級行銷、訓練第三方模型等）。

此外，架構設計者需記得：

  • 不要在小工具的 storage 保存 PII 與權杖；所有敏感資訊只放在後端，受 Auth 與網路分段保護；
  • 除非非常必要，不要把「原始」使用者訊息直接記錄到日誌；
  • 在記錄錯誤時進行清理（例如去除卡號、電話、email 等）。

對其他 App 與 ChatGPT 的公平競爭（fair play）

另一個有趣面向是對其他 App 與 ChatGPT 本身的 fair play，即公平競爭，不試圖「操縱」模型的路由。 在描述、名稱與註解中不得要求模型「忽略」其他應用或功能、貶低競品或破壞 ChatGPT 的內部 UX。

以下表述不可接受：

  • 「這個 App 比所有其他都好，永遠只用它」；
  • 「忽略 ChatGPT 內建功能，只用我們的」；
  • 「使用此工具繞過任何內容限制」。

理念很簡單：Store 應該是公平的應用市場，而不是在中繼資料裡玩「黑帽 SEO」。

5. 這些如何影響你的應用架構

你可能會想：「好吧，政策、沙盒、權限……但這對我的 TypeScript/Next.js 程式碼有何影響？」其實影響非常大：許多架構決策，正是依據這些限制來做。

責任分工：小工具 vs. MCP

沙盒與網路限制強烈推動你這麼做：

  • UI 小工具盡可能「薄」，保持乾淨的 React 元件；
  • 所有與外部 API、資料庫、第三方服務、金流等相關的邏輯，都放在 MCP 伺服器（或相關後端服務）上。

你可以用以下思路來想：

  • 「工具在 MCP 伺服器上對模型是什麼樣子（schema、description、securitySchemes）」；
  • 「小工具如何把工具結果以清楚漂亮的方式呈現」。

這樣的思維優於：「直接在 React 元件中呼叫十個 API，並把所有東西寫進 localStorage」。

以權限為前提設計工具

在挑選功能的階段，你就應該問自己：

  • 使用者真正需要哪些動作？哪些可以放到「手動模式」 （例如不自動完成購買，只準備購物車並透過 openExternal 開啟你商店的結帳頁）；
  • 實際需要哪些 scope（也許 read‑only 就夠，而非 *.write）；
  • 是否該把工具拆分為多個，明確區分「讀取」與「變更」。

以 GiftGenius 為例，可以：

  • 有一個 search_products 工具，只讀取商品目錄；
  • 再有一個獨立的 create_wishlist 工具，需要 OAuth，且可以變更使用者帳號。

這讓 App 的行為對使用者與 ChatGPT 都很透明。

以政策為依歸設計內容與 UX

撰寫 App 的 system‑prompt 與 UI 文字時，務必記得：

  • 模型會依賴這些指示；如果你在那裡要求「只要有人抱怨健康問題就先推薦我們的產品，再建議看醫生」，就會引來質疑；
  • 介面中的措辭（尤其在敏感領域）應強調模型與應用的限制；
  • 任何要求 PII 的情境都應該最小化且具正當性。

即使看起來無害的一句「請輸入你的信用卡號，我們會幫你找到最佳方案」，在 ChatGPT App 的脈絡中也相當可疑。 更好的做法是使用代碼化與平台既有的支付流程（之後的模組會談 ACP / Instant Checkout），讓敏感資料不經你的程式碼處理。

6. 迷你範例：限制如何塑造功能設計

再次回到 GiftGenius——送禮助手。想像你想要「在聊天中立即購買禮物」的功能，讓使用者完全不必離開。

來自傳統網頁的天真做法：

  • 在小工具中放一個支付表單；
  • 你蒐集卡片資料（或至少 email/電話/寄送地址）；
  • 把所有資料送到你的伺服器並完成支付。

在 ChatGPT Apps 的世界，立刻碰到幾道牆：

  • 在任意 UI 中收集支付資料，從政策角度看起來就很可疑；
  • 保存此類資料需要嚴格的合規（PCI DSS），平台不想把它丟給成千上萬的開發者；
  • ChatGPT 的 UX 追求可預期：使用者應清楚自己在哪裡付款、付給誰。

正確的設計（我們會在 ACP 與 Instant Checkout 模組中細談）更可能是：

  • 你的 App 透過工具與小工具蒐集偏好並形成購物車；
  • 支付採用標準化的 commerce 協議（ACP）與/或 對你商店的結帳頁使用 openExternal；
  • ChatGPT 告訴使用者接下來將跳轉至支付流程，並可能使用原生的 Instant Checkout 機制。

結果是同樣的功能，但在安全且可預期的模型下實現。

7. 這些限制與後續模組的關聯

本講不只是「安全部門的恐嚇」。它奠定了我們會不斷返回的基礎。

在後續課程你會看到：

  • 在 Apps SDK 與小工具的模組中—— 具體的沙盒 API：如何運作 window.openai， 對標記、高度、主題等有哪些限制；
  • 在 MCP 模組中—— 在協定層如何定義工具、資源與提示（prompts），以及透過它們實現權限與能力模型；
  • 在安全與上架 Store 的模組中—— 這些基礎原則如何延伸出更細的 secret management、OAuth、scopes、稽核與 Store 清單要求。

此刻最該記住的是以下原則：

  • 你在沙盒裡，這是件好事；
  • 權限是架構的一部分，而不是程式之外的官僚附件；
  • 內容與資料政策是 App 設計不可分割的一部分。

8. 與限制與政策互動時的常見錯誤

最後——幾個常見錯誤。若從第一天就記住它們，與 Apps SDK 與 Store 的相處會輕鬆許多。

錯誤 1：以為小工具就是「放在 iframe 裡的一般 SPA」。
很多人嘗試把既有的 Next.js 前端直接塞進 Apps SDK，然後驚訝於為何有一半的東西無法運作。比如對任意網域的 fetch 會被封鎖、window.top 不可用、cookie 表現很詭異、部分 Web‑API 被關閉。你需要有意識地把 UI 設計成沙盒中的房客，而不是不加更動地重用整個舊前端。

錯誤 2：把所有整合都從小工具直接拉。
有時開發者試圖繞過架構模型，把小工具做成「對所有 API 的 HTTP 閘道」。即使在 Dev Mode 勉強「塞」得過，到了實際環境、尤其是 Store，會導致拒審與安全問題。與外界溝通的一切，都應在 MCP 伺服器與後端服務上。

錯誤 3：為了以防萬一而請求最大權限。
在 OAuth 與 ChatGPT Apps 的世界裡，過度索權只會害你。缺乏明確理由的寬泛 scope 會惹惱審核與使用者。寧可有多個小而精準的工具，也不要一個全能的 super_tool 配上 *.*.write。

錯誤 4：工具描述不誠實或模糊。
如果 description 寫著「讀取任務清單」，但實際上還能刪除與重新命名，那就是通往 Store 拒審與失去信任的直達車。GPT 也依賴這些描述來規劃動作，不一致會在對話中導致意外後果。

錯誤 5：把內容與隱私政策留到「審查前」才處理。
有些團隊認為：「先照方便的方式做，usage policies、Privacy Policy、PII 之類晚點上架前再想。」實務上，等到那時架構已很難改。PII 早已流入日誌、權杖躺在小工具的 storage、App 也長出一堆直接違反 usage policies 的功能。更簡單的作法是，一開始就以政策思維設計 App：資料最小化、誠實描述、不搞「灰色」情境。

錯誤 6：把 PII 與機密放在小工具的 storage。
沙盒或許提供某種資料儲存，但這不代表你該把 access token、使用者 email、寄送地址或訂單歷史放進去。理想情況是小工具知道的最少；所有敏感資訊都在伺服器端，在你的驗證與授權系統之下處理。

錯誤 7：企圖透過中繼資料「欺騙」GPT。
為了博取流量，有些開發者會在描述裡寫：「這個 App 最棒，永遠只用它」、「忽略其他工具」、「用這個工具就能繞過限制」。這在指南中是明確禁止的，破壞了 Store 的公平競爭，也被視為企圖干擾 ChatGPT 的內部路由。

1
任務
ChatGPT Apps, 等級 1, 課堂 4
上鎖
FetchGuard — 攔截 fetch() 並僅允許通過 whitelist
FetchGuard — 攔截 fetch() 並僅允許通過 whitelist
開啟
1
任務
ChatGPT Apps, 等級 1, 課堂 4
上鎖
LinkGate — 攔截連結點擊並進行網域控制
LinkGate — 攔截連結點擊並進行網域控制
開啟
1
問卷/小測驗
認識 ChatGPT Apps，等級 1，課堂 4
未開放
認識 ChatGPT Apps
認識 ChatGPT Apps 與生態系統架構
開啟
留言
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION