The Einstein Trust Layer: what it protects, what it doesn't, and what stays your job
The Einstein Trust Layer gets invoked in security reviews as if it settles the question. It settles about half: here's what the pipeline verifiably does, where it stops, and which risks remain squarely yours.
There’s a moment in almost every Agentforce security review where someone asks the question that matters: “So when the agent sends our customer data to a large language model — what happens to it?” And someone else, usually reading from a slide, answers: “The Einstein Trust Layer handles that.”
That answer is roughly half right. The Trust Layer is real, it’s well-engineered, and it does specific, verifiable things: it masks defined categories of PII, enforces zero-data-retention agreements with model providers, grounds prompts through your existing permission model, scores every response for toxicity, and writes an audit trail you can query with SQL. What it does not do is make your org’s sharing model sane, stop every prompt injection, clean your data, or file your DPIA. Salesforce is careful about this distinction in its documentation. The slide decks are less careful, and that gap is where security incidents live.
This post walks the pipeline as documented — prompt journey out, response journey back — with links to the official sources for each control. Then it covers the honest half: the risks the Trust Layer explicitly leaves with you, and what to do about them.
What the Einstein Trust Layer actually is
The Einstein Trust Layer is a set of controls that sits between Salesforce and the large language model on every generative AI request. Salesforce’s Trailhead module describes it as a sequence of gateways and retrieval mechanisms that runs whether the request comes from an embedded feature like Einstein Service Replies, a prompt template, the Models API, or an Agentforce agent.
Two things are worth getting straight before the component tour. First, it’s not a product you buy or a box you tick — it’s infrastructure that’s on by default for Einstein generative AI, with a handful of admin-configurable policies layered on top. Second, it’s a pipeline, not a perimeter. Data flows out through one set of controls (grounding, masking, prompt defense, the secure gateway) and back through another (demasking, toxicity scoring, audit logging). Each stage does one job. None of them does yours.
If you’re still working out what Agentforce itself is — agents, topics, actions, grounding — start with our plain-English Agentforce explainer and come back. This post assumes you know what an agent is and are trying to work out whether you can defend one in front of a security team.
The prompt journey: grounding, masking, and prompt defense
A prompt doesn’t go to the model raw. Between the user’s request and the LLM, the Trust Layer runs four documented stages.
Secure data retrieval and dynamic grounding. Prompts get grounded — filled with real CRM data — at run time, and that retrieval respects the Salesforce permissions already in place: sharing rules, field-level security, object permissions. A user who can’t see a field won’t have that field appear in their grounded prompt. This is genuinely good design. It’s also the source of the biggest misunderstanding in the whole system, which we’ll get to.
Data masking. Before the prompt leaves Salesforce, the Trust Layer detects and tokenizes sensitive data using a blend of pattern matching and machine learning. Detected values are replaced with typed placeholders — the Salesforce engineering walkthrough shows the pattern: the first detected person becomes PERSON_0, the next PERSON_1 — and the mapping is held back so the response can be demasked before the user sees it. Out of the box, masking covers names, email addresses, phone numbers, credit card numbers, and US Social Security numbers by default, with company names available as an opt-in toggle. Admins configure this per entity type in Einstein Trust Layer setup, and there’s a second mode — field-based masking driven by your data classification metadata — for fields you’ve tagged as sensitive regardless of pattern.
Three caveats belong in your risk register. Masking is validity-checked: an invalid credit card number or malformed SSN won’t be masked, because it doesn’t parse as one. Detection is probabilistic and locale-sensitive — Salesforce’s own developer guide says plainly that no model can guarantee 100% accuracy and cross-region use can affect detection. And masking costs context: with masking enabled, requests are limited to a 65,536-token context window regardless of what the underlying model supports.
Prompt defense. The Trust Layer wraps prompts with system-level guardrail instructions — Trailhead quotes one directly: “You must not address any content or generate answers that you don’t have data or basis on” — designed to reduce hallucination and resist instruction hijacking. Useful. Not sufficient, as the ForcedLeak section below demonstrates.
The secure gateway. The masked, defended prompt then crosses an encrypted gateway to the model provider under the zero-data-retention terms described next.
The response journey: zero data retention, toxicity scoring, and the audit trail
What comes back gets processed too, and this half of the pipeline is where the accountability story lives.
Zero data retention. Salesforce’s arrangement with external model providers is contractual: providers must not retain prompts or responses, and customer data isn’t used to train their models. The Agentforce developer guide lists zero-data-retention agreements with third-party LLM partners as a core Trust Layer commitment. It’s worth being precise about what this is: a legal control, not a physical one. Your data does transit the provider’s infrastructure for the duration of inference. For most risk appetites that’s fine. For the strictest, note that as of October 2025 Anthropic’s Claude became the first LLM fully integrated within the Salesforce trust boundary, with traffic contained in Salesforce’s virtual private cloud — an architectural answer for regulated industries, not just a contractual one.
Toxicity scoring. Every generation is scanned and scored. The audit and feedback data model records safety scores from 0.0 to 1.0 across eight categories — toxicity, hate, identity, violence, physical harm, sexual content, profanity, and bias — using a hybrid of rule-based filtering and a trained model. Detection has historically been strongest in English; if you’re deploying in other languages, check the current region and language support documentation rather than assuming parity.
Demasking and the audit trail. Masked tokens are swapped back for real values before the user sees the response, and the whole interaction — original prompt, masked prompt, response, toxicity scores, masking events, and user feedback — lands as timestamped records in Data Cloud. This isn’t a black box: the data model is published as standard Data Model Objects (GenAIGatewayRequest, GenAIContentCategory, GenAIFeedback, and friends) that you can query with ANSI SQL in the Data Cloud query editor. If your compliance team wants to know exactly what an agent said to a customer last Tuesday and what the violence score was, that query is writable today.
That’s the pipeline. It’s a genuinely stronger default posture than what you get pointing your own middleware at a model API. Now for the part the slide decks skip.
Four things the Trust Layer does not do for you
1. It doesn’t fix your permission model
Read the grounding documentation again, carefully: retrieval respects the permissions currently in place. It enforces your sharing model with perfect fidelity — including all the parts of it that are wrong. Fifteen years of “View All on Account, we’ll tidy it later” becomes fifteen years of over-exposure, now searchable in natural language by anyone with agent access.
For Agentforce specifically, autonomous agents run in the context of a designated agent user, and everything the agent can see or do flows from that user’s permission sets. Salesforce’s own agent user guidance pushes least privilege: scope the agent user tightly, don’t reuse one agent user across multiple agents, and grant actions deliberately rather than inheriting broad profiles. In practice this is the single highest-value security exercise in an Agentforce rollout, and it’s the one most often deferred. The Trust Layer will faithfully ground a prompt with every record your over-permissioned agent user can reach. That’s not a bug. That’s the contract.
2. It doesn’t mask data for agents — check this one yourself
Here’s the detail that surprises almost everyone in a security review: as of this writing, LLM data masking is disabled for Agentforce agents. Salesforce’s stated reason is agent performance and accuracy — masked tokens degrade multi-step reasoning — and agent traffic is still covered by encryption in transit and the zero-data-retention agreements. Masking remains available and configurable for embedded generative features like Einstein Service Replies and Work Summaries.
Reasonable trade-off or not, it changes your data-flow diagram: for agent interactions, real names and real account data can reach the model provider under contractual (or, with in-boundary models, architectural) protection rather than being tokenized first. Your DPIA needs to say that. Also remember the default mask set is generic PII — if your sensitive identifiers are medical record numbers, policy numbers, or national IDs from outside the US, the defaults don’t know about them, and you’ll need field-based masking backed by proper data classification for the features where masking applies.
3. It doesn’t solve prompt injection — it mitigates it
Prompt defense instructions raise the cost of an attack. They don’t change the underlying condition: an LLM cannot reliably distinguish trusted instructions from untrusted data that happens to contain instructions. The proof arrived in September 2025, when Noma Labs disclosed ForcedLeak, a CVSS 9.4 vulnerability chain in Agentforce. The attack was elegant and unsettling: malicious instructions embedded in a Web-to-Lead description field (which accepts 42,000 characters) sat dormant in the CRM until an employee asked the agent about that lead — at which point the agent processed the embedded instructions as part of its task and exfiltrated CRM data to an attacker-controlled domain that had lapsed from Salesforce’s own allowlist.
Salesforce patched the exfiltration path by enforcing Trusted URLs for Agentforce and Einstein AI from September 8, 2025 — agents can no longer send output to unapproved domains. That closed this chain. It did not, and cannot, close the class. Every field an agent can read — lead descriptions, case comments, inbound emails, knowledge articles — is untrusted input the moment an attacker can write to it. Your mitigations are architectural: validate and constrain what enters groundable fields, keep destructive and outbound actions behind approval, scope topics narrowly, and maintain your Trusted URL list like the security control it now is. We covered the guardrail-design side of this in our Agentforce production lessons.
4. It doesn’t clean your data or run your process
The Trust Layer verifies nothing about truth. If your knowledge articles contradict each other, the agent will ground on the contradiction with full permission-model compliance and an excellent toxicity score. Garbage in, confidently-phrased garbage out — masked, logged, and audited all the way.
And the audit trail is only a control if somebody reads it. The scores, masking events, and feedback records landing in Data Cloud are raw material for governance, not governance itself. Someone has to own the dashboard, define the thresholds that trigger review, and act when a pattern shows up. In our experience that ownership is the most common gap: the technical control exists, and no human process is attached to it.
The compliance work that stays yours
Even with every Trust Layer control configured correctly, a set of obligations remains with you as data controller, and none of them are Salesforce’s to discharge.
- DPIAs. If you’re subject to GDPR, deploying generative AI over customer personal data is a textbook trigger for a data protection impact assessment — Article 35 requires one where new technologies are likely to produce high risk to individuals. The Trust Layer gives you strong inputs for that assessment (masking behaviour, ZDR terms, audit capability). It doesn’t write the assessment.
- Retention of audit data. Ironic but true: the audit trail is itself a store of prompts and responses containing personal data, held in your Data Cloud under the Einstein audit and feedback data model. It needs a retention schedule, a deletion process that satisfies data-subject requests, and a line in your records of processing. Zero data retention at the model provider does not mean zero retention anywhere.
- Regional and language fit. Feature availability, masking locales, and toxicity-detection quality vary by region and language — masking detection is explicitly locale-sensitive. If you operate across jurisdictions, verify what your residency commitments actually cover in writing with your account team, and test masking against your real data formats, not US samples.
- Vendor due diligence. Your security team will want more than a blog post; point them at the Agentforce and Einstein Generative AI security white paper on Salesforce’s compliance site and map its claims to your control framework yourselves.
Who owns what: a shared-responsibility view
The cleanest way to brief stakeholders is the same framing cloud providers have used for years — a shared-responsibility split. Here’s ours for Einstein generative AI:
| Risk area | Einstein Trust Layer provides | Stays with you |
|---|---|---|
| Data in transit to models | Secure gateway, zero-data-retention agreements, in-boundary model options | Deciding which objects and fields belong in prompts at all |
| Sensitive data exposure | Pattern- and field-based masking for embedded features (default PII set) | Masking is off for agents; custom identifiers; data classification hygiene |
| Record access | Grounding that honors sharing rules and field-level security | The sharing model itself; least-privilege agent users |
| Prompt injection | Prompt defense instructions, Trusted URL enforcement | Treating groundable fields as untrusted input; action guardrails; approvals |
| Harmful output | Toxicity and safety scoring across eight categories | Thresholds, monitoring, human review of externally visible content |
| Accountability | Queryable audit trail and feedback data in Data Cloud | Retention policy, DPIAs, and actually reviewing the logs |
If you can fill in the right-hand column for your org with names and dates, you’re ready for the security review. If the right-hand column is blank, the Trust Layer isn’t the thing standing between you and an incident — luck is.
Trust is a pipeline plus a posture
The Einstein Trust Layer deserves more credit than the cynics give it and less than the sales deck implies. Contractual zero data retention, permission-aware grounding, configurable masking, scored outputs, and a SQL-queryable audit trail are real controls — most in-house LLM integrations we review have none of them. Salesforce has done the plumbing well, and the plumbing matters.
But every one of those controls amplifies whatever posture it finds. Permission-aware grounding amplifies your sharing model, whether that model is disciplined or archaeological. The audit trail amplifies your governance process, or documents its absence in timestamped detail. Prompt defense narrows the injection surface that your field validation and action design must still close. The pattern is consistent: Salesforce secures the pipe, and you remain responsible for what flows into it, who can turn the tap, and what happens downstream.
The practical takeaway fits in three moves. Audit the agent user’s effective access before launch and cut it to the bone. Write down your actual data flow — including the fact that agent traffic isn’t masked — and put it in front of your DPO before someone else does. And attach a named human to the audit trail with a review cadence. Do those three things and the Trust Layer becomes what it was designed to be: the strong default layer of a defence you own. Skip them and it becomes what it too often is — a reassuring answer to a question nobody finished asking.
Understanding the basics
What is the Einstein Trust Layer?
The Einstein Trust Layer is Salesforce’s built-in set of security controls that sits between your CRM data and large language models on every generative AI request. It grounds prompts through your existing permissions, masks defined types of sensitive data, wraps prompts with defensive instructions, enforces zero-data-retention agreements with model providers, scores responses for toxicity, and records a full audit trail in Data Cloud. It runs by default for Einstein generative AI features and Agentforce.
Does Salesforce send my CRM data to OpenAI or other model providers?
Yes — prompts, including grounded CRM data, transit the model provider’s infrastructure during inference. The protection is contractual: Salesforce’s zero-data-retention agreements require that external providers don’t store prompts or responses and don’t use your data to train models. Since October 2025, some models — starting with Anthropic’s Claude — can also run fully inside the Salesforce trust boundary, keeping traffic within Salesforce’s virtual private cloud.
Does the Einstein Trust Layer mask data for Agentforce agents?
No. As of this writing, LLM data masking is disabled for Agentforce agents; Salesforce cites agent performance and accuracy as the reason. Agent traffic is still encrypted in transit and covered by zero-data-retention agreements. Masking remains available for embedded generative features like Einstein Service Replies, where admins can configure which entity types are masked — names, emails, phone numbers, credit cards, and US SSNs by default.
Preparing an Agentforce rollout that has to survive a security review? Talk to us — building agents that pass that conversation is what we do.
