If Windsurf's Cascade agent wrote an API key into your source, or a secret leaked through a prompt or an MCP workflow, treat the key as compromised. Rotate it first, then remove it from the code and history, then keep secrets out of the agent's reach. Where the key ended up matters less than the fact that it left your control.
Why it's a problem
A hardcoded key in committed source is exposed to anyone with the repo. Windsurf runs as a desktop IDE with agentic workflows, so secrets can also leak through prompts, MCP server calls, and unvalidated commands the agent runs, paths that a browser or a normal linter never sees. Once a key is out through any of these, it is out.
How to fix it, in order
- 1Rotate the key first. Revoke and regenerate it at the provider before touching anything else.
- 2Check the provider's logs. Look for use you do not recognize and treat anything unexplained as an incident.
- 3Remove it from code and git history. Delete the inline value and, if committed, purge it with filter-repo or BFG and force-push.
- 4Move it to an environment variable. Read the new key from the environment and confirm the .env is gitignored.
Why Windsurf does this
Cascade generates and runs code to complete a task, and inlining a key is the quickest way to make an integration work in the moment. Its agentic reach, running commands and calling MCP servers, also means a secret in your environment can end up in a prompt or a tool call without an obvious commit.
Stop it happening again
Keep secrets in environment variables and out of files the agent indexes or prompts against. Be deliberate about which MCP servers Cascade can auto-invoke, since those calls can carry data out. Add a gitleaks pre-commit hook so a hardcoded key fails the commit no matter how it got there.
The quick fix
- Rotate the key first.
- Check provider logs for unauthorized use.
- Purge from git history; move the key to an environment variable.
- Limit which MCP servers can auto-run and add a gitleaks pre-commit hook.