Sandbox-Kundendaten: Was KI-Coding-Agenten lesen dürfen

Sandbox-Kundendaten sollten maskiert oder ganz außer Reichweite sein, bevor sich der KI-Coding-Agent eines Partners mit einer Salesforce-Sandbox verbindet, denn alles, was der Agent liest, landet in einem Prompt. Eine Full-Copy-Sandbox enthält dieselben Händlerpreise, Verträge und Servicefälle wie die Produktion. Meine Regel: Agenten arbeiten in Scratch Orgs und Developer-Sandboxes mit Seed-Testdaten, eine maskierte Partial Copy dient den Integrationstests, die Full Copy bleibt Menschen vorbehalten. Der Preis ist Testrealismus. Maskierung zerstört Preislogik und seltene Datenkonstellationen, also muss jemand einen Seed-Datensatz bewusst bauen.

Mit einem Coding-Agent wird die Full-Copy-Sandbox zum Datenleck

Ein Coding-Agent wie Claude Code, Cursor oder Agentforce Vibes liest Code, und er kann die Org abfragen, in der er angemeldet ist. Fragt ein Entwickler, warum Garantieanträge eines Händlers an der Validierung scheitern, setzt der Agent eine SOQL-Abfrage ab und bekommt zwanzig Anträge mit Fehlerbeschreibung, Händlername und Nettopreis zurück. Diese Datensätze sind jetzt Teil des Gesprächs mit dem Modell.

Salesforce beschreibt vier Sandbox-Typen1:

Sandbox-Typ	Daten aus Produktion	Datenspeicher	Refresh
Developer	keine, nur Metadaten	200 MB	täglich
Developer Pro	keine, nur Metadaten	1 GB	täglich
Partial Copy	Auszug laut Sandbox-Vorlage	5 GB	alle 5 Tage
Full	alle Daten und Dateien	wie Produktion	alle 29 Tage

Aus Datenschutzsicht ist eine Full Copy die Produktion unter einer anderen Login-URL.

Für Claude Code unter kommerziellen Bedingungen schreibt Anthropic, dass es nicht mit Code oder Prompts trainiert2 und diese standardmäßig 30 Tage aufbewahrt. Claude Code speichert Sitzungsprotokolle außerdem standardmäßig 30 Tage im Klartext auf dem Rechner. Ein Partner-Laptop hält das Abfrageergebnis also einen Monat lang. Die Löschung bei Projektende gehört in den Vertrag, siehe Partner coden mit KI.

Simon Willison nennt die Kombination aus privaten Daten, nicht vertrauenswürdigen Inhalten und einem Weg nach außen die „lethal trifecta“3. Eine Full Copy bringt zwei davon mit: Kundendaten aus der Produktion und Texte, die Händler über das Portal oder per E-Mail geschrieben haben. Eine Fehlerbeschreibung im Garantieantrag kann Anweisungen enthalten wie die README im Leitfaden zum sicheren Betrieb4 von Anthropic, mehr dazu in Prompt Injection im Händlerportal. Der Laptop mit Internetzugang liefert das dritte Element.

Welche Daten in der Sandbox eines Herstellers sind heikel?

Personenbezogene Daten. Ansprechpartner bei Händlern und Endkunden, Namen der Servicetechniker im Außendienst, Lieferadressen, Telefonnummern. Der Scratch-Org-Leitfaden von Salesforce sagt es deutlich: „Don’t add personal data to scratch orgs.“5 Ob eine Full Copy mit personenbezogenen Daten überhaupt für die Entwicklung genutzt werden darf, entscheidet Ihr Datenschutzbeauftragter. Das hier ist keine Rechtsberatung; die DSGVO-Seite steht in KI-Coding-Tools: Betriebsrat und DSGVO.

Kaufmännische Daten. Händlernettopreise, Rabattmatrizen, Bonusvereinbarungen, Mengen in Sales Agreements, Garantiekonditionen je Händler. Die DSGVO schützt sie nicht, aber der Partner, der heute Ihr Portal baut, arbeitet nächstes Jahr vielleicht für einen Wettbewerber.

Freitext. Fallbeschreibungen, E-Mails, Chatter-Beiträge, Notizen an Arbeitsaufträgen und Fehlerbeschreibungen in Garantieanträgen. Sie mischen beide Gruppen und lassen sich am schwersten maskieren, ohne ihren Sinn zu zerstören.

Laut Salesforce leitet Agentforce Vibes Prompts durch den Einstein Trust Layer6, der personenbezogene Daten und Kartendaten erkennen und maskieren kann; bei aktiver Maskierung ist das Kontextfenster auf 115.000 Token begrenzt. Ein Händlernettopreis ist weder das eine noch das andere, er erreicht das Modell also nach meinem Verständnis unmaskiert. Claude Code schickt Prompts direkt an Anthropic oder Ihren Cloud-Anbieter, ohne Maskierungsschritt von Salesforce. Mehr dazu in Einstein Trust Layer: was er schützt.

Welche Umgebung darf ein Agent nutzen?

Ich würde jeder Umgebung eine Datenstufe und eine Agentenregel geben:

Umgebung	Daten	Coding-Agent	Zweck
Scratch Org	leer, plus Seed-Daten	ja	Story bauen und Unit-Tests
Developer-(Pro-)Sandbox	Metadaten, plus Seed-Daten	ja	gemeinsame Entwicklung, Schnittstellen-Stubs
Partial Copy, maskiert	Auszug nach Maskierungslauf	nur lesend, nach geprüftem Maskierungsjob	Integrationstests mit SAP-QS-System
Full	alles	nein	UAT, End-to-End- und Lasttests

Für die maskierte Partial Copy verkauft Salesforce Data Mask & Seed7. Einen Preis nennt die Produktseite nicht.

Für Admins

Wie arbeitet Data Mask?

Laut Trailhead (öffnet in einem neuen Tab) ist Data Mask ein Managed Package, das in der Produktion installiert wird. Eine dort konfigurierte Maskierung erscheint in der Sandbox, wenn diese angelegt oder aktualisiert wird, und Sie starten sie jedes Mal im Data-Mask-Tab der Sandbox. Pro Feld wählen Sie Zufallszeichen oder Zufallszahlen zwischen Minimum und Maximum, einen Ersatz aus einer Bibliothek wie Nachname, Firmenname oder Straße, oder Löschen. Fallkommentare lassen sich maskieren, E-Mails und Chatter-Feeds komplett löschen. Checkbox-, Lookup- und Picklist-Felder werden nicht unterstützt.

Scratch Orgs sind standardmäßig leer. Für kleine Mengen empfiehlt Salesforce die data-tree-Befehle8, passend für weniger als 3.000 Datensätze. Liegt ein solcher Seed-Datensatz im Repository, starten alle Entwickler und Agenten vom selben Stand.

Maskierung kostet Testrealismus

• Preislogik. Zufallszahlen zerstören den Zusammenhang zwischen Listenpreis, Händlerrabatt und Nettopreis, ein Test der Bonusberechnung besteht dann zufällig oder eben nicht. Preislogik braucht eine eigens gebaute Testpreisliste: zwei Preislisten für einen Händler, ein Nullpreis für Kulanzteile, eine zweite Währung.
• Seltene Konstellationen. Die Maschine mit 14 Jahren Servicehistorie, die Anlage, die den Händler gewechselt hat, die SAP-Kundennummer an zwei Accounts. Solche Fälle stehen nur im Seed-Datensatz, wenn jemand sie aufschreibt. Ich würde Service und Vertrieb um 20 bis 30 davon bitten.
• Freitext. Maskierte Fallkommentare machen Zusammenfassungen der Servicehistorie schwer testbar. Synthetische Fehlerbeschreibungen mit den Fehlercodes aus Ihrem Service helfen.
• Schnittstellenschlüssel. Werden SAP-Kunden- und Materialnummern maskiert, scheitern die Tests gegen das SAP-QS-System. Ich würde sie behalten und die Namen drumherum maskieren.
• Volumen. Eine Partial Copy ist auf 5 GB begrenzt, eine Developer-Sandbox auf 200 MB. Lasttests gehören in die Full Copy, durchgeführt von Menschen, ebenso die Laufzeitbewertung von ApexGuru, siehe Quality Gates für KI-Code.
• Pflege. Ein neues Feld für einen Händlerzuschlag bleibt unmaskiert, bis jemand es in die Maskierung aufnimmt. Diese Prüfung gehört in die Release-Checkliste.

Rechenbeispiel: Garantieanträge und der Agent des Partners

Nehmen wir einen Maschinenbauer mit Service Cloud, Field Service und Manufacturing Cloud auf einer Org, SAP als ERP, rund 300 Händlern und einer Full Copy mit monatlichem Refresh. Alle Zahlen in diesem Szenario sind Annahmen. Der Partner möchte Claude Code für eine Story zur Validierung von Garantieanträgen einsetzen und bittet um Zugriff auf die Full Copy, „weil dort die echten Anträge liegen“.

Der Kunde entscheidet sich stattdessen für drei Stufen:

• Scratch Orgs mit rund 1.500 Seed-Datensätzen: 30 Händler, 200 Anlagen, 400 Garantieanträge, zwei synthetische Preislisten und 25 Sonderfälle aus dem Service.
• Eine Integrationssandbox als maskierte Partial Copy: Namen aus der Bibliothek, E-Mails und Chatter gelöscht, Nettopreise zufällig, SAP-Nummern erhalten.
• Die Full Copy für UAT und SAP-End-to-End-Tests, ohne CLI-Login für die Entwickler des Partners.

Der angenommene Aufwand: 6 bis 10 Personentage für Seed-Datensatz und Maskierung, dazu ein halber Tag pro Release für neue Felder. Dafür liegt auf keinem Partner-Laptop ein Antrag aus der Produktion, und ein Fehler, der nur mit echten Preisstaffeln auftritt, zeigt sich im UAT statt in der Scratch Org. Diesen Tausch würde ich eingehen.

Erster Schritt: kein Full-Copy-Login auf Rechnern mit Agent

Die wirksamste Kontrolle: Auf keinem Rechner, auf dem ein Agent läuft, existiert ein Login für die Full Copy. Werkzeugeinstellungen sichern das ab:

• Claude Code. Laut Anthropics Best Practices9 gelten Deny-Regeln in jedem Berechtigungsmodus. Dieselbe Seite sagt aber, dass eine WebFetch-Sperre nichts gegen curl ausrichtet, solange die Sandbox nicht aktiv ist. Deny-Regeln ergänzen den fehlenden Login, ersetzen ihn aber nicht.
• Salesforce DX MCP Server. Er erreicht nur ausdrücklich freigegebene10 Orgs. Laut README erreicht er am 2. November 2026 das Ende seiner Lebensdauer, und was ihn ersetzt, braucht dieselbe Einschränkung.
• Agentforce Vibes. Salesforce beschreibt, wie man Vibes pro Org abschaltet11, im Setup unter Agentforce Vibes Extensions, für Produktions-Orgs. Ich würde das auch für die Full Copy tun.
• Protokolle. Verkürzen Sie die lokale Aufbewahrung mit cleanupPeriodDays und lassen Sie sich von Partnern bei Projektende die Löschung bestätigen.

Sandbox-Stufen und Pipelines gehören zu meiner Arbeit in DevOps und Release-Management. Meine Prüffrage für jede Umgebung lautet: Würde ich diese Daten einen Monat lang auf einem Partner-Laptop akzeptieren? So würde ich anfangen:

1. Alle Sandboxes auflisten mit Typ, letztem Refresh und wer einen CLI-Login hat.
2. Felder einteilen in personenbezogen, kaufmännisch und Freitext, zusammen mit dem Datenschutzbeauftragten.
3. Den Seed-Datensatz bauen mit Service und Vertrieb, inklusive Sonderfällen, und ins Repository einchecken.
4. Die Maskierung konfigurieren für die Partial Copy und die Feldprüfung in jedes Release aufnehmen.
5. Agentenzugriff auf die Full Copy entfernen und die Stufen in die Partneranlage und die KI-Regeldatei schreiben; weitere Agentenregeln stehen in Kapitel 8 der Masterclass.

Quellen11

1. 1vier Sandbox-Typen (öffnet in einem neuen Tab)salesforce.com
2. 2nicht mit Code oder Prompts trainiert (öffnet in einem neuen Tab)code.claude.com
3. 3„lethal trifecta“ (öffnet in einem neuen Tab)simonwillison.net
4. 4Leitfaden zum sicheren Betrieb (öffnet in einem neuen Tab)code.claude.com
5. 5„Don’t add personal data to scratch orgs.“ (öffnet in einem neuen Tab)developer.salesforce.com
6. 6leitet Agentforce Vibes Prompts durch den Einstein Trust Layer (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Data Mask & Seed (öffnet in einem neuen Tab)salesforce.com
8. 8data-tree-Befehle (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Best Practices (öffnet in einem neuen Tab)code.claude.com
10. 10ausdrücklich freigegebene (öffnet in einem neuen Tab)developer.salesforce.com
11. 11Vibes pro Org abschaltet (öffnet in einem neuen Tab)developer.salesforce.com