jeremylongshore Devin Desktop Security Basics
Overview
Devin Desktop is the current name for Windsurf. Secure it with layered controls: repository permissions and secret management are authoritative; .codeiumignore, Rules, and prompts reduce context exposure but do not replace access control.
Prerequisites
- A version-controlled workspace and clean working tree
- The organization's data-classification and secret-handling policy
- Authorization to inspect configuration without collecting secret values
Tool Use
- Use
Readto inspect only the repository files and configuration needed for the request. - Use
Grepto locate relevant settings, rules, logs, or code without broad collection. - Use
Writeonly for a new artifact the user requested; never write credentials or unreviewed production configuration.
Instructions
Step 1: Map trust boundaries
Record repository sensitivity, connected organizations, enabled models, MCP servers, Hooks, terminal permissions, remote indexing, and deployment integrations. Identify which controls are local, repository-owned, or centrally administered.
Step 2: Configure context exclusions
Create .codeiumignore at the repository root using gitignore syntax. Include only project-relevant patterns, for example:
.env
.env.*
*.pem
*.key
credentials/
secrets/
customer-data/
dist/
node_modules/
Windsurf also honors .gitignore, and Enterprise administrators can add a global .codeiumignore under ~/.codeium/. Verify behavior with a harmless canary filename; do not place a real secret in the test.
Step 3: Enforce durable behavior
Use repository AGENTS.md or .devin/rules/*.md to require secure coding, validation, least privilege, and explicit approval for risky operations. Keep each workspace Rule within the documented 12,000-character limit and use the correct trigger: mode.
Step 4: Review tools and automation
- Disable unused MCP servers and tools.
- Prefer provider OAuth or environment-backed secrets over literal values in
mcp_config.json. - Review Hooks as executable policy code and fail closed where required.
- Keep protected branches, code owners, CI, and deployment approvals outside the model's discretion.
- Require human approval for production, destructive, identity, and billing mutations.
Step 5: Respond to exposure
If a secret appears in a prompt, output, log, diff, or diagnostic bundle, treat it as exposed: stop sharing, revoke or rotate it through the provider, remove it from history where authorized, and document the incident. Adding an ignore rule alone is not remediation.
Step 6: Verify
Confirm ignored paths are absent from context, protected branches still require review, MCP tools match policy, Hooks run on representative success and failure paths, and no configuration file contains credential material.
Output
Deliver a security review with context boundaries, ignored paths, organization policy, MCP and Hook exposure, repository protections, detected secret locations without values, remediation owners, and verification evidence. Mark controls as preventive, detective, or corrective.
Error Handling
| Issue | Response |
|---|---|
| Ignored file still appears | Check syntax, location, gitignore interaction, and current indexing state |
| MCP requires a token | Use provider OAuth or an approved secret store; never commit the value |
| Hook blocks legitimate work | Preserve the event, fix the narrow rule, and retest failure handling |
| Compliance claim is uncertain | Link first-party evidence and route the decision to security or legal |
Examples
Finding: ".env.production was not excluded. Add .env.*, rotate any exposed credential, verify with a harmless canary, and retain protected-branch review as the enforcement boundary."
Resources
- Focused first-party references
- Windsurf Ignore
- Rules and
AGENTS.md - Hooks
- MCP
Related Skill
Continue with windsurf-data-handling to build a regulated-data inventory, verify mutable vendor claims, and record control evidence without exposing sensitive values.