← All articles

Sandbox customer data: what AI coding agents may read

Sandbox customer data should be masked, or kept out of reach, before a partner’s AI coding agent connects to a Salesforce sandbox, because whatever the agent reads ends up in a prompt. A full copy sandbox holds the same dealer prices, contracts and service cases as production. My rule: agents work in scratch orgs and developer sandboxes with seeded test data, a masked partial copy serves integration tests, and the full copy stays with humans. The price is test realism: masking breaks price logic and rare data constellations, so someone has to build a seed data set on purpose.

A full copy sandbox leaks once a coding agent is connected

A coding agent such as Claude Code, Cursor or Agentforce Vibes reads code, and it can also query the org it is logged into. Asked why warranty claims from one dealer fail validation, the agent runs a SOQL query and gets back twenty claims with fault descriptions, dealer names and net prices. Those records are now part of the conversation with the model.

Salesforce describes four sandbox types1:

Sandbox type Data from production Data storage Refresh
Developer none, metadata only 200 MB daily
Developer Pro none, metadata only 1 GB daily
Partial Copy sample defined by a sandbox template 5 GB every 5 days
Full all data and files same as production every 29 days

From a data protection point of view, a full copy is production with a different login URL.

For Claude Code under commercial terms, Anthropic states that it does not train on code or prompts2 and keeps them for 30 days by default. Claude Code also stores session transcripts locally in plaintext for 30 days by default, so a partner laptop holds that query result for a month. Deletion at the end of an engagement belongs in the contract, see partners coding with AI.

Simon Willison calls private data, untrusted content and a way to communicate externally the lethal trifecta3. A full copy brings two: customer data, and text dealers wrote through the portal or by email. A warranty fault description can carry instructions just like the README in Anthropic’s secure deployment guide4, as described in prompt injection in dealer portals. The laptop with internet access supplies the third.

Which data in a manufacturer’s sandbox is sensitive?

Personal data. Contacts at dealers and end customers, technician names, delivery addresses, phone numbers. Salesforce’s scratch org guide says plainly: “Don’t add personal data to scratch orgs.”5 Whether a full copy with personal data may serve development at all is for your data protection officer to decide; this is not legal advice, and the GDPR side is in AI coding tools: works council and GDPR.

Commercial data. Dealer net prices, discount matrices, rebate agreements, sales agreement volumes, warranty terms per dealer. GDPR does not cover them, but the partner building your portal may work for a competitor next year.

Free text. Case descriptions, emails, Chatter posts, work order notes and warranty fault descriptions. They mix both groups and are the hardest to mask without destroying their meaning.

Salesforce says Agentforce Vibes routes prompts through the Einstein Trust Layer6, which “can identify and mask” personal and payment card data, and caps the context window at 115K tokens while masking is active. A dealer net price is neither, so as I read it the price reaches the model unmasked. Claude Code sends prompts to Anthropic or your cloud provider directly, with no Salesforce masking step in between. More in the Einstein Trust Layer and what it protects.

Which environment may an agent use?

I would give each environment a data level and an agent rule:

Environment Data Coding agent Used for
Scratch org empty, plus seed data yes building and unit testing a story
Developer (Pro) sandbox metadata, plus seed data yes shared development, integration stubs
Partial Copy, masked template sample after the mask ran read only, once the mask job is checked integration tests with SAP QA
Full everything no UAT, end to end and load tests

For the masked partial copy Salesforce sells Data Mask & Seed7. The product page lists no price.

For admins

How does Data Mask work?

According to Trailhead (opens in a new tab), Data Mask is a managed package installed in production; a mask configured there appears in a sandbox when it is created or refreshed, and you run it from the Data Mask tab in the sandbox each time. Per field you choose random characters or numbers between a minimum and maximum, a library replacement such as last name, company name or street, or deletion. You can also mask case comments and delete all emails and Chatter feeds. Checkbox, lookup and picklist fields are not supported.

Scratch orgs are empty by default. For small sets Salesforce recommends the data tree commands8, which suit fewer than 3,000 records. Kept in the repository, such a seed set gives every developer and agent the same start.

Masking costs test realism

  • Price logic. Random numbers break the relationship between list price, dealer discount and net price, so a rebate test passes or fails by chance. Pricing needs a synthetic price list: two price lists for one dealer, a zero price for goodwill parts, a second currency.
  • Rare constellations. The machine with 14 years of service history, the asset that moved between dealers, the SAP customer number mapped to two accounts. A seed set only contains them if someone writes them down, so I would ask service and sales for 20 to 30 such cases.
  • Free text. Masked case comments make service history summaries hard to test. Synthetic fault descriptions with your real error codes help.
  • Integration keys. Mask SAP customer and material numbers and tests against SAP QA fail. I would keep them and mask the names around them.
  • Volume. A partial copy is capped at 5 GB, a developer sandbox at 200 MB. Load tests belong in the full copy, run by humans, as do ApexGuru’s runtime ratings, see quality gates for AI code.
  • Upkeep. A new field for a dealer surcharge stays unmasked until someone adds it to the mask, so that check belongs in the release checklist.

Worked example: warranty claims and a partner’s agent

Assume a machine builder with Service Cloud, Field Service and Manufacturing Cloud on one org, SAP as ERP, about 300 dealers and a full copy refreshed monthly. All numbers here are assumptions. The partner wants Claude Code for a warranty validation story and asks for the full copy, “because the real claims are there”.

The client chooses three levels instead:

  • Scratch orgs with about 1,500 seed records: 30 dealers, 200 assets, 400 claims, two synthetic price lists and 25 edge cases from service.
  • An integration sandbox as masked partial copy: names from the library, emails and Chatter deleted, net prices randomised, SAP numbers kept.
  • The full copy for UAT and SAP end to end tests, with no CLI login for the partner’s developers.

The assumed effort is 6 to 10 person days for seed set and mask, plus half a day per release for new fields. In return no partner laptop holds a real claim, and a defect that only shows with real price tiers surfaces in UAT instead of a scratch org. I would accept that trade.

First step: no full copy login on machines that run an agent

The strongest control: no full copy login on any machine where an agent runs. Tool settings come second:

  • Claude Code. Anthropic’s best practices9 say deny rules “hold in every permission mode”, but also that a WebFetch deny does nothing against curl unless the sandbox is on. Deny rules back up the missing login; they do not replace it.
  • Salesforce DX MCP Server. It reaches only explicitly allowlisted10 orgs. According to its README it reaches end of life on 2 November 2026; whatever replaces it needs the same restriction.
  • Agentforce Vibes. Salesforce describes disabling Vibes per org11 under Setup, Agentforce Vibes Extensions, for production. I would do the same for the full copy.
  • Transcripts. Shorten local retention with cleanupPeriodDays and have partners confirm deletion when they leave.

Sandbox levels and pipelines are part of my DevOps and release management work. My test question for every environment: would I accept this data on a partner laptop for a month? Where I would start:

  1. List every sandbox with type, last refresh and who holds a CLI login.
  2. Classify the fields into personal, commercial and free text, with your data protection officer.
  3. Build the seed set with service and sales, including edge cases, and check it into the repository.
  4. Configure the mask for the partial copy and add the field check to every release.
  5. Remove agent access to the full copy and write the levels into the partner annex and the AI rules file; more agent rules are in chapter 8 of the masterclass.
Sources11
  1. 1four sandbox types (opens in a new tab)salesforce.com
  2. 2does not train on code or prompts (opens in a new tab)code.claude.com
  3. 3lethal trifecta (opens in a new tab)simonwillison.net
  4. 4secure deployment guide (opens in a new tab)code.claude.com
  5. 5“Don’t add personal data to scratch orgs.” (opens in a new tab)developer.salesforce.com
  6. 6routes prompts through the Einstein Trust Layer (opens in a new tab)developer.salesforce.com
  7. 7Data Mask & Seed (opens in a new tab)salesforce.com
  8. 8data tree commands (opens in a new tab)developer.salesforce.com
  9. 9best practices (opens in a new tab)code.claude.com
  10. 10explicitly allowlisted (opens in a new tab)developer.salesforce.com
  11. 11disabling Vibes per org (opens in a new tab)developer.salesforce.com

Frequently asked questions

Can an AI coding agent work in a full copy sandbox?

Technically yes, but I would not allow it. A full copy contains all production data, and every record the agent queries goes into the prompt and the local session transcript. Use scratch orgs or developer sandboxes with seeded test data instead.

Does Salesforce Data Mask protect dealer prices?

It can replace number fields with random values in a range you set, so prices can be masked. That breaks the relationship between list price, discount and net price, so pricing logic needs a synthetic price list designed for testing.

Which field types can Data Mask not mask?

According to the Trailhead module on Data Mask, checkbox, lookup and picklist fields are not supported. Relationships therefore stay intact, and the records they point to have to be masked themselves.

How do I get realistic test data into a scratch org?

Scratch orgs are empty by default. Salesforce recommends the data tree export and import commands for small sets of fewer than 3,000 records and the data bulk commands for more. The edge cases have to come from your service and sales teams.

What does Data Mask & Seed cost?

Salesforce's product page lists no price. Ask your account executive for a quote and compare it with the effort of building and maintaining your own seed data set.

Contact

Releases take too long or break too often?

In 30 minutes we walk through your path from sandbox to production and find the step that slows you down most.

What to bring

  • How you deploy today: change sets, a tool or a pipeline, and who does it
  • How many sandboxes, teams and partners deliver into the same org
  • One release that went wrong recently, and what happened

What we clarify

  • Where in the process most time is lost and most errors come from
  • Whether your existing Git platform is enough, for example GitLab, Azure DevOps, GitHub or Bitbucket
  • Which first pipeline step pays off and can then be run by your own team
Book a call (opens Microsoft Bookings in a new tab)

Pick a slot in my calendar via Microsoft Bookings. Prefer to write? Use the form and I’ll get back to you.

Rather talk right away? +49 221 98656758

Send a message

Your details are only used to answer your request. More in the privacy policy.