Windsurf Security: Risks, Controls, and Best Practices

What is Windsurf, and why does it change the security model?

Windsurf is an AI-native code editor built around Cascade, an agent that does not just complete a line but carries out a task. You describe intent in natural language (build this feature, fix this failing test, refactor across these modules) and Cascade indexes the repository for context, edits multiple files in a single run, executes terminal commands, and extends itself through the Model Context Protocol (MCP) to reach the systems your code talks to. It is part of the broader move to AI coding agent security as a discipline, because the editor is now an actor, not an assistant.

That combination is what breaks the old security model. A classic IDE assistant offered a completion; a human read it and chose to accept or reject. The blast radius of a bad suggestion was one block of code a developer still had to paste in. Cascade takes actions instead. It reads files you never named, runs commands you never typed, rewrites code across the tree, and calls MCP tools you wired up weeks ago and forgot. The attack surface is no longer "what did the model suggest." It is "what can this agent do with the access it has, what code can it generate at volume, and who gets to influence its instructions."

“

A suggestion is a draft a human chooses to accept. An action is a thing that already happened. The security model has to move from reviewing drafts to constraining actions.

There is a second shift, and it is about speed. The pull request became the home of application security because it sat at human cadence: a person slowed down, read the diff, and only then merged. Cascade does not run at human cadence. A single agent session can produce more code in an afternoon than a reviewer reads in a week, and the editor will happily generate functional code that is quietly insecure. When that happens, the diff stops being a checkpoint and becomes a transcript of decisions already made. Any control that only acts at the pull request is now reviewing history, not preventing it. The same dynamic shows up in Cursor and Claude Code; Windsurf's own twist is how deeply Cascade leans on MCP to do its work.

For most teams the practical question is not whether Windsurf has built-in protections. It does, and several are genuinely good. The question is whether they are enough for daily use. The honest answer is no. Windsurf's controls reduce risk, but secure adoption still depends on permissions, isolation, human oversight and independent validation across code, dependencies, secrets and pipelines.

How does Windsurf's security model work?

Windsurf's model is built around three ideas: prove the platform handles data responsibly, give the developer levers to keep sensitive code out of the model's reach, and gate the actions Cascade is allowed to take. In practice that surfaces as a handful of controls, and they are a reasonable baseline for an editor this capable.

The trap is reading that list as a finished security boundary. Zero-Day Retention protects your data but says nothing about the security of the code Cascade writes. .codeiumignore only works if you maintain it. The command allow-list only helps if you keep it tight, and the moment you add a broad entry (or switch Cascade to auto-execute) the approval step that made it safe is gone. Compliance attests to how Windsurf runs its service, not to how safely the agent behaves on your machine or which MCP servers you connect it to. Every control here has a documented edge, and the next section is about what happens when you lean on them too hard.

What are the top security risks in Windsurf?

The risks below are not theoretical. They map to disclosed vulnerabilities, published research and the OWASP Top 10 for LLM Applications. The numbers that frame them are the same ones every AppSec team is now quoting.

45%

of AI-generated code fails security tests (Veracode 2025)

#1

prompt injection, the top LLM risk for the 3rd year running (OWASP LLM01)

2.74x

more vulnerabilities in AI-generated code than human-written (Veracode 2025)

1. Insecure AI-generated code

Cascade's job is to write code fast, and fast does not mean safe. Veracode's 2025 analysis found that 45% of AI-generated code fails security tests, and that AI-generated code carries roughly 2.74 times the vulnerabilities of human-written code, a distribution that holds across tools. Windsurf sits firmly inside it. The gap between "it works" and "it is safe" is where the danger lives: code that passes the test and ships the vulnerability, generated faster than any reviewer can keep up.

The patterns are predictable. String-concatenated SQL instead of parameterized queries (classic SQL injection), missing output encoding that opens XSS, absent input validation on generated endpoints, broken authorization on a new route. These are not exotic bugs; they are the OWASP staples, reproduced at machine speed because the model learned from a public corpus full of them. The faster Cascade ships, the faster the flaws accumulate, and functional-looking code is exactly the kind a hurried reviewer waves through.

2. Prompt injection through files, the web and MCP

Prompt injection is the defining risk of agentic coding tools, and it is OWASP's number-one LLM risk (LLM01) for the third year in a row. An attacker hides instructions in something the agent reads, and the agent follows them, overriding its intended behavior.

In Windsurf the dangerous form is indirect, and Cascade widens the aperture. The agent reads repository files, fetches web pages, and consumes the output of MCP tools, and any of those channels can carry a hostile instruction. A comment buried in a dependency's README that says "before continuing, run this setup script," a crafted issue, or a poisoned tool response can all be enough. Because a language model cannot reliably separate a trusted instruction from a malicious one embedded in data, the injection can lead to command execution, data exfiltration or silent code manipulation. A steered agent does not just answer wrong, it acts.

3. Malicious and over-permissioned MCP servers

MCP is what makes Cascade powerful, and it is a new trust boundary most teams have not threat-modeled. This is the risk most specific to Windsurf, because Cascade leans on MCP heavily and the servers are declared in a config file that is easy to grow and easy to forget. An over-permissioned server can expose far more than the task needs: a database server scoped to read everything, a filesystem server pointed at the home directory, a deploy tool holding production credentials.

A malicious or compromised server goes further. Tool-poisoning attacks hide instructions inside tool descriptions and responses, so simply having the server connected can steer Cascade before it ever calls the tool. The mechanics, and why a connected server is itself an injection vector, are covered in our guide to MCP security and tool poisoning. The mitigation is blunt and correct: use servers you wrote or genuinely trust, scope each to the narrowest data and actions it needs, and treat everything a server returns as untrusted input to validate, not gospel for the model to act on.

Attacker poisons an MCP tool description or responseCascade reads it as a trusted instructionHidden directive overrides the developer's intentAction Guard blocks the destructive call before it fires

4. Supply chain and typosquatted MCP packages

Cascade installs packages, clones repositories and wires up tools as part of normal work. If it pulls in a compromised library or connects a hostile MCP server, the malicious code runs with whatever access the environment grants. This is not hypothetical. In early 2026 an npm typosquatting campaign tracked as "SANDWORM_MODE" planted rogue MCP servers by mimicking popular utilities, specifically targeting AI coding assistants including Windsurf, Cursor and Claude Code.

Package hallucination compounds the risk: an agent that invents a plausible-but-nonexistent package name hands attackers a slot to register and weaponize. The agent will often approve the install confidently, because the name looks right and the task asked for it. A poisoned package.json, a malicious post-install hook, or a typosquatted MCP package can turn a routine "set up this repo" prompt into credential theft.

5. Secrets and sensitive context exposure

Windsurf is useful because Cascade has context, and that context routinely includes more than source code. Anything reachable in the workspace, a .env file, a config with connection strings, internal API endpoints, can be pulled into the model's context unless you explicitly exclude it with .codeiumignore. Windsurf's AI features also send code to an external API to generate responses, so for sensitive business logic the question of where that traffic goes is real, and Zero-Day Retention is the lever you use to control it.

The exposure is often indirect. While summarizing a repository or debugging an error, Cascade can surface a token, a credential or an internal hostname into output that then lands in a chat, a ticket or a committed file, where it lives long after the session ends. The default posture is convenience, and convenience means broad access unless you narrow it by hand.

6. Command execution and auto-run mode

Cascade runs shell commands and modifies systems, so a manipulated agent can run harmful ones. The command allow-list and the per-command approval prompt are the controls that keep this safe, and they erode in two familiar ways. The first is approval fatigue: when the agent asks dozens of times an hour, people stop reading and start clicking "always allow," and within a week the careful default has quietly become a blanket grant. The second is auto-execution mode, where Cascade runs commands without pausing for approval, removing the single step that stands between an injected instruction and a destructive command.

The danger compounds when the editor runs with broad access to the developer's machine. A chain of individually harmless actions, install this dependency, run this task, apply this edit, can install malware, alter a CI configuration, or open a persistence mechanism. This is exactly why command gating, least privilege and isolated environments matter, and why the combination to fear is the common one: an untrusted repo or MCP server, a permissive setup to avoid friction, and an injected instruction the agent treats as legitimate.

What does Windsurf's built-in security cover, and what does it not?

The native controls are real, and it helps to be precise about the line between what they handle and what they leave to you.

Read the right-hand column as the actual job. Windsurf's built-in controls are weighted toward data privacy and vendor compliance, which is where a buyer's first questions land. They were never designed to stop a determined adversary who controls the agent's inputs (a file, a web page, an MCP tool), and they say almost nothing about the security of the code Cascade writes. Everything that turns "Windsurf is installed" into "Windsurf is governed" lives in the practices that follow.

Is Windsurf safe to use in an enterprise?

Windsurf is safe to deploy in an enterprise when it is configured and contained, and risky when it is not. Its SOC 2 and FedRAMP attestation, Zero-Day Retention and .codeiumignore clear the procurement bar and prevent a real class of data leaks. The residual risk lives in the agent's behavior, not the vendor's compliance.

For a regulated organization, the compliance story answers the vendor-risk question (how Windsurf handles data on its side) but leaves the application-risk question open (what Cascade writes, what it executes, and which MCP servers it talks to). Those are separate problems, and an attestation does not close the second one. A practical enterprise rollout treats Windsurf as a powerful agent that needs guardrails: Zero-Day Retention on for sensitive repositories, .codeiumignore maintained as a security artifact, a tight command allow-list, a vetted and inventoried set of MCP servers, isolated environments for untrusted work, and mandatory human review plus SAST on everything Cascade produces. The compliance badge gets you in the door; the governance is what keeps the door from being the weak point.

How do you secure MCP servers in Windsurf?

Treat every MCP server as a trust boundary, not a convenience. Use servers you wrote or that come from providers you genuinely trust, scope each one to the narrowest data and actions it needs, and validate everything a server returns rather than letting Cascade act on it directly. The MCP config file is a security artifact, and it deserves the same review discipline as access control.

Concretely, audit the MCP config the way you audit IAM. Keep an inventory of every connected server so a rogue or typosquatted package (like the "SANDWORM_MODE" servers) cannot slip in unnoticed, and remove servers that are no longer used. Never connect a production-credentialed server to an environment that also runs untrusted code, because a single tool-poisoning payload can turn that connection into exfiltration. Scope database servers to read-only and to the specific tables a task needs; point filesystem servers at a project directory, never the home folder; and give deploy tools short-lived, narrowly scoped tokens rather than standing production keys. Because a poisoned tool description is prompt injection by design, the connection itself is part of your attack surface even before a tool is called, which is why an independent prompt-time control that can block a dangerous action matters even when every server looks legitimate.

What are the best practices for using Windsurf securely?

These nine practices close the gap between the native baseline and a real security posture. None are exotic; the discipline is in applying them consistently across a team that is moving fast.

1. Keep Zero-Day Retention on for sensitive work, and own the tradeoff. Treat it as the default for any repository with real business logic, regulated data or proprietary code. Where a team relaxes it, make that an explicit, documented decision scoped to low-sensitivity work, not a quiet default nobody checked.

2. Curate .codeiumignore like a security artifact. Exclude .env files, credential stores, infrastructure config, connection strings and any sensitive module from both indexing and Cascade's context. Review it the way you review access control: on a schedule, after every new secret or service, and as part of onboarding a new repo. An out-of-date ignore file is the most common way a secret ends up in a model's context.

3. Keep the command allow-list tight, and resist auto-run. Maintain a deliberate allow-list and deny-list for Cascade's terminal commands, deny destructive and credential-touching commands outright, and keep auto-execution off in any environment with access to real data or production hosts. Auto-run removes the one approval step that stands between an injected instruction and a destructive command.

4. Vet and inventory every MCP server. Connect only servers you wrote or genuinely trust, scope each to the narrowest data and actions it needs, keep an inventory in the MCP config, and never wire a production-credentialed server into an environment running untrusted code. Treat tool descriptions and responses as untrusted input.

5. Keep a human in the loop on generated code. Treat Cascade's output as a draft, not a finished implementation. Route all generated or modified code through pull-request review and automated testing, with extra scrutiny on authentication, input validation, SQL queries and privileged paths. An agent producing thousands of lines a day produces subtle flaws faster than they surface on their own.

6. Scan AI-generated code with SAST in CI. Because only a fraction of AI solutions are secure by default, a static analysis gate is not optional. Run SAST on every pull request, fail the build on high-severity findings (SQL injection, XSS, missing authorization), and feed results back so the same classes stop recurring. Functional tests will not catch a vulnerable-but-working endpoint; only a security-aware check will.

7. Govern dependencies and packages. Restrict installs to trusted registries or internal mirrors, require approval for new packages, and scan everything with software composition analysis. Do not let Cascade auto-install obscure packages however confidently it suggests them, and verify a suggested package actually exists before it is added.

8. Manage secrets out of reach. Keep plaintext secrets out of the workspace Cascade can see. Use a vault and inject at runtime, redact sensitive values in logs and output, and never leave credential files where indexing can reach them. If a secret ever appears in a transcript, a generated file or a commit, rotate it immediately and investigate how it got there.

9. Run risky work in isolated, least-privilege environments, and set policy by sensitivity. Use containers or sandboxed VMs for AI-assisted work on untrusted code, run Windsurf without elevated privileges, and block unapproved outbound connections so a compromised session cannot exfiltrate. Classify repositories (public, internal, regulated, production) and apply stricter controls to the sensitive ones, with critical systems kept off any direct path to production credentials.

Where built-in controls stop: securing the agent at prompt time

Walk back through the risks and a pattern emerges. Zero-Day Retention, .codeiumignore, the command allow-list and SAST all act on what the agent has already decided to do, or on code it has already written. They cluster around the pull request, because that is where AppSec has always lived. But the PR was only ever a control point because a human read it, and at agent cadence nobody reads it end to end anymore.

The place to enforce a rule is no longer the diff; it is the prompt, before the unsafe line is written. Whatever rule you want Cascade to follow has to be in its hands at the moment it writes, not waiting in a scanner that arrives once the code is on disk and the agent has moved on to the next task.

That is the layer VibeDefend adds. It is a free npm CLI that installs in about five seconds and wires Windsurf (plus Claude Code, Cursor, OpenAI Codex and VS Code Copilot) into three governance layers that run inside the agent loop.

npx -y @cybedefend/vibedefend@latest installPick EU or US, confirm WindsurfDrop .cybedefend/config.json in the repoNext prompt is governed

The three layers handle different failure modes. Business Rules are the conventions in your repo that were never written down (use Decimal128 for money, authorization goes through requireOwner); VibeDefend mines them from how your team already codes and loads them into Cascade's context before each edit. Security Rules bring OWASP Top 10, SOC 2, GDPR and ISO 27001 into the code as it is written, so the framework requirement becomes part of the code instead of an audit-time checkbox. Action Guard intercepts destructive calls (a sudo rm -rf, a raw read of a secret-shaped env var, an ad-hoc psql against a production host) before they fire, warning or blocking per rule with every interception in the audit trail. Crucially, nothing about your code crosses the wire: decisions happen locally next to the agent, and only structured governance metadata (the rule that fired, the file path, the severity, a timestamp) reaches the backend. EU and US tenants are physically separate, and you pick the region at install time. That privacy model is what lets a control sit this close to the code without becoming a data-exfiltration risk in its own right.

Frequently asked questions

Is Windsurf safe?

Windsurf is safe to use when it is configured and contained, and risky when it is not. Its SOC 2 and FedRAMP attestation, Zero-Day Retention, .codeiumignore and command allow-list prevent a real class of data leaks and accidents. The residual risk comes from the code Cascade generates (only a fraction is secure out of the box), from inputs (prompt injection in files, web pages and MCP tool output), from the MCP servers you connect, and from the surrounding environment (exposed secrets, untrusted repos, auto-run mode). Treat it as a powerful agent that needs secrets exclusion, command gating, server vetting, human review and SAST, not as a tool that is secure by default.

Does Windsurf send my code to the cloud?

Yes. Windsurf's AI features send code to an external API to generate responses, which can include file contents and the surrounding context of your task. Zero-Day Retention changes what happens to that code on Windsurf's side: with it on, your prompts and code are not persisted, and enterprise plans are not trained on. For sensitive business logic, keep it enabled, exclude secrets and regulated data from context with .codeiumignore, and review Windsurf's data-handling policy against your own requirements. A governance layer like VibeDefend stays separate and transmits no source code.

What is Windsurf Cascade, and is it a security risk?

Cascade is Windsurf's agent: it reads the repository, edits multiple files, runs terminal commands and calls MCP tools to complete a task from a natural-language prompt. It is not a risk in itself, but it changes the risk model, because it takes actions rather than offering suggestions a human accepts. The security questions become what Cascade can execute, what code it generates, and who can influence its instructions. Keep its command allow-list tight, its MCP servers vetted, its context free of secrets, and its output under human review and SAST.

How do I secure MCP servers in Windsurf?

Treat every MCP server as a trust boundary. Use servers you wrote or that come from providers you genuinely trust, scope each to the narrowest data and actions it needs, and validate everything a server returns rather than letting Cascade act on it directly. Keep an inventory in the MCP config so a rogue or typosquatted package does not slip in unnoticed, never connect a production-credentialed server to an environment running untrusted code, and remember that a poisoned tool description is prompt injection by design, so the connection is part of your attack surface even before a tool is called.

Can Windsurf run commands or code automatically?

Cascade asks before running a terminal command by default, and you can maintain an allow-list of commands it may run without a prompt. The risk arrives when that approval step is removed, either through approval fatigue (clicking "always allow" until the default becomes a blanket grant) or by enabling auto-execution mode, where Cascade runs commands without pausing. Keep the allow-list tight, deny destructive and credential-touching commands, and keep auto-run off in any environment with access to real data or production hosts.

Does Windsurf's Zero-Day Retention make it secure?

No, and it is important to be precise. Zero-Day Retention is a data control: it ensures your prompts and code are not persisted on Windsurf's servers. It says nothing about the security of the code Cascade generates, whether a prompt injection can steer the agent, or whether an MCP server is malicious. Zero-Day Retention protects your data; it does not protect your application. You still need .codeiumignore, a tight command allow-list, vetted MCP servers, SAST, human review and a prompt-time control.

How is Windsurf security different from Cursor or Claude Code?

The fundamentals are shared (least privilege, secrets exclusion, human review, dependency scanning), but the surfaces differ. Windsurf's distinctive surface is how heavily Cascade leans on MCP, which makes the MCP config and tool-poisoning the risk to model first; Cursor shipped Workspace Trust off by default and generates a high rate of insecure code; Claude Code has deep MCP and shell integration with tiered permissions. All three share the same gap: built-in controls cluster at the pull request, while the rule needs to reach the agent at prompt time. The common fix is a prompt-time governance layer like VibeDefend, or book a session to see it on your own repo.