Securing code written with Windsurf: a review checklist

Like other editor-based tools, Windsurf works inside whatever project you open, so the framework, hosting and database are yours. Its documentation has moved: the Windsurf docs address now redirects to a Devin Desktop documentation site, which describes an AI IDE and mentions Windsurf as a former name. Product names and menu labels may therefore differ from what you see, so check the current documentation for your version.

The current documentation describes four terminal auto-execution levels for the agent. Disabled requires approval for every command. Allowlist only auto-runs commands you approved. Auto leaves the safety judgment to the agent and still asks about risky commands, on premium models only. Turbo runs everything except commands on the deny list. It also describes allow and deny lists, where a command matching both requires approval, and administrator controls on team plans that cap the maximum level. Verify setting names in your build.

The boundary here has two sides. Code the agent writes is untrusted until you read and test it. And anything you pre-approve for execution widens the damage from a mistake or from instructions hidden in a file or web page the agent reads. The most permissive level is convenient and removes the pause where you would notice a bad command.

Run these in your own repository after a Cascade session. They show what changed, what dependencies arrived and whether any secret was written.

The final command lists tracked environment files. No output, apart from an example file with placeholders, is the pass result.

git status --short
git diff --stat
git diff -- package.json package-lock.json

git diff | grep -nE "sk_live_|sk-[A-Za-z0-9]{20,}|BEGIN PRIVATE KEY|password\s*="

git log --all -p -S"BEGIN PRIVATE KEY" | head -50

npm audit --omit=dev

git ls-files | grep -E "^\.env"

If the approval prompts slow you down, narrow them instead of removing them. Add specific read-only commands to the allowlist, such as listing files or running your test suite, and put destructive verbs on the deny list. Because the documentation says a command matching both lists requires approval, a deny entry is a safety net over a broad allowlist entry, but do not rely on that alone. A single broad entry such as a bare shell name approves far more than you meant.

Keep production out of reach. Run the agent against a development database with disposable data, and keep production credentials out of the shell it uses. Prefer scoped, revocable tokens. If a team administrator sets a maximum level, treat that as a floor you are glad to have.

For MCP servers, the documentation notes that tool calls can run code written by arbitrary server authors and disclaims liability for failures. Read that literally. Install servers from sources you can identify, check what commands they launch, give them the least access that works, and remove the ones you stop using. Team plans can restrict servers to an allowlist, so use it if you can.

• Switching to the most automatic level for a long task and forgetting to switch back.
• Adding a broad command to the allowlist and assuming the deny list covers every dangerous case.
• Running the agent with production credentials in the environment.
• Committing large AI diffs unread because the app appears to work.
• Installing MCP servers from unknown sources or leaving unused ones connected.
• Storing a key in a rules file or in a saved memory.
• Trusting the documentation you remember. Names and settings changed, so check the current site.

After a session, start the app locally and call each route the way an attacker would, without a session and with the wrong user's session. Compare fields returned in responses with what the screen shows. Read new dependencies and confirm they are needed. An agent's final message describes intent, and only requests and diffs show what actually happened.

The first call must be rejected as unauthenticated and the second must be refused or return nothing. Adjust the paths and token style to your own project.

export BASE="http://localhost:3000"

curl -i "$BASE/api/records/RECORD_ID_OWNED_BY_USER_A"

curl -i "$BASE/api/records/RECORD_ID_OWNED_BY_USER_A" \
  -H "Authorization: Bearer USER_B_TOKEN"

Recheck your auto-execution level, both lists and your MCP servers after each update and before starting long unattended tasks. Run the diff, secret and audit commands before every commit. Pass condition: nothing destructive can run without your approval, no secret is tracked or in history, and every merged AI change has been read and tested against the running app.