The main Windsurf security concerns are tools that act without asking, terminal commands that run on their own, and MCP servers nobody reviewed. Researchers showed in 2025 that a prompt injection hidden in a file or web page could make Windsurf's Cascade agent send data out through its URL-reading tool or save instructions into its long-term memory, neither of which asked the user first. Windsurf does give you controls: session modes that decide how commands run, Allow, Ask and Deny rules, and for Teams and Enterprise plans, organization rules and an MCP server allowlist. The concerns are manageable once those controls are set on purpose rather than left at their defaults.
Windsurf, Cascade and Devin: which product this covers
Windsurf is an AI code editor whose agent is called Cascade. It is now part of Cognition, and its documentation is moving under the Devin name: the terminal page describes "Devin Desktop" while its enterprise section and many links still say Windsurf. Settings and admin controls carry over, so this guide uses Windsurf throughout and links to the current docs.
Windsurf security concerns from published research
Data leaving through tools that need no approval
In August 2025, the researcher behind Embrace The Red published two ways a prompt injection could move data out of a developer's machine. The read_url_content tool makes outbound web requests without user approval, so injected instructions could put source code or .env values into a URL. Windsurf also rendered images from outside domains, which leaks data the same way. The issues were reported on May 30, 2025; the author published after about three months without a fix, and later noted Windsurf said it was working on one, with no date.
Instructions that persist in memory
A second post showed that Cascade's create_memory tool also ran without approval. A comment hidden in a source file could make the agent save attacker instructions into long-term memory, affecting every future chat. The author suggested memories be proposed for approval rather than added automatically, and that users review stored memories regularly.
Instructions in a filename: CVE-2025-36730
Tenable found that in Windsurf 1.10.7, a crafted filename could be appended to the user's prompt, after which Windsurf followed instructions in that file. In the proof of concept, the agent used its URL-reading tool to send user and project details to a website, with no interaction. The flaw is CVE-2025-36730, rated 4.6 (Medium). Windsurf said VS Code's Workspace Trust partly mitigates it, and when Tenable published on October 14, 2025, a solution had yet to be released.
All three are versions of the same problem: anything the agent reads can carry instructions, and a tool that acts without approval turns those instructions into actions. It is the pattern behind every MCP tool poisoning attack, and it is not unique to Windsurf. Our guides to Cursor security risks and Claude Code security risks cover the equivalent cases in those agents.
Terminal commands: session modes and rules
How Cascade runs shell commands depends on the session mode. In Code mode it asks before running any command that no rule covers. In Smart mode, a fast model approves commands it judges safe. In Bypass Permissions mode it runs uncovered commands without asking, unless organization policy requires approval.
Rules sit on top of the mode. You add them under Allow, Ask and Deny in the settings, written like Exec(git status). Deny has the highest priority and blocks a matching command, Ask always prompts, and Allow runs a command without a prompt. Commands that match no rule follow the session mode. When the agent asks for approval, you can run the command once, allow it for the session, or allow it permanently, which writes an Allow rule.
That last option is where risk accumulates. Every "allow permanently" click widens what runs unattended. Review the Allow list periodically, and keep network tools such as curl and anything that touches credentials on Ask or Deny.
MCP servers in Windsurf
Windsurf reads MCP servers from mcp_config.json. Setup guides place it at ~/.codeium/windsurf/mcp_config.json on macOS and Linux and %USERPROFILE%\.codeium\windsurf\mcp_config.json on Windows; newer Devin-branded docs also describe ~/.config/devin/mcp_config.json. The file uses a top-level mcpServers object. Local servers have command, args and env; remote servers use serverUrl or url with headers. To keep tokens out of the file, Windsurf supports ${env:VARIABLE_NAME} in those fields.
The same checks apply as for any agent: exact versions, narrow folder access, HTTPS for remote servers, and no literal secrets. Our MCP security checklist has the full list, and every check works the same way on a Windsurf config.
Admin controls on Teams and Enterprise
For organizations, two sets of controls address most Windsurf security concerns. On the terminal side, admins can set Allow, Ask and Deny rules for every member, enforce sandbox mode, and limit which session modes members can pick. The docs state that organization Deny and Ask rules take priority over a member's own rules and over Bypass Permissions.
On the MCP side, admins can turn MCP off for the team or keep an allowlist of approved servers. Once any server is on the allowlist, every unlisted server is blocked. Entries are matched with regular expressions anchored to the whole value and case-sensitive: the command must match, each argument is matched against its own pattern, and the number of arguments must match. Values in env are not matched, and invalid patterns deny access. An allowlist is only as good as its patterns, so prefer exact commands with pinned versions over wide ones like .*.
Data retention and whether code may be used for training depend on the plan you are on. Read the current terms for your plan on Windsurf's security page before rolling it out, and confirm them in your contract for Enterprise.
How Windsurf security concerns compare with other coding agents
None of these issues is unique to Windsurf. Every coding agent reads untrusted text, runs commands and loads MCP servers, and every major one has had published research showing an injection turning into an action. What differs is the default behavior and where the controls live. Windsurf's documented answer is the combination of session modes, rule lists and organization policy that overrides individual settings. Claude Code uses permission modes, allow and deny rules and managed settings. Cursor uses its own run modes and an MCP allowlist for teams.
For a security team, the practical point is consistency. Developers often run more than one agent, and a server allowed in one is easy to add to another. Set equivalent rules in each agent the team uses, and keep one inventory of servers across all of them, so a decision made for Windsurf does not quietly fail to apply in the editor next to it.
A short Windsurf hardening list
Set the default session mode to Code for anyone working with untrusted repositories. Add Deny rules for outbound network commands and for reads of credential files. Turn on the MCP allowlist and list exact commands. Keep Windsurf updated and check the changelog for fixes to the issues above. Review saved memories and the permanent Allow list once a month. And keep an inventory of which MCP servers each developer actually loads, since the allowlist only covers machines under the team plan.
Next step: turn Windsurf security concerns into a list you can act on
Most Windsurf security concerns come down to knowing what the agent can reach. The MCP security scanner reads Windsurf's config alongside every other agent on your team's machines and repositories, and scores each MCP server it finds, so the allowlist starts from what is really in use.