Security & Data Handling

Most SE work happens on or around customer data. Logs, screenshots, sandbox records, and exports all pass through your laptop on the way to a demo or POC. This page is the short, firm version of how to use Cursor without creating a problem for yourself or your customer.

What actually leaves your machine

When you use Cursor with the default settings, a few things happen:

• Your chat messages go to the model provider (Anthropic, OpenAI, Google, or whoever the current model comes from).
• The files and snippets you reference with @ travel with the message as context.
• Terminal output the agent reads (for example, sf org list) goes with it too.
• MCP tool calls are executed on your machine, but the arguments to those calls are in the chat transcript.

When you turn Privacy Mode on, Cursor adds protections on top of that. Your code and prompts are not used to train models, and retention is minimized. This is on by default for most business accounts, but it's worth verifying in your setup.

Check your setup

1. In Cursor, open Settings (Cmd+, on macOS, Ctrl+, on Windows).
2. Search for Privacy.
3. Confirm Privacy Mode is enabled.
4. If you're on a Business or Enterprise plan, confirm with your admin that SSO and audit logging are configured.

If you're ever unsure, read the current Cursor privacy and security documentation. It's the source of truth and shifts as features ship.

Things to never paste into chat

Short, unambiguous list. These shouldn't show up in a chat transcript, ever:

• Passwords.
• OAuth access tokens, refresh tokens, or session IDs.
• JWT private keys (the .key files behind your Connected App).
• API keys for any customer system.
• Unredacted customer PII (names, emails, phone numbers, government IDs, account numbers, billing addresses).
• Financial or health data of any kind.
• Screenshots showing PII or credentials.
• The contents of a production sf config get target-org when that org is a customer production.

If something on this list ends up in chat by accident, rotate the secret immediately. Treat the rotation the way you'd treat any security incident.

Redacting customer data before it travels

Most SE debugging involves pasting a log or a screenshot. A lightweight redaction habit keeps you safe without slowing you down.

For logs and CSV exports

Before you paste, replace identifying fields with a placeholder:

Error on record 001... -> Error on record [REDACTED_ACCOUNT_ID]
contact=jane.doe@acme.com -> contact=[REDACTED_EMAIL]

If the log is long, you can ask Cursor itself to help (in a new chat with only the log, so you're not mixing contexts):

Redact all email addresses, phone numbers, personal names, and Salesforce IDs
from the log below. Replace each with [REDACTED_<TYPE>]. Return only the
redacted text, no commentary.

Then take the redacted output to your real debugging chat.

For screenshots

Blur or black-box anything with a name, email, phone number, or record ID before you attach the image. A quick markup in Preview (macOS) or Snipping Tool (Windows) is plenty. For repeated use, a tool like Monosnap or the annotation layer in your screenshot tool does this in a couple of clicks.

For SOQL and DML snippets

Strip the data, keep the shape:

-- Before
SELECT Id, Name, Email, SSN__c FROM Contact WHERE Account.Name = 'Acme Corp'

-- After (fine to paste)
SELECT Id, Name, Email, SSN__c FROM Contact WHERE Account.Name = '[CUSTOMER]'

The shape of the query is almost always the interesting part, not the specific name.

Scoping auto-run

"Auto-run" lets the agent execute commands without asking. It's wonderful on a scratch org you can rebuild in sixty seconds. It is not wonderful pointed at a customer's production org.

A sensible default for SE work:

• Auto-run allowed for read-only commands: sf org list, sf org display, sf project retrieve start, sf apex run test in a scratch org, git status, git diff.
• Confirmation required for writes: sf project deploy start, sf project delete, sf data update, sf data delete, anything with --target-org pointing at a *prod* alias, any git push --force, any rm -rf.

Configure this in Cursor's settings under Auto-run or Terminal command allow-list, depending on your Cursor version. A companion safety rule in your project keeps the agent itself aware:

---
description: Never auto-deploy to production-style aliases
alwaysApply: true
---

- Do not run deploy, delete, or update commands against any alias that
  contains `prod`, `production`, or matches our customer's production
  pattern `*-prod-*` without the user explicitly writing "deploy to
  production" in chat.
- When in doubt, list the target alias and ask before running.

Model choice and what it implies

Different models have different data handling guarantees. In Cursor's default setup with Privacy Mode on, most models keep your data out of training. Enterprise customers can further restrict which models are allowed.

A quick sanity check before your first customer session:

1. Confirm Privacy Mode is on.
2. Confirm the model dropdown is set to a model your security team has approved.
3. If you're working on a regulated customer (healthcare, finance, public sector), confirm with your compliance or customer success contact which models are acceptable for that account.

If you need to lock a model choice at the organization level, your Cursor admin can restrict which models are available in the UI.

MCP servers: treat them like production integrations

When you add an MCP server to Cursor, you're giving the agent a new set of tools it can call on your behalf. Treat them the way you'd treat any integration:

• Only install MCPs from sources you trust.
• For the Salesforce MCP, scope it with --toolsets and --orgs so it can only hit the orgs you want and only with the operations you've approved.
• For Filesystem MCPs, scope them to a specific folder (never / or ~).
• Review the MCP's permissions periodically. MCPs update themselves via @latest tags and may gain new tools over time.

A scoped Salesforce MCP config for customer work looks like:

{
  "mcpServers": {
    "Salesforce ACME UAT": {
      "command": "npx",
      "args": [
        "-y", "@salesforce/mcp@latest",
        "--orgs", "acme-uat",
        "--toolsets", "orgs,metadata,data"
      ]
    }
  }
}

Notice there's no users toolset in that example and no --allow-non-ga-tools. Add those only when you need them, and only on orgs where the blast radius is acceptable.

Customer-facing trust talking points

When a customer asks "is it safe for your team to use Cursor on our sandbox?", you can answer directly:

• Cursor is used in Privacy Mode, which means our prompts and code are not used to train models.
• We scope the Salesforce MCP to the specific org you've given us access to and only the toolsets we need.
• Auto-run is off for destructive commands. Every deploy and data change is reviewed by a human.
• We redact PII before pasting logs into chat.
• Screenshots with customer data are blurred or black-boxed before they travel anywhere.

If the customer wants more detail, point them at Cursor's security documentation and your company's standard AI use policy.

A three-minute self-audit before a customer call

Run through this before you open a customer sandbox in Cursor:

1. Privacy Mode is on.
2. My default target org is not a customer production org.
3. Auto-run is scoped. Writes require confirmation.
4. The MCPs I have installed are the ones I expect.
5. I know which rules in .cursor/rules/ are active.
6. My chat history is cleared of anything from a different customer.

Three minutes of hygiene up front avoids a very awkward conversation later.

What to do next

• Scope your MCPs properly in MCP Setup.
• Lock baseline safety rules into Rules & AGENTS.md.
• Keep secrets out of your repo with Git for Salesforce SEs.