Einstein Trust Layer
The Einstein Trust Layer is the Salesforce-managed runtime layer that sits between customer data and the foundation model when any generative AI feature is invoked.
Definition
The Einstein Trust Layer is the Salesforce-managed runtime layer that sits between customer data and the foundation model when any generative AI feature is invoked. It performs four primary jobs on every prompt: data masking (replacing PII with placeholders before the prompt leaves the Salesforce boundary), dynamic grounding (injecting authoritative source data so the model has the right facts in context), toxicity and bias detection (filtering responses for harmful content), and zero-retention auditing (logging the prompt and response so the customer has a full record of what the model saw and said).
The Trust Layer is the architectural reason Salesforce can call out to third-party LLMs (in-house, OpenAI, Anthropic, others) without exposing customer data to those providers' training pipelines. The masking happens before the request leaves the Salesforce boundary. The unmasking happens after the response returns. The provider sees a tokenized prompt without recognizable names, emails, or account numbers. The contract with each model provider also forbids retention or training on customer prompts. The Trust Layer enforces in software what the contract promises on paper.
How the Trust Layer wraps every Salesforce GenAI call
Masking and unmasking, the round trip
When a generative feature fires, the Trust Layer scans the prompt for personally identifiable information using a combination of pattern matching (email format, credit card number format) and named entity recognition. Each detected entity is replaced with a placeholder token like PERSON_1 or EMAIL_2 before the prompt is sent to the foundation model. The foundation model returns a response that still contains those placeholders. The Trust Layer reverses the mapping, substituting the real values back in before the response reaches the user. The provider never sees the unmasked values.
Dynamic grounding lives inside the Trust Layer
Dynamic grounding is one of the Trust Layer's responsibilities, not a separate feature. When a prompt template references a record, a knowledge article, or a Data Cloud entity, the Trust Layer fetches the data, applies field-level security, and merges the values into the prompt. This is also where retrieval-augmented generation happens for unstructured sources. The grounding step is the largest single mitigation against hallucination, but it is also where context-window costs accumulate. The Trust Layer enforces both the data access rules and the token budget.
Toxicity and bias filters
Before a generated response reaches the user, the Trust Layer runs it through a toxicity classifier and a bias detector. The toxicity classifier flags hate speech, harassment, explicit content, and similar categories. The bias detector flags responses that show demographic bias in language. Responses that fail either filter are blocked and a fallback is returned. The filters are not perfect, especially in non-English content, but they catch the bulk of the obvious failures. Audit logs preserve the original blocked response so the team can review and tune the filter thresholds.
Zero retention and the audit trail
Every prompt sent through the Trust Layer is logged with the user, timestamp, prompt template version, full prompt text, full response text, retrieved grounding sources, and filter decisions. This is the audit trail. The data lives in the customer's Salesforce org, not at the model provider. Salesforce's contract with each provider also requires zero retention on the provider side, meaning the prompt is not stored after the response is returned and is not used for training. The audit trail is the customer's only forensic record when something goes wrong with a generated response.
What the Trust Layer does not do
The Trust Layer reduces a wide range of risks but it does not eliminate hallucination. A grounded, masked, toxicity-clean response can still be factually wrong. The Trust Layer is also not a content review tool. It does not check whether the answer is on-brand or compliant with a customer-specific policy. Those reviews require either tighter prompt design or a human in the loop. Treating the Trust Layer as a guarantee of correctness is the single most common misunderstanding among teams launching their first generative feature.
The full request flow, step by step
A generative call enters the Trust Layer, is enriched with dynamic grounding from records and knowledge, is masked for PII, is sent to the foundation model with retention-disabled headers, returns with a response, has placeholders unmasked, is run through toxicity and bias filters, is logged in the audit trail, and is returned to the user. Each step is logged with its outcome. When a feature misbehaves, the audit trail is the right place to start the debugging, not the model output.
Trust Layer for Bring Your Own Model paths
Custom paths that call external models from Salesforce (BYOM in Einstein Studio, Apex callouts wrapped in prompt templates) inherit some Trust Layer features and not others. Masking and audit logging apply when the call goes through a prompt template. They do not apply when Apex calls an external service directly. Teams building BYOM or direct integrations are responsible for replicating masking, auditing, and toxicity filtering in their own code if the use case requires those protections.
How to configure and monitor the Einstein Trust Layer
The Trust Layer is on by default for any feature using a Salesforce prompt template. Configuration is mostly about reviewing the defaults, customizing the masking dictionary, and setting up audit-trail visibility.
- Confirm the Trust Layer is enabled for the org
Setup, Einstein, Trust Layer. The feature should show enabled for any org with Einstein Generative AI provisioned. If it does not, escalate to the AE; this is platform plumbing, not customer-side configuration.
- Review the default masking rules
The Trust Layer ships with PII detection for names, emails, phone numbers, credit cards, SSNs, and addresses. Review the list. If the org handles industry-specific identifiers (case numbers, member IDs), check whether they are covered.
- Customize masking with extensions
For custom identifiers, configure additional masking patterns. Salesforce exposes this through the Einstein Trust Layer configuration. Test with sample records before enabling in production.
- Set up audit trail access
Grant the Einstein Generative AI Audit permission to the security or compliance team. The audit trail lives in Setup, Einstein, Trust Layer, Audit Logs. Schedule weekly review.
- Test with sample prompts and review the trail
Run several test prompts that include PII, retrieve the entries from the audit log, and confirm masking, grounding, and filter behavior match expectations. Catch surprises in test, not production.
The PII detection and replacement layer. Covers standard categories by default; supports custom patterns for industry-specific identifiers.
The runtime data injection layer. Pulls record data, knowledge, and Data Cloud entities into prompts based on the template definition.
The response-side filter that blocks harmful content. Threshold and category coverage depend on the underlying classifier version.
Defends against prompt injection attempts by detecting suspicious patterns in user-supplied input before the prompt is built.
The full record of every Trust Layer transaction. Required for compliance and forensic review. Lives in the customer's org, not at the provider.
- Over-masking strips context the model needs to answer. A prompt with five PERSON tokens often confuses the model about who is who. Tune the masking categories rather than maximizing them.
- The Trust Layer does not prevent hallucinations. Grounded, masked, filtered responses can still be factually wrong. Plan for residual hallucination review.
- Toxicity filters are weaker in non-English content. Multi-language deployments need tighter prompt design or human review on responses in low-resource languages.
- The audit trail is the only forensic record when something goes wrong. Make sure the security team has access before the first incident, not after.
- BYOM and direct Apex callouts bypass parts of the Trust Layer. The team owns masking, filtering, and auditing in those paths if the use case needs them.
Trust & references
Cross-checked against the following references.
- Einstein Trust LayerSalesforce Help
- Einstein Generative AI SecuritySalesforce Help
Straight from the source - Salesforce's reference material on Einstein Trust Layer.
- Einstein Trust Layer overviewSalesforce Help
- Prompt Builder overviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Einstein Trust Layer?
Q2. What protections does the Trust Layer provide?
Q3. Why does the Trust Layer matter for enterprise generative AI?
Discussion
Loading discussion…