Windsurf Security Guide: hardening the Cascade agent, MCP and team controls

Windsurf gives an AI agent, Cascade, the developer's terminal, files and network, and how much it can do without asking is decided by settings that many teams never touch. The editor is now documented by Cognition as Devin Desktop: its enterprise policy page notes that pre-rename releases used Windsurf policy paths, and the admin docs still point to the legacy Windsurf dashboard, so administrators will meet both names. This guide covers identity and team administration, admin roles and service keys, MCP and extension governance, terminal auto-execution, data handling settings, logging and a hardening baseline. It goes deeper on this one product than our cross-product AI IDE and Coding Agent Security Guide. Facts come from Cognition's own documentation, checked on 8 November 2026; the product is changing quickly (Cascade is now labelled legacy alongside a newer Devin Local agent), so re-check each setting before you enforce it.

This is an independent guide from NHI Mgmt Group, based on Cognition's public documentation as of November 2026. It is not sponsored or reviewed by Cognition. Product features change, so confirm settings against Cognition's current documentation.

Key takeaways

• Cap autonomy centrally. The team "Maximum autonomy level" limits which Cascade terminal auto-execution level members can pick; without it, any user can select the level that runs everything except the deny list.
• Deny lists beat allow lists. Team and user command lists are merged and a deny match always wins, so a short team deny list for destructive and exfiltration-prone commands is a cheap, strong control.
• One MCP allowlist entry flips the default. Once any server is on the team MCP allowlist, all others are blocked; use that, or registry-only mode, rather than leaving "Allow MCP" open.
• Two agents, two control sets. Legacy Cascade obeys the autonomy level and command lists; Devin Local and Devin CLI obey team permission rules and the Devin Sandbox. Configure both or disable the one you do not use.
• Identity is SAML plus SCIM, Enterprise only. SSO is SP-initiated SAML, SCIM cannot assign roles, and the SCIM token is a service key: treat it as a privileged non-human credential.

How identity and access work in Windsurf

Team members authenticate to Cognition's service, and the team settings they inherit cannot be overridden locally. On Enterprise plans, single sign-on and SCIM provisioning are configured in Team Settings. The SSO and SCIM documentation states the following constraints, each of which affects design:

• Protocol: SAML only; OIDC is not supported for this flow. Documented identity providers are Google Workspace, Microsoft Entra ID, Okta, Duo and PingID, and other SAML providers are said to work.
• Flow: only SP-initiated SSO is supported; IdP-initiated tiles will not work. Users sign in through a team login URL built from an SSO ID chosen at setup, which cannot be changed later, so pick a neutral identifier.
• Testing before saving: the Save button appears only after a successful test login. Cognition's FedRAMP admin guide recommends testing SSO with a non-admin account before broad rollout.
• MFA: MFA is inherited from the identity provider, so enforce it there with a conditional access or sign-on policy scoped to the Windsurf application.
• SCIM: the base URL is https://server.codeium.com/scim/v2 (a legacy Codeium hostname). Only users and groups assigned to the IdP application sync, and the docs state Entra ID syncs every 40 minutes, which sets your worst-case deprovisioning lag unless you trigger an on-demand push.
• Deprovisioning: in Entra ID, removal disables access and frees the seat rather than deleting the user; in Okta you must enable "Deactivate Users". Through the API, setting active to false disables a user.

For the federal deployment, the FedRAMP guide states it runs on AWS GovCloud, SSO (OIDC or SAML 2.0) is the only login method and setup is coordinated with Cognition rather than self-serve. See the SCIM Provisioning Guide for joiner, mover and leaver design.

Admin roles and privileged access

Role-based access control has two built-in roles: the Admin Role with all permissions and the User Role with none. Custom roles are created in Role Management under Team Settings by selecting granular permissions. Super Admins (Admin role in the "all users" group) can change any role; Group Admins can change roles only within their groups. User groups require Enterprise with SCIM and sync from the identity provider.

The FedRAMP guide's recommendations apply to any tenant: reserve the Admin role for a small number of people, require MFA for all administrative accounts, run regular access reviews, and offboard admins by revoking the role, deleting their service keys, then deleting the user. Because SCIM cannot assign roles, role grants happen in the console and will not appear in IdP group reviews; export the Team page for each quarterly review. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Service keys

Service keys are created under Team Settings, Service Keys, and carry the permissions of the role selected. They are used for the SCIM connection and the Analytics API. The docs recommend descriptive names, least-privilege roles and rotation by creating a replacement key and then deleting the old one. Create one key per integration (for example a "SCIM Provisioning" role holding only Teams Read-Only, Update and Delete, and a separate analytics role holding Analytics Read), store each in your secrets manager, and record an owner. See the Secrets Management Guide.

MCP servers

MCP configuration exists at three scopes: project (.devin/mcp_config.json, committed to version control), local override (.devin/mcp_config.local.json, gitignored) and user (~/.config/devin/mcp_config.json). Supported transports are stdio, Streamable HTTP and SSE, each with OAuth. By default the agent asks before every MCP tool call, and users can allow a single tool or a whole server. The project scope matters: a cloned repository can propose MCP servers, which is the pattern covered in our Coding Agent Configuration File Attacks guide.

Extensions, deploys and connected services

The team "Extension policy" is a JSON allowlist keyed by extension ID, publisher or *, and overrides a local or MDM AllowedExtensions policy. "Extension marketplace URL" forces installs from a specified gallery such as an internal mirror. The legacy "App deploys" control lets members deploy to Netlify from Cascade; disable it unless deployments are meant to bypass your pipeline. See the MCP Security Guide for server vetting.

Terminal auto-execution and the agent sandbox

The terminal documentation describes four Cascade levels: Disabled (every command needs approval), Allowlist Only (only allow-listed commands run automatically), Auto (the agent judges safety and potentially risky commands still need approval; requires premium models) and Turbo (everything runs except deny-listed commands). The admin controls reference labels the same cap "Maximum autonomy level" with the values No auto-approvals, Allowlist only, Smart and Bypass. Users can select any level up to the team maximum.

• List syntax: an entry ending in a space and * matches every command starting with those tokens (git * covers git add -A); other entries match exactly. Prefix entries for interpreters such as python * or bash * effectively allow arbitrary code.
• Team lists: configured under Team Settings, Terminal Commands, Manage Lists; merged with user lists, and a deny match at either level overrides an allow.
• Restrict Cascade to workspace: limits Cascade file reads and writes to the open workspace, which keeps the agent out of ~/.ssh, cloud credential files and other repositories.
• Devin Local and CLI: the autonomy cap does not apply. These agents follow "Devin CLI permissions" (team allow, ask and deny rules that take highest precedence over user and project config), "Devin Sandbox" (forces sandbox mode limiting file system and network access to granted scopes), "Sandbox domains" and "Sandbox command exclusions". The "Devin Local Agent" toggle is off by default on Enterprise.
• Web search: off by default for enterprise teams; reading a specific URL is not blocked, but in Cascade each page read needs manual approval.

Auto-execution is where prompt injection turns into action: text in a README, issue or fetched page can ask the agent to run a command, and the level decides whether a human sees it first. See the Prompt Injection Guide and the AI Agent Sandboxing and Code Execution Guide.

Data handling and context controls

• Ignore files: .devinignore at the repository root (gitignore syntax) stops matching files being indexed, viewed, edited or created by the agent; legacy .windsurfignore and .codeiumignore are still read. Defaults already exclude .gitignore paths, node_modules and hidden paths. Enterprise customers can place a global .codeiumignore in ~/.codeium/ that applies to every workspace on the machine, which suits MDM distribution.
• Models with provider retention: "Enable access to Anthropic models with data retention" and the OpenAI equivalent unlock models that require up to 30 days of stored data for trust and safety checks; the docs state providers do not train on this data. Leave them off if your data classification forbids third-party retention.
• Allowlisted models: restricts which models Cascade, Devin Local, Command and Devin CLI can use, filtered by model or by provider.
• Sharing: "Share conversations" creates links visible only to logged-in team members; "Share codemaps" can be set to team or public, team only, or none. Choose team only or none.
• New features: the admin guide states new major features with data privacy implications ship off by default, so review release notes before enabling them.

Device policies (MDM)

Device policies are enforced by the operating system before sign-in and members cannot change them. On Windows the registry path is Software\Policies\Windsurf\Devin, deployed with the Devin.admx and Devin.adml templates; computer-level policies beat user-level ones, and pre-rename releases used Software\Policies\Windsurf\Windsurf with windsurf.admx, so check both if you run mixed versions. macOS uses a configuration profile with policy names as keys, and Linux reads /etc/vscode/policy.json. VS Code policies do not apply to this editor, and the reverse is true.

See the Developer Workstation and IDE Security Guide for the wider endpoint baseline.

Logging and detection

The admin console provides analytics dashboards (Adoption Overview, Team Activity, share of code written by the agent) and an Analytics API, gated by the Analytics Read permission; "Individual analytics" enables per-member views. These show usage, not a security audit trail of every command, so build detection from three sources:

1. Hooks: hooks run a shell command or LLM prompt at lifecycle points. Configured in .devin/hooks.v1.json, a PreToolUse hook with matcher exec runs before every shell command and can block it. Enterprise teams can push team-wide Cascade hooks through the "Agent hooks" setting. Use a hook to log every proposed command and MCP call to a local file your EDR or log agent forwards. Note hooks do not run while a workspace is in Restricted Mode.
2. Endpoint telemetry: process trees with the editor as parent, outbound connections to unexpected domains, and reads of credential files (T1552.001 Credentials In Files). See the macOS Detection and Response Guide.
3. Identity and admin: IdP sign-in logs for the SAML app, SCIM errors, and changes to roles, service keys and team settings reviewed against change tickets.

Metrics: percentage of members whose effective autonomy cap is Allowlist only or lower; number of MCP servers in use outside the allowlist (target zero); service keys older than your rotation period; time from IdP removal to seat deactivation; count of hook-blocked commands per week, trended.

Hardening baseline

1. Identity first: configure SAML SSO and SCIM, enforce MFA in the IdP, and create custom roles so only two or three people hold Team Settings Update and Role Management.
2. Cap the agent: set Maximum autonomy level to Allowlist only for most teams; allow Smart for a pilot ring; avoid Bypass. Add a team deny list covering destructive commands, package publishing, credential tooling and raw network tools.
3. Confine context: turn on Restrict Cascade to workspace, distribute a global ignore file covering .env and key material, and leave web search off unless needed.
4. Govern MCP: disable Allow MCP until an allowlist or registry is in place; then enable registry-only mode.
5. Govern Devin Local: leave the Devin Local Agent off until you have set Devin CLI permissions and forced the Devin Sandbox with a domain allowlist.
6. Lock the client: deploy MDM policies for extensions, update mode and telemetry; set the team Extension policy.
7. Test and roll back: pilot each change with one team for two weeks, watch hook logs for blocked legitimate commands, then widen. Every control here is a team setting, so rollback is a console change; record the prior value in the change ticket.

Common misconfigurations

• No autonomy cap: leaving the maximum at the top level lets any member run Turbo, so an injected instruction executes without review.
• Interpreter prefixes on the allow list: python *, node * or bash * turn Allowlist Only into run-anything.
• Configuring Cascade but not Devin Local: the autonomy cap and command lists do not govern Devin Local or the CLI; enabling the Devin Local Agent without CLI permissions and sandboxing reopens the gap. An unconfined coding agent with production access can delete data as easily as it writes code.
• Allow MCP on with an empty allowlist: members and committed project configs can add any server.
• Shared or over-scoped service keys: one Admin-role key used for SCIM, analytics and scripts, never rotated.
• Assuming SCIM covers roles: admin grants made in the console survive IdP group changes and are missed in access reviews.

Practitioner checklist

• Configure SP-initiated SAML SSO and SCIM; enforce MFA in the IdP; test with a non-admin account.
• Create custom roles; limit Team Settings Update, SSO Write and Role Management to named admins.
• Issue one least-privilege service key per integration, vault it and rotate by create-then-delete.
• Set Maximum autonomy level to Allowlist only and publish a team deny list.
• Enable Restrict Cascade to workspace and push a global ignore file through MDM.
• Disable Allow MCP until an MCP allowlist or registry-only mode is configured.
• Keep the Devin Local Agent off until Devin CLI permissions and Devin Sandbox are enforced.
• Deploy AllowedExtensions, UpdateMode and TelemetryLevel policies; check both Windsurf registry roots.
• Push a PreToolUse logging hook and forward its output to your SIEM.
• Review roles, keys and team settings quarterly against change records.

Standards and references

• Cognition: Windsurf is now Devin Desktop (2 June 2026)
• Cognition: Devin Desktop admin controls reference
• Cognition: Terminal auto-execution
• Cognition: SSO and SCIM
• Cognition: Role-based access control
• Cognition: Model Context Protocol
• Cognition: Enterprise policies
• Cognition: FedRAMP security admin guide
• Cognition: Ignore files

Related NHI Mgmt Group resources: AI IDE and Coding Agent Security Guide · Coding Agent Configuration File Attacks · MCP Security Guide · AI Coding Agent Incident Playbook