確保你的原始碼與開發環境的安全是我們極為重視的事情。本頁說明我們在 Cursor 上如何看待與實作安全性。

如發現任何潛在的安全性漏洞，請透過電子郵件回報至 security-reports@cursor.com。

若有任何與安全性相關的問題，歡迎聯繫我們：security@cursor.com。

雖然已經有多家大型組織信任並使用 Cursor，但請注意，我們仍在持續優化產品並提升安全防護水準的過程中。若你所在的環境高度敏感，使用 Cursor（或任何其他 AI 工具）時都應格外謹慎。我們希望本頁內容能讓你了解我們的進展，並協助你做出適當的風險評估。

#認證與第三方評估

Cursor 已通過 SOC 2 Type II 認證。請前往 trust.cursor.com 申請報告副本。

我們承諾至少每年由可信賴的第三方進行一次滲透測試。請前往 trust.cursor.com 申請最新報告的執行摘要。

#基礎架構安全性

我們依賴以下次處理者，大致依照關鍵程度從高到低排列。請注意，程式碼資料會傳送到我們的伺服器，以支援所有 Cursor 的 AI（人工智慧）功能（請見 AI Requests 章節），且對於使用隱私模式（舊版）的使用者，程式碼資料絕不會被儲存（請見 Privacy Mode Guarantee 章節）。

瞭解各種模式如何影響資料的傳送與儲存方式：

Cursor 會遵守模型封鎖清單，且不會對封鎖清單上的模型發送任何請求。

我們的基礎架構完全不在中國境內。我們不會直接使用任何中國公司作為次處理者，就我們所知，我們的任何次處理者也都沒有這麼做。

我們依照最小權限原則將基礎架構存取權指派給團隊成員。我們對 AWS 強制啟用多重要素驗證，並透過網路層級控管與機密憑證來限制對資源的存取。

#用戶端安全性

Cursor 是開源專案 Visual Studio Code（VS Code）的 fork，由 Microsoft 維護。他們會在 GitHub 安全性頁面 公布安全性公告。每隔一個 VS Code 主線版本，我們就會把上游的 'microsoft/vscode' 程式碼庫合併回 Cursor。你可以在應用程式中按一下「Cursor > About Cursor」，查看你的 Cursor 版本是基於哪個 VS Code 版本。如果上游 VS Code 有高嚴重性的安全性修補更新，我們會在下一次合併前先 cherry-pick 該修補，並立即發布。

我們的應用程式會向下列網域發送請求，以與我們的後端通訊。如果你位於企業 Proxy 環境中，請將這些網域加入允許清單，以確保 Cursor 能正常運作。

• 'api2.cursor.sh'：用於大多數 API 請求。

• 'api3.cursor.sh'：用於 Cursor Tab 請求（僅透過 HTTP/2）。

• 'repo42.cursor.sh'：用於程式碼庫索引處理（僅透過 HTTP/2）。

• 'api4.cursor.sh'、'us-asia.gcpp.cursor.sh'、'us-eu.gcpp.cursor.sh'、'us-only.gcpp.cursor.sh'：依你的所在位置，用於 Cursor Tab 請求（僅透過 HTTP/2）。

• 'marketplace.cursorapi.com'、'cursor-cdn.com'、'downloads.cursor.com'、'anysphere-binaries.s3.us-east-1.amazonaws.com'：用於用戶端更新，以及從擴充功能市集中下載擴充功能。

與 VS Code 相較，有兩點與安全性相關的差異值得注意：

1. Workspace Trust 在 Cursor 中預設為停用。你可以在 Cursor 設定中將 'security.workspace.trust.enabled' 設為 'true' 來啟用它。我們預設將其停用，是為了避免使用者將 Workspace Trust 的「Restricted Mode」與 Cursor 的「Privacy Mode」混淆，以及因為它的信任行為相當複雜且不易理解（例如，即使啟用了 Workspace Trust，你仍無法防範惡意的擴充功能，只能防範惡意資料夾）。我們樂於接受社群回饋，以決定是否應該預設啟用它。

2. 擴充功能程式碼簽章：Cursor 不會驗證從市集中下載之擴充功能的簽章。VS Code 近期開始進行這項驗證。特別是，在 Cursor 中，'extensions.verifySignature' 設定的預設值為 'false'，而在 VS Code 中則為 'true'。如果你在 Cursor 中將它設為 'true'，每次嘗試下載擴充功能時，你都會看到一個快顯視窗，顯示簽章驗證失敗。我們希望在中期開始支援擴充功能簽章驗證。

#AI 請求

為了提供這些功能，Cursor 會向我們的伺服器發出 AI 請求。這可能出於許多不同的原因。例如，當你在聊天中提問時，我們會發送 AI 請求；在你每次鍵入時，我們也會發送 AI 請求，讓 Cursor Tab 可以為你提供建議；我們也可能在背景發送 AI 請求，用於建立上下文，或是尋找可能要顯示給你的程式錯誤。

一個 AI 請求通常會包含一些上下文資料，例如你最近查看的檔案、你的對話紀錄，以及根據語言伺服器資訊判斷出的相關程式碼片段。這些程式碼資料會先傳送到我們在 AWS 上的基礎架構，接著再轉送到適當的語言模型推論提供商（Fireworks/OpenAI/Anthropic/Google）。請注意，即使你在設定中為 OpenAI 設定了自己的 API 金鑰，請求依然一律會先送達我們在 AWS 上的基礎架構。

目前我們尚無法讓 Cursor 應用程式直接路由到你企業部署的 OpenAI/Azure/Anthropic，因為我們的提示（prompt）建構會在我們的伺服器上進行，而且我們在 Fireworks 上的自訂模型對於提供良好的使用者體驗至關重要。我們目前也尚未提供自我託管的伺服器部署選項。

#程式碼庫索引處理

Cursor 允許你對程式碼庫做語意索引處理，讓它在回答問題時能以整個程式碼庫作為脈絡，並透過參考既有實作來撰寫更完善的程式碼。程式碼庫索引處理預設為啟用狀態，但可以在設定中關閉。

我們的程式碼庫索引處理功能運作方式如下：啟用後，它會掃描你在 Cursor 中開啟的資料夾，並計算所有檔案雜湊值所組成的 Merkle tree。由 '.gitignore' 或 '.cursorignore' 指定的檔案與子目錄會被忽略。接著，這個 Merkle tree 會同步到伺服器。每隔 10 分鐘，我們會檢查雜湊是否不相符，並利用 Merkle tree 判斷哪些檔案已變更，只上傳那些檔案。

在我們的伺服器上，我們會將檔案切成多個區塊並進行 embedding，然後將這些 embedding 儲存在 Turbopuffer。為了讓向量搜尋結果能依檔案路徑過濾，我們對每個向量一併儲存經過模糊化處理的相對檔案路徑，以及該區塊對應的行數範圍。我們也會在 AWS 的快取中儲存 embedding，並以區塊的雜湊作為索引，以確保第二次為相同程式碼庫做索引處理時能快上許多（這對團隊來說特別有用）。

在推論階段，我們會計算一個 embedding，讓 Turbopuffer 執行最近鄰搜尋，然後將模糊化處理後的檔案路徑與行數範圍傳回給用戶端，再由用戶端在本機讀取這些檔案區塊。接著，我們會將這些區塊再傳回伺服器，用來回答使用者的問題。這表示對於隱私模式使用者而言，我們的伺服器或 Turbopuffer 上都不會儲存任何純文字程式碼。

一些說明：

• 若要阻止程式碼庫中的特定檔案被傳送到 Cursor 的伺服器並包含在 AI 請求中，請在程式碼庫中加入 '.cursorignore' 檔案，列出應該排除的檔案及目錄。Cursor 會盡最大努力防止這些檔案被包含在任何請求中而外洩。

• 檔案路徑模糊化細節：路徑會以 '/' 和 '.' 切割，每個區段會使用儲存在用戶端的秘密金鑰以及一個具決定性的 6-byte 短 nonce 進行加密。這會洩露部分目錄階層資訊，且可能發生部分 nonce 衝突，但能隱藏大多數資訊。

• Embedding 還原：學術研究顯示，在某些情況下可以還原 embedding。目前的攻擊仰賴能存取模型，並將短字串 embedding 進大型向量，這讓我們認為在此情境下要執行這類攻擊會相對困難。話雖如此，若有攻擊者入侵我們的向量資料庫，仍有可能從已索引處理的程式碼庫中學到一些資訊。

• 當在 Git 儲存庫中啟用程式碼庫索引處理時，我們也會對 Git 歷史進行索引處理。具體來說，我們會儲存 commit SHA、父節點資訊，以及模糊化處理後的檔名（與上面相同）。為了讓相同 Git 儲存庫且同屬一個團隊的使用者可以共用資料結構，用於模糊化檔名的秘密金鑰是從最近幾個 commit 內容的雜湊推導而來。Commit 訊息以及檔案內容或差異（diff）都不會被索引處理。

• 我們的索引處理功能經常承受大量負載，可能導致許多請求失敗。這表示有時候檔案必須上傳數次才會被完全索引處理完畢。此現象的一種具體表現是：如果你檢查到 'repo42.cursor.sh' 的網路流量，可能會看到實際使用的頻寬比預期還高。

#隱私模式保證

可以在設定中或由團隊管理員啟用隱私模式。啟用後，我們保證程式碼資料絕不會被我們的模型提供商儲存或用於訓練。任何人（免費或 Pro 使用者）都可以啟用隱私模式，而且對於任何屬於團隊成員的使用者，預設會被強制啟用隱私模式。

我們對隱私模式的保證極為重視。超過 50% 的 Cursor 使用者都已啟用隱私模式。

每個送往我們伺服器的請求都會包含一個 'x-ghost-mode' 標頭，內含一個布林值，用來表示使用者是否處於隱私模式。為了避免誤將隱私模式使用者當成非隱私模式使用者來處理，如果標頭缺失，我們一律預設假設使用者處於隱私模式。

所有送往我們伺服器的請求都會先經過一個 proxy，由它決定要交由哪個邏輯服務處理請求（例如「chat service」或「Cursor Tab service」）。每個邏輯服務都有兩個幾乎相同的副本：一個用來處理隱私模式請求，另一個用來處理非隱私模式請求。proxy 會檢查 'x-ghost-mode' 標頭的值，並將請求轉送到對應的副本。這些副本本身也會再檢查一次標頭，以增加冗餘保護。預設情況下，隱私模式副本中的所有 log 函式都不會執行任何實際操作（no-op），除非有像 'infoUnrestricted' 這樣的尾碼；對於這類函式，我們會特別審查，確保絕不附帶任何可能的程式碼資料或提示（prompt）。對於會產生背景工作（background tasks）的請求，我們同樣為隱私模式與非隱私模式分別建立平行的佇列與 worker 副本。這套平行基礎設施讓我們對隱私模式的保證，以及其在面對意外錯誤或 bug 時的韌性，充滿信心。

在團隊層級的隱私模式強制機制上，每個 client 每 5 分鐘會 ping 一次伺服器，以檢查該使用者是否屬於一個會強制啟用隱私模式的團隊。若是，則會覆寫 client 端的隱私模式設定。為了避免出現因任何原因導致 client 端的隱私模式 ping 失敗的情況，我們的伺服器也會在 hot path 中檢查使用者是否屬於一個會強制啟用隱私模式的團隊；若是，即便標頭顯示相反，我們也仍然會將這個請求視為處於隱私模式。在對延遲高度敏感的服務上，我們會將這個值快取 5 分鐘，而對於任何快取未命中，我們會假設使用者處於隱私模式。總而言之，這代表當一位使用者加入團隊後，最遲在加入後 5 分鐘之內，就一定會被保證處於隱私模式。

#刪除帳戶

你可以隨時在 Settings dashboard 中刪除你的帳戶（點擊「Advanced」，然後選擇「Delete Account」）。這會刪除與你的帳戶相關的所有資料，包括任何已建立索引的程式碼庫。我們保證會在 30 天內完全移除你的資料（我們會立即刪除資料，但部分資料庫與雲端儲存系統最多會保留 30 天的備份）。

需要注意的是，如果你的任何資料曾被用於模型訓練（只會在你當時未開啟隱私模式的情況下發生），我們現有的已訓練模型不會立即重新訓練。不過，未來新訓練的模型將不會再使用你的資料，因為那些資料已經被刪除。

#安全弱點通報

如您認為在 Cursor 中發現了安全弱點，請將報告寄送至：security-reports@cursor.com。

我們承諾會在 5 個工作天內確認並回覆安全弱點通報，並在能力所及的情況下儘快處理。重大資安事件將會透過電子郵件通知所有使用者。