Cursor 已通過 SOC 2 Type II 認證。請訪問 以請求報告副本。

我們承諾至少每年委托信譽良好的第三方進行滲透測試。請訪問 以請求最新報告的執(zhí)行摘要。

我們依賴以下子處理器，大致按從最關鍵到最不關鍵的順序排列。請注意，代碼數據會被發(fā)送到我們的服務器，以支持 Cursor 的所有 AI 功能（請參閱 ），并且隱私模式用戶的代碼數據永遠不會被持久化（請參閱 部分）。

我們的基礎設施均不在中國。我們不直接使用任何中國公司作為子處理器，據我們所知，我們的子處理器也沒有這樣做。

我們以最小權限原則向團隊成員分配基礎設施訪問權限。我們對 AWS 強制執(zhí)行多因素身份驗證。我們使用網絡級控制和密鑰來限制對資源的訪問。

Cursor 是開源 (VS Code) 的一個分支，由 Microsoft 維護。他們在 上發(fā)布安全公告。每隔一個 VS Code 主線版本，我們都會將上游 代碼庫合并到 Cursor 中。您可以通過點擊應用中的“Cursor > 關于 Cursor”來查看您的 Cursor 版本基于哪個 VS Code 版本。如果上游 VS Code 中存在高危安全相關補丁，我們將在下次合并之前 cherry-pick 該修復程序并立即發(fā)布。

我們的應用將向以下域發(fā)出請求，以與我們的后端通信。如果您位于企業(yè)代理之后，請將這些域列入白名單，以確保 Cursor 正常工作。

• ：用于大多數 API 請求。

• ：用于 Cursor Tab 請求（僅限 HTTP/2）。

• ：用于代碼庫索引（僅限 HTTP/2）。

• , , , ：根據您的位置用于 Cursor Tab 請求（僅限 HTTP/2）。

• , ：用于從擴展市場下載擴展。

需要注意的與 VS Code 相關的兩個安全差異

1. 在 Cursor 中默認禁用。您可以通過在 Cursor 設置中將 設置為 來啟用它。默認情況下禁用它是為了防止工作區(qū)信任的“受限模式”與 Cursor 的“隱私模式”之間產生混淆，并且因為其信任屬性細致入微且難以理解（例如，即使啟用了工作區(qū)信任，您也無法免受惡意擴展的侵害，只能免受惡意文件夾的侵害）。我們樂于聽取社區(qū)關于是否應默認啟用它的反饋。

2. 擴展代碼簽名：Cursor 不驗證從市場下載的擴展的簽名。VS Code 最近開始這樣做。特別是， 設置在 Cursor 中默認為 ，但在 VS Code 中默認為 。如果您在 Cursor 中將其設置為 ，則每次嘗試下載擴展時，都會看到一個彈出窗口，提示簽名驗證失敗。我們希望在中期未來開始支持擴展簽名驗證。

為了提供其功能，Cursor 會向我們的服務器發(fā)出 AI 請求。這種情況發(fā)生在許多不同的原因下。例如，當您在聊天中提出問題時，我們會發(fā)送 AI 請求；我們在每次擊鍵時都會發(fā)送 AI 請求，以便 Cursor Tab 可以為您提供建議；我們還可能在后臺發(fā)送 AI 請求，以構建上下文或查找要向您顯示的錯誤。

AI 請求通常包括上下文，例如您最近查看的文件、您的對話歷史記錄以及基于語言服務器信息的代碼片段。此代碼數據被發(fā)送到我們在 AWS 上的基礎設施，然后發(fā)送到相應的語言模型推理提供商（Fireworks/OpenAI/Anthropic/Google）。請注意，即使您在設置中為 OpenAI 配置了自己的 API 密鑰，請求也始終會訪問我們在 AWS 上的基礎設施。

我們目前無法從 Cursor 應用直接路由到您的企業(yè)部署的 OpenAI/Azure/Anthropic，因為我們的提示構建發(fā)生在我們的服務器上，并且我們在 Fireworks 上的自定義模型對于提供良好的用戶體驗至關重要。我們尚無自托管服務器部署選項。

您擁有 Cursor 生成的所有代碼的所有權。

Cursor 允許您對代碼庫進行語義索引，這使其能夠回答與您的所有代碼相關的問題，并通過引用現有實現來編寫更好的代碼。代碼庫索引默認啟用，但可以在入職培訓期間或在設置中關閉。

我們的代碼庫索引功能的工作原理如下：啟用后，它會掃描您在 Cursor 中打開的文件夾，并計算所有文件的 Merkle 樹哈希值。由 或 指定的文件和子目錄將被忽略。然后，Merkle 樹將同步到服務器。每 10 分鐘，我們會檢查哈希值是否不匹配，并使用 Merkle 樹來確定哪些文件已更改，并僅上傳這些文件。

在我們的服務器上，我們會對文件進行分塊和嵌入，并將嵌入存儲在 中。為了允許按文件路徑過濾向量搜索結果，我們?yōu)槊總€向量存儲一個混淆的相對文件路徑，以及塊對應的行范圍。我們還將嵌入存儲在 AWS 的緩存中，按塊的哈希值索引，以確保第二次索引相同的代碼庫會更快得多（這對于團隊尤其有用）。

在推理時，我們計算一個嵌入，讓 Turbopuffer 執(zhí)行最近鄰搜索，將混淆的文件路徑和行范圍發(fā)送回客戶端，并在客戶端本地讀取這些文件塊。然后，我們將這些塊發(fā)送回服務器以回答用戶的問題。這意味著我們的服務器或 Turbopuffer 上不存儲任何明文代碼。

一些注意事項

• 雖然 文件可以阻止文件被索引，但這些文件仍可能包含在 AI 請求中，例如，如果您最近查看了一個文件，然后在聊天中提出了問題。我們正在考慮添加一個 文件，以解決希望阻止文件在任何請求中上傳的用例 — 如果您對這個功能感興趣，請在論壇上發(fā)帖或通過 聯系我們。

• 文件路徑混淆詳細信息：路徑按 和 分割，每個段都使用存儲在客戶端的密鑰和確定性的短 6 字節(jié) nonce 進行加密。這會泄露有關目錄層次結構的信息，并且會發(fā)生一些 nonce 沖突，但會隱藏大多數信息。

• 嵌入逆向：學術研究表明，在某些情況下可以逆向嵌入。當前的攻擊依賴于訪問模型并將短字符串嵌入到大向量中，這使我們相信這里的攻擊會有些困難。也就是說，闖入我們向量數據庫的攻擊者絕對有可能了解有關索引代碼庫的信息。

• 當在 Git 倉庫中啟用代碼庫索引時，我們還會索引 Git 歷史記錄。具體來說，我們存儲提交 SHA、父信息和混淆的文件名（與上面相同）。為了允許在同一 Git 倉庫和同一團隊中的用戶共享數據結構，用于混淆文件名的密鑰是從最近提交內容的哈希值派生的。提交消息和文件內容或差異未被索引。

• 我們的索引功能經常遇到高負載，這可能會導致許多請求失敗。這意味著有時，文件需要上傳多次才能被完全索引。這種情況的一種表現是，如果您檢查到 的網絡流量，您可能會看到使用的帶寬超出預期。

隱私模式可以在入職培訓期間或在設置中啟用。啟用后，我們保證代碼數據不會以明文形式存儲在我們的服務器或我們的子處理器處。隱私模式可以由任何人（免費或 Pro 用戶）啟用，并且對于任何團隊成員的用戶，默認強制啟用隱私模式。

我們非常重視隱私模式保證。大約 50% 的 Cursor 用戶啟用了隱私模式。您可以在我們的 中閱讀有關隱私保證的更多信息。

啟用隱私模式后，代碼數據不會持久化在我們的服務器或任何子處理器處。代碼數據在請求的生命周期內仍然對我們服務器的內存可見，并且可能會在稍長的時間內（分鐘到小時的數量級）存在于長時間運行的后臺作業(yè)、KV 緩存或臨時文件緩存中。對于文件緩存，所有數據都使用客戶端生成的密鑰進行加密，這些密鑰僅在請求期間保留。隱私模式用戶提交的代碼數據永遠不會用于模型訓練。

用戶的隱私模式設置存儲在客戶端上。每個發(fā)送到我們服務器的請求都包含一個 標頭。為了防止意外地將隱私模式用戶視為非隱私模式用戶，如果標頭丟失，我們始終默認假設用戶處于隱私模式。

所有發(fā)送到我們服務器的請求首先會訪問一個代理，該代理決定應由哪個邏輯服務處理請求（例如，“聊天服務”或“Cursor Tab 服務”）。每個邏輯服務都有兩個幾乎相同的副本：一個副本處理隱私模式請求，另一個副本處理非隱私模式請求。代理檢查 標頭的值，并將請求發(fā)送到相應的副本。副本本身也會檢查標頭以進行冗余。默認情況下，隱私模式副本中的所有日志記錄功能都是空操作，除非像 這樣帶有后綴，我們會仔細審查這些后綴，以確保永遠不會附加任何潛在的代碼數據或提示。對于產生后臺任務的請求，我們類似地為隱私模式和非隱私模式設置了并行隊列和工作副本。這種并行基礎設施使我們對隱私模式保證及其抵抗意外錯誤或漏洞的彈性充滿信心。

對于團隊級隱私模式強制執(zhí)行，每個客戶端每 5 分鐘 ping 服務器一次，以檢查用戶是否在強制執(zhí)行隱私模式的團隊中。如果是，它將覆蓋客戶端的隱私模式設置。為了防止客戶端的隱私模式 ping 由于任何原因失敗的情況，我們的服務器還在熱路徑中檢查用戶是否屬于強制執(zhí)行隱私模式的團隊，如果是，則即使標頭另有說明，也將其請求視為處于隱私模式。在延遲敏感型服務上，我們會將此值緩存 5 分鐘，對于任何緩存未命中，我們都假設用戶處于隱私模式?？偠灾?，這意味著當用戶加入團隊時，他們保證最遲在加入團隊后 5 分鐘內處于隱私模式。

您可以隨時在 中刪除您的賬戶（點擊“高級”，然后點擊“刪除賬戶”）。這將刪除與您的賬戶關聯的所有數據，包括任何索引的代碼庫。我們保證在 30 天內完全刪除您的數據（我們會立即刪除數據，但我們的一些數據庫和云存儲的備份不超過 30 天）。

值得注意的是，如果您的任何數據曾用于模型訓練（這只會在您當時未處于隱私模式時發(fā)生），我們現有的訓練模型不會立即重新訓練。但是，任何未來訓練的模型都不會使用您的數據進行訓練，因為該數據已被刪除。

如果您認為自己在 Cursor 中發(fā)現了漏洞，請按照我們的 上的指南進行操作，并在那里提交報告。如果您無法使用 GitHub，您也可以通過 與我們聯系。

我們承諾在 5 個工作日內確認漏洞報告，并在我們能夠盡快解決它們。我們將以安全公告的形式在我們的 GitHub 安全頁面上發(fā)布結果。重大事件將通過 GitHub 安全頁面和電子郵件向所有用戶通告。