Is Cursor AI safe? The editor, the code, and the app you shipped

You built something in Cursor, it works, and you are about to put real people on it. Somewhere in that week you typed "is cursor ai safe" into a search box, and what came back was a page about Cursor's privacy settings, a page about whether AI-written code is any good, and a page about a custom mouse-pointer download. None of them said a word about the app you are about to publish.

Here is the part most of those answers get wrong: "is Cursor AI safe" is three questions wearing one sentence, and they have three different answers. Two of them are about Cursor and the models behind it. The third is about what you shipped, and it is the one that decides whether a stranger can read your users' data.

Think of Cursor as a contractor you hired to build a house. Whether it keeps a copy of your plans is one question. Whether what it builds is up to code is a second. Whether the doors lock once you have moved in is the third, and it stays your question for as long as you live there.

Is Cursor AI safe?

As an editor, it is an ordinary cloud tool: a privacy switch, a published security page and a SOC 2 Type II attestation. That answers one of the three questions, and not the one that decides whether strangers can read your users' data.

1. The editor. Does Cursor keep your code, train on it, or hand it to somebody else. This is the contractor's copy of the plans.
2. The code. Is what the AI writes secure. This is whether the house is up to code, and nobody inspects it on the way in.
3. The app you published. What a stranger can reach from the street: a key in the code a browser downloads, a database that answers with no login, a file that should never have had a URL. These are the doors.

Nothing on Cursor's side can answer the third. Nothing on ours can answer the first two.

Does Cursor keep my code?

For as long as it takes to answer you, yes. After that it depends on one switch.

Cursor is a cloud tool. When you ask it anything, the relevant parts of your project leave your computer, go to Cursor's servers, and are passed on to a model provider (OpenAI, Anthropic, Google, whichever model you picked) to be answered. That is how the product works. The plans have to reach the contractor.

What happens afterwards is the switch, and Cursor's data-use page puts both positions in one paragraph. With Privacy Mode on, "Customer Data will not be used for training by Cursor" and Cursor "maintains zero data retention (ZDR) agreements with all providers", meaning the companies running the models agree to keep nothing either. With it off, Cursor "may use and store codebase data, prompts, editor actions, code snippets, and other code data and actions to improve our AI features and train our models."

The switch is available on every plan, the free one included, and a team or enterprise admin can turn it on for everyone and stop members turning it off. Cursor's own hardening guide says it is on by default for Enterprise accounts. On an individual plan it is a setting, and the setting is worth finding today.

One more thing about it, because it has already caught somebody out. Since mid-2025 there have been two versions: "Privacy Mode", which lets Cursor store some data for features such as its cloud agents and memories, and "Privacy Mode (Legacy)", which stores nothing. In July 2026 a Hacker News poster described signing in to the iOS app and finding their account moved from the legacy setting to the current one. A Cursor employee replied that the prompt to turn on cloud agents had done it "without making clear what that meant or that it's hard to undo", and that moving back was not available in the app. If you chose the stricter one, check it is still selected.

The certificates answer a narrower question than they look. Cursor's security page lists a SOC 2 Type II attestation, ISO/IEC 27001 and ISO/IEC 42001. Those mean an outside auditor checked that Cursor has controls over how it handles the data it holds, the way a contractor's insurance certificate says the contractor is insured. They say nothing about the code it writes and nothing about the app you deploy with it.

What does codebase indexing upload?

An index of your project, kept on Cursor's servers, with the file paths encrypted and the code itself never stored as readable text.

Indexing is how Cursor answers a question about your whole project rather than the file you have open. It splits your files into pieces, sends them to Cursor's servers to be turned into embeddings (a numeric summary of what each piece is about), and keeps those embeddings so that when you ask "where do we handle refunds" it can find the right pieces. Cursor's documentation says: "File paths are encrypted before being sent to Cursor's servers. Code content is never stored in plaintext." What stays on their side is a map of your code, and that is a different thing from a copy of it.

Two things are worth knowing about the map.

Some files are left out by default, and you can add more. Cursor skips anything in your .gitignore and a default list that includes .env*, the file where your secret keys usually live. A .cursorignore file in the project root, written in the same syntax as .gitignore, keeps anything else you name out of the index and out of what the AI is shown.

The agent's terminal does not read that list. This is the caveat that matters for keys. Cursor's ignore-files page says that "the terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore", and that "complete protection isn't guaranteed due to LLM unpredictability". When the agent runs a command on your machine, it can read .env the way any command can. The file is out of the index and still within reach. If a key is in the project folder you have open in Cursor, treat it as a key the agent can see.

Is the code Cursor writes secure?

Not by default, and that is measured, though the measurement is of the models Cursor uses and not of Cursor itself.

Veracode, a company that sells code-security testing, has put over 150 models through the same 80 programming tasks, in four languages, each task offering a secure and an insecure way to do the job. Its spring 2026 update, published on 24 March 2026, found that only 55% of the results were secure, a figure Veracode calls "virtually identical to where they stood two years ago", while the share that compiled had passed 95%. On two of the four flaw types the models almost never chose the safe version: cross-site scripting, which lets one visitor's text run as code in another visitor's browser, passed 15% of the time, and log injection 13%.

Veracode's own summary is that the models "have become excellent at writing code that compiles. They've failed at writing code that's safe."

