Security changed Cursor, Nov 10, 2024
Cursor · Nov 10, 2024 · 7 added, 7 removed · found in an Internet Archive capture
- Added: While we have several large organizations already trusting Cursor, please note that we are still in the journey of growing our product and improving our security posture. If you're working in a highly sensitive environment, you should be careful when using Cursor or any other AI tool. We hope this page gives insight into our progress and helps you make a proper risk assessment.
- Added: Exa and SerpApi See search requests (potentially derived from code data) : Used for web search functionality. Search requests are potentially derived from code data (e.g. when using "@web" in the chat, a separate language model will look at your message, conversation history and current file to determine what to search for, and Exa/SerpApi will see the resulting search query).
- Removed: Exa Sees search requests (potentially derived from code data) : Used for web search functionality. Search requests are potentially derived from code data (e.g. when using "@web" in the chat, a separate language model will look at your message, conversation history and current file to determine what to search for, and Exa will see the resulting search query).
- Added: One security-related difference to VS Code to note:
- Removed: Two security-related differences to VS Code to note:
- Removed: Our cursor-server builds, which are installed whenever you do remote development with Cursor (e.g. when developing over SSH), are based on Node 16, which has reached its EOL. We do this to support machines that do not have glibc >= 2.28 installed (e.g. Ubuntu 18). VS Code currently gives the Node 16-based legacy build to everyone who does not have glibc >= 2.28 , and gives a Node 20-based non-legacy build to everyone else, whereas we give the Node 16-based legacy build to everyone. Once VS Code ceases to support the Node 16-based build in February, 2025 (see here ), we will also upgrade to the non-legacy build process and distribute that to everyone.
- Added: Privacy mode can be enabled during onboarding or in settings. When it is enabled, we guarantee that code is not stored at our servers or by our subprocessors. Privacy mode can be enabled by anyone (free or Pro user), and is by default forcibly enabled for any user that is a member of a team.
- Removed: Privacy mode can be enabled during onboarding or in settings. When it is enabled, we guarantee that code data is not stored in plaintext at our servers or by our subprocessors. Privacy mode can be enabled by anyone (free or Pro user), and is by default forcibly enabled for any user that is a member of a team.
- Added: With privacy mode enabled, code data is not persisted at our servers or by any of our subprocessors. The code data is still visible to our servers in memory for the lifetime of the request, and may exist for a slightly longer period (on the order of minutes to hours) for long-running background jobs, KV caching, or temporary file caching. For file caching specifically, all data is encrypted with client-generated keys that are only retained for the duration of the request. The code data submitted by privacy mode users will never be trained on.
- Removed: With privacy mode enabled, code data is not persisted at our servers or by any of our subprocessors. The code data is still visible to our servers in memory for the lifetime of the request, and may exist for a slightly longer period (on the order of minutes to hours) for long-running background jobs or KV caching. The code data submitted by privacy mode users will never be trained on.
- Added: For team-level privacy mode enforcement, each client pings the server every 5 minutes to check if the user is on a team that enforces privacy mode. If so, it overrides the client's privacy mode setting. To prevent cases where the privacy mode ping by the client fails for any reason, our server also, in the hot path, checks whether the user is part of a team that enforces privacy mode, and if so treats the request as if it is on privacy mode even if the header says otherwise. On latency-sensitive services, we cache this value for 5 minutes, and for any cache miss we assume that the user is on privacy mode. All in all, this means that when a user joins a team, they will be guaranteed to be on privacy mode at the very latest 5 minutes after joining the team. As a special case, if a user signs into a team account at onboarding, they will be guaranteed to be on privacy mode immediately.
- Removed: For team-level privacy mode enforcement, each client pings the server every 5 minutes to check if the user is on a team that enforces privacy mode. If so, it overrides the client's privacy mode setting. To prevent cases where the privacy mode ping by the client fails for any reason, our server also, in the hot path, checks whether the user is part of a team that enforces privacy mode, and if so treats the request as if it is on privacy mode even if the header says otherwise. On latency-sensitive services, we cache this value for 5 minutes, and for any cache miss we assume that the user is on privacy mode. All in all, this means that when a user joins a team, they will be guaranteed to be on privacy mode at the very latest 5 minutes after joining the team.
- Added: We commit to addressing vulnerability reports within 15 business days, and will publish the results in the form of security advisories on our GitHub security page. Critical incidents will be communicated both on the GitHub security page and via email to all users.
- Removed: We commit to addressing vulnerability reports immediately, and will publish the results in the form of security advisories on our GitHub security page. Critical incidents will be communicated both on the GitHub security page and via email to all users.
About this change
- Page
- cursor.com/security
- Kind
- Documentation
- Text hash
- a5af7b0432b0 to b7651cd9dabb
- Dated by
- the first Internet Archive capture sampled that shows the new text; the change happened on or before this date