Windsurf Enterprise Rbac

Devin Desktop Enterprise Access Control

Overview

Build an evidence-backed enterprise access model for Devin Desktop, the current name for Windsurf. RBAC is an Enterprise feature; verify plan eligibility and current control labels in the admin console before promising a capability.

Prerequisites

• An Enterprise organization and an authenticated administrator
• Named identity, security, billing, and developer-experience owners
• The organization's identity lifecycle, least-privilege, and break-glass requirements
• Current first-party documentation and contract terms for any mutable product claim

Authentication

Perform administrative changes only from a protected enterprise-admin session. Treat SAML metadata, SCIM tokens, service keys, recovery codes, cookies, and exported member data as secrets; keep values in approved identity or secret systems and place only redacted references in deliverables.

Tool Use

• Use Read to inspect only the repository policy and configuration files needed for the access design.
• Use Write only for a new access matrix or rollout artifact explicitly requested by the user.
• Use Edit for bounded changes to existing policy documents, preserving unrelated work and all credential boundaries.

Instructions

Step 1: Establish the administrative boundary

Record the organization, administrator group, identity provider, affected teams, repositories, and environments. Use the Devin Desktop admin console under the team settings surface; do not invent SAML endpoints or API scopes from examples.

Step 2: Design roles from documented permissions

Devin Desktop provides default Admin and User roles and supports custom Enterprise roles. Start the User role with no administrative permissions, then grant only the documented actions required for the job.

Map needs against the current permission families:

• Attribution and analytics read access
• Team read, update, delete, and invite actions
• Index read, create, update, delete, and management actions
• SSO read and write actions
• Service-key read, create, update, and delete actions
• Billing read and write actions
• Role read, create, update, and delete actions

Never copy a role name from this skill without checking the live permissions list. The product can add, rename, or split permissions.

Step 3: Connect SSO and SCIM lifecycle

Use SSO for authentication and SCIM for automated provisioning, deprovisioning, and group-to-team mapping where supported. Define:

1. The IdP group that grants base access.
2. The IdP groups that map to Devin Desktop teams.
3. The role each team receives.
4. The offboarding event and maximum revocation time.
5. A tested break-glass path with a named owner and audit requirement.

Enable enforcement only after a pilot administrator and a non-administrator complete sign-in, role, and recovery tests.

Step 4: Configure team feature controls

Review each organization-level control in the current admin guide and record the chosen state, owner, and reason. Current control families include:

• Model access by specific model or provider, plus the initial Cascade default
• Maximum terminal auto-execution level: Disabled, Allowlist Only, Auto, or Turbo
• Team terminal allowlists and denylists, with deny taking precedence
• MCP availability and approved-server policy
• App Deploys, conversation sharing, PR-review integration, and knowledge-base access

Prefer the lowest terminal level that supports the workflow. Review MCP servers as external capabilities because they may create or mutate resources outside Devin Desktop.

Step 5: Separate product controls from external enforcement

For every requirement, identify the authoritative enforcement point. Repository permissions, branch protection, identity-provider policy, secret management, deployment approval, and data-loss controls remain authoritative even when Devin Desktop provides a related toggle.