For you, the person who did not write the code, the gap between those two numbers is the whole finding. The test you run on a Cursor project is whether it works: you click through the app and the right things appear. That is the 95%. The test nobody runs is whether the code decided who is allowed to see what, and the 55% says that decision was made about half the time. An app can pass the first test completely and fail the second, because a page that shows you your orders and a page that shows anyone everybody's orders look identical to the person who owns the account.

Where that decision belongs, and why "load the orders" never makes it on its own, is the middle of the Cursor guide.

Prompt injection, in plain language

The model treats instructions as instructions wherever it finds them, including inside things it was only supposed to read.

You tell Cursor "summarise this thread" or "tidy this file", and to do that it reads the thread or the file. If the thread contains a sentence written to look like an instruction to an AI, the model may follow it, because it has no reliable way to tell your voice from the page's. That is prompt injection, and in a coding agent, which can edit files and run commands on your machine, the consequences reach past a bad summary.

Two named cases, both against Cursor. In March 2025 Pillar Security published "Rules File Backdoor": instructions hidden with invisible Unicode characters inside a .cursor/rules file, the configuration file that tells Cursor how you like your code written. The file looked clean in the editor and in a GitHub diff, and it quietly told the AI to add a script from an attacker's domain to every generated page and never to mention it. Cursor's response was that this was not a vulnerability in its platform and that the responsibility sits with the user. In August 2025 Aim Security disclosed CVE-2025-54135, which they called CurXecute: a message in a public Slack channel, read by Cursor through an MCP server (a plug-in that lets the agent reach outside tools), could make the agent write an entry into its own mcp.json configuration, and Cursor started that entry, running the attacker's command, before you had approved the edit. Cursor fixed it in version 1.3 on 29 July 2025, and every change to that file now waits for your approval.

What follows for you is short. A rules file you copied from a repository or a blog post is code, and it steers everything the agent writes after it, so read it like code. Keep Cursor updated, since the fix for CurXecute was a version number. And every MCP server you plug in that reads text from outside, an inbox, a ticket queue, a search, hands the agent sentences you did not write.

What a scan of 30,998 live apps says about the third question

That nothing about the editor reaches the app you published. We cannot tell a Cursor app from any other from outside, and that is the finding.

Between 12 and 14 August 2026 we ran the nine external checks anyone can run free on our homepage over 30,998 live apps. We found them by where they were published: 18,554 on Lovable's domain, 5,438 on Base44's, 3,042 on Replit's, and so on down. A Cursor project is deployed wherever you put it, on Vercel, on Netlify, on a domain you bought, and the page a visitor downloads carries no mark of the editor that wrote it. So there is no Cursor column in the report, and there cannot be one.

What there is, on every builder we measured, is the same short list of things an owner had left open, and none of them is decided by the editor. Every share below is of the apps that check answered on, because a check that could not finish is unknown rather than passed. No app is named here or anywhere else we publish.

The first row is measured over the 3,680 apps that named a Supabase project and whose database answered the question, which is why its base is smaller; what that check does and does not read has the full ladder. The fifth row is the one that costs money on its own: an OpenAI, Anthropic, AWS or Stripe secret key, or a Supabase service_role key, in the code a browser downloads.

The last column is what changes on Cursor. On a builder's own domain, two of those rows belong to the host: the headers are sent by whatever serves the page, and source maps follow the builder's build settings. A Cursor project is your repository, your build and your deploy, so every row in that table is yours, including the two a Lovable owner does not control. That is more control and more to check, and it is why the Cursor guide spends its time on your build output and your database rather than on the editor. The Replit post asks the same three questions of a platform that both hosts the app and lets you ship a server of your own.

The five-minute check from outside

Use a private window for the first three, so your own login does not answer for a stranger.

1. Open your published address with /.env on the end, then /.git/config. Both should fail. If either shows text, rotate every key in it today, then fix the deploy so the file is never served.
2. Open one of your own API routes the same way, one you would not want a stranger reading. If it answers with data, that route needs a login check.
3. Open your live app, then the Sources tab of your browser's developer tools. If you can read your original files with their comments, source maps are on in your production build.
4. If your data is in Supabase, the inside half of the check is in the Cursor guide: search the build output for service_role and sk_live_, then open the policies page.
5. Or let the scan do it. It runs these and the rest of the nine from outside, takes about 20 seconds, needs no account, and prints "Couldn't check" for anything it could not answer rather than a tick: scan your app.

What changes after the next push?

Anything. A Cursor project ships when you push it, and nothing between your editor and the internet re-reads the app for a route that lost its login check, a key pasted in to get past a failing build at midnight, or a source map that came back on with a config change. The Veracode number is why this matters more here than on a builder: every session with the agent is new code that compiles and may not be safe, and a scan you ran last month describes last month's app.

Reeve Monitor is built for that. It re-runs all nine checks every hour on up to three apps, watches uptime every 60 seconds, tells you when a result changes rather than waiting for you to look, and sends a monthly report. It is $12 a month at list, with seven days free before it charges you; the pricing page is sometimes below the figure here and never above it. Monitor watches and nothing more. If your Cursor app keeps its data in Supabase, Care is the plan that also holds a copy of that database, and of your uploaded files once you connect a Storage credential. If the data lives somewhere else, Monitor is the half that fits.

What to do this week

The inside half of all this, the build output and the database, is the Cursor guide. The 10-minute security checklist covers what is worth confirming on any newly launched app, whatever wrote it.