Review both what Cascade can do in your workspace and what the application it generates can do in production. An agent’s command permissions and your app’s authorization rules solve different problems.
Windsurf’s official documentation index links terminal command controls, file indexing exclusions and MCP configuration. Consult the settings for your installed version before giving Cascade access to a sensitive project.
1. Set a deliberate command boundary
Inspect terminal auto-execution and allow/deny settings. Review commands that install packages, change deployment state, read credentials or send data to a remote endpoint. Broad command approval deserves more scrutiny than permission to run a known test.
Use a development environment with synthetic records and test service keys. Keep production administration separate from ordinary coding. A mistaken “reset the database” instruction should not be able to destroy customer data.
2. Inventory MCP servers and workspace context
List the MCP servers configured for the workspace, their publishers and the operations each exposes. Treat repository text, issue descriptions and tool output as source material that may contain hostile instructions.
Exclude confidential material from unnecessary context and indexing, using the controls supported by your installed version. An exclusion is a context choice; do not assume it is an operating-system security barrier. Limit the credentials and filesystem access available to tools as well.
3. Inspect generated dependencies and changes
Read package.json, the lockfile and changes to scripts. Confirm why every newly introduced dependency is needed. Check install hooks and external downloads before running them in an environment with useful credentials.
Review changes to login handlers, database policies, server calls and error handling. A generated fallback that returns an empty list can hide a broken integration. Ask for an explanation of the failure path and verify it yourself.
4. Test the application’s boundaries
Use two synthetic users to test cross-account reads and writes. Search the built frontend for credential exposure. Cause a controlled upstream failure and verify the app reports it honestly. Check that private user data is redacted from logs and unnecessary model prompts.
Save a regression test for each reproducible defect. Avoid accepting a new test solely because the same agent wrote both the implementation and the assertion; inspect whether it exercises the actual user-visible failure.
5. Run a local repository diagnosis
npx @neuralaxis/vibedoctor scan --fullVibeDoctor can inspect the repository and combine applicable engine findings with built-in checks. It does not configure Cascade’s permissions or establish that your production settings are safe. Recover failed engines before trusting the report, then give the agent one verified finding at a time.
Read the broader vibe coding checklist for the final release sequence, and how it works for VibeDoctor’s coverage limits.