Does Einstein Trust Layer Mask Agent Data?
No. Salesforce documents that LLM data masking is disabled for agents, a deliberate tradeoff for agent performance and accuracy. Masking still applies to embedded generative AI features, and the rest of the Trust Layer still applies to agents.
Last updated:
Does the Einstein Trust Layer mask data for Agentforce agents?
No. Salesforce documents that LLM data masking through the Einstein Trust Layer is disabled for agents. That covers both pattern-based and field-based masking. If you have assumed that turning on masking policies in Einstein Trust Layer setup also covers your Agentforce agents, it does not.
This surprises people because the Trust Layer is usually described as a single protective envelope around every generative AI call in Salesforce. It is more accurate to think of it as a set of separate controls with separate scopes. Masking is one control. It is the one that does not currently extend to agents. The others do.
The rest of this page sets out what Salesforce says, where masking does still apply, why Salesforce turned it off for agents, and what to check in your own org. Every claim is linked to a Salesforce source at the end.
What still applies to agent traffic
Masking being off does not mean nothing is protecting agent traffic. It means one specific control is not in the path. Salesforce's Trust Layer documentation describes several controls, and they have different scopes.
| Trust Layer control | Applies to agents? | What it does |
|---|---|---|
| LLM data masking | No, disabled for agents | Detects and masks selected PII and PCI values in the prompt before it reaches the model. |
| Zero-retention agreements | Yes | Salesforce's contracts with model providers bar them from storing prompts or using them for training. |
| Toxicity scoring | Yes | Scores prompts and responses for harmful content and records the score. |
| Audit trail | Yes | Records generative AI interactions, including trust signals, for later review. |
| Secure data retrieval | Yes | Grounding respects the running user's permissions, so an agent retrieves only what that user can see. |
The distinction that matters for a security review is between a contractual control and an architectural one. A zero-retention agreement is a promise by the provider not to keep your data. Masking is a change to what you send in the first place. Both are legitimate controls. They fail differently, and a regulator or an internal auditor will usually ask about both.
Where masking does still apply
LLM data masking is available for embedded generative AI features, and Salesforce names Einstein Service Replies and Einstein Work Summaries as examples. Those are configured in Einstein Trust Layer setup, and the policies you set there govern those features.
This is why two teams in the same company can reach opposite conclusions. A team that adopted generative AI through embedded features has masking, saw it in Setup, and reasonably assumes it is global. A team that built agents does not have it. Both are looking at the same Setup page.
If your generative AI footprint is entirely embedded features today, masking is available to you now. If you are moving from embedded features to agents, treat that as a change in your data-protection posture that deserves its own review, not as a simple feature upgrade.
What LLM data masking covers when it is available
Knowing the scope matters even where masking is on, because the default set is narrower than most people assume. Trailhead's configuration unit documents the defaults.
| Data type | Default state | Note |
|---|---|---|
| Name | Masked by default | Detected by pattern. |
| Email address | Masked by default | Detected by pattern. |
| Phone number | Masked by default | Validated against phone number format rules. |
| Credit card | Masked by default | Validated against card number rules. |
| United States Social Security Number | Masked by default | United States format. Other national identifiers are not equivalent. |
| Company name | Available to enable | Off unless you turn it on. |
Two properties of this design are worth writing into your own risk notes. First, detection is validated: Trailhead states that where a data type has format and validation rules, the value is checked, and an item that is not a valid value for its type is not masked. That is correct engineering, and it also means a deliberately malformed or unusually formatted value can pass through.
Second, Salesforce is explicit about the accuracy ceiling. Its documentation states that although detection models tested effectively, no model can guarantee 100% accuracy, and that cross-region and multi-country use cases can affect the ability to detect specific data patterns. Salesforce made the same point publicly in its own blog on LLM data masking, which discusses the tradeoffs of the technique rather than presenting it as complete protection.
In practice the gap is rarely the standard fields. It is the custom field holding a case note, a claim description, or a clinical detail in free text, where the sensitive value has no recognisable pattern at all. See PII masking for the underlying definition.
Why Salesforce disabled masking for agents
Salesforce has given a reason, and it is a reasonable engineering one. The Agentforce Privacy FAQ, published June 2025, states that masking is currently disabled for Agentforce to improve the performance and accuracy of agents. Salesforce's June 2025 blog on LLM data masking explains the mechanism: masking adds latency to planner and action workflows.
There is an accuracy dimension as well as a latency one. An agent plans across several steps. If a customer name is replaced by a placeholder at step one, the planner reasons over the placeholder for every later step, and the quality of that reasoning degrades. Masking a single-shot summarisation call is comparatively easy. Masking a multi-step agent loop without damaging the loop is genuinely harder.
Read the word "currently" in Salesforce's wording as meaningful. This is a stated tradeoff at a point in time, not a permanent architectural position, and it is the kind of thing that changes between releases. Re-check it each release rather than relying on this page or any other third-party page indefinitely.
What this means in a regulated org
For most teams this is a fact to record, not a reason to stop. The practical consequence is that the masking control you may have cited in a design document does not cover the agent path, so either the control or the document needs to change.
Three questions tend to come up in review. Which fields can each agent actually reach, given the permissions of the user it runs as? Of those fields, which contain regulated data such as PII, PHI or cardholder data? And for the ones that do, what control is in the request path today, now that masking is not?
In healthcare specifically, be careful about how the answer is phrased. Pattern masking addresses a subset of identifiers, not all of them. No pattern-based technique can mask a biometric identifier or a full-face photograph, so any claim of complete identifier coverage is wrong regardless of which product makes it. See AI for healthcare for how that boundary is usually drawn, and AI governance for the policy layer around it.
It is also worth separating this question from a related one that often gets merged into it. Whether an agent can be manipulated into revealing data through its inputs is a different problem from whether values are masked on the way out. See prompt injection for that distinction, and AI guardrails for the broader control set.
How to verify this in your own org
Do not take this from a vendor page, including this one. Four checks, roughly twenty minutes:
- In Setup, open Einstein Setup and the Einstein Trust Layer page. Note which masking policies are enabled and, importantly, which features the page says they cover.
- In Agentforce Builder, list your active agents. For each one, note the actions it can call and the objects and fields those actions touch. That is the data that can reach a model.
- Check which users your agents run as, and what those users can see. Grounding respects the running user's permissions, so an over-permissioned running user quietly widens the agent's reach.
- Review the generative AI audit trail for a real agent interaction and confirm you can reconstruct what was sent. If you cannot evidence it, you cannot attest to it.
Pair this with which LLM Agentforce uses, since the answer determines which provider agreement governs the traffic, and with whether Agentforce requires Data 360, because Trust Layer storage of prompts and trust signals depends on it.
How GPTfy handles masking for agent calls
GPTfy applies masking in its own request path rather than relying on the platform's, so the control does not depend on which Salesforce feature is making the call. Four layers are available: field-level rules, regular expressions, blocklists and Apex for cases the first three cannot express. Note that a blocklist masks a matched value; it does not stop the prompt from running.
Raw data stays in Salesforce and masked data flows to your AI provider, through your own Named Credential, so the provider relationship and the zero-retention configuration are yours to set. Every call writes a Security Audit Record, which is what most reviewers actually want when they ask whether you can evidence a generative AI interaction after the fact.
This complements the platform controls rather than replacing them. More detail on data masking, audit trails and governance, bringing your own model, and the step-by-step guide to data masking for Salesforce AI.
Sources
Every statement about Salesforce behaviour on this page comes from one of these. Salesforce Help pages are updated without a visible date, so re-check them each release rather than relying on the date at the top of this page.
- Salesforce Help: Large Language Model Data Masking
- Agentforce Developer Guide: Data Masking
- Agentforce Developer Guide: Trust Layer
- Salesforce Help: Einstein Trust Layer, Designed for Trust
- Salesforce Help: Trust and Agentforce
- Trailhead: Configure LLM Data Masking Policies in Einstein AI
- Salesforce blog: LLM Data Masking, Silver Bullet or Double-Edged Sword?
- Salesforce Agentforce Privacy FAQ (June 2025), which states that data masking is currently disabled for Agentforce to improve the performance and accuracy of agents.
Agentforce, Einstein, Data 360 and Salesforce are trademarks of Salesforce, Inc. GPTfy is not affiliated with or endorsed by Salesforce, Inc. Last reviewed 21 September 2026.
Key takeaways
Masking is off for agents
Salesforce documents that LLM data masking is disabled for agents. Both pattern-based and field-based masking are covered by that statement.
It is a stated tradeoff
Salesforce says masking is disabled to improve agent performance and accuracy, because masking adds latency to planner and action workflows.
The rest of the Trust Layer still applies
Zero-retention agreements with model providers, toxicity scoring and the audit trail are not the same control as masking, and they still cover agent traffic.
Embedded features are different
Masking is available for embedded generative AI features such as Einstein Service Replies and Einstein Work Summaries, configured in Einstein Trust Layer setup.
GPTfy position
Masking applied before the model call, in your org, through your own Named Credential, with a Security Audit Record written for every call.
FAQ
No. Salesforce documents that LLM data masking is disabled for agents. Salesforce's Agentforce Privacy FAQ states masking is turned off to improve the performance and accuracy of agents, and its June 2025 blog explains that masking adds latency to planner and action workflows. The rest of the Trust Layer still applies to agent traffic.
The data an agent grounds on is sent to the model as retrieved, rather than passed through the Trust Layer's pattern and field masking first. Salesforce's zero-retention agreements with model providers still apply, so the provider is contractually barred from storing or training on it. Contractual control and masking are different controls.
To embedded generative AI features rather than agents. Salesforce names Einstein Service Replies and Einstein Work Summaries as examples, and those are configured in Einstein Trust Layer setup. If your only exposure to generative AI is through those embedded features, masking is available and you can turn it on.
Trailhead documents Name, Email Address, Phone Number, Credit Card and United States Social Security Number as masked by default, with Company Name available to enable. Detection uses format and validation rules, so an item that is not a valid value for its type is not masked.
No, and Salesforce says so directly. Its documentation states that although the detection models tested effectively, no model can guarantee 100% accuracy, and that cross-region and multi-country use cases can affect the ability to detect specific data patterns. Custom fields holding sensitive data in free text are the common blind spot.
Open Einstein Setup and review the Einstein Trust Layer page to see which masking policies are on and which features they cover. Then list your active agents in Agentforce Builder and note which objects and fields each one can reach, because that is the data an agent can send to a model.
GPTfy applies its own masking layers before the model call rather than relying on the platform's, using field-level rules, regex, blocklists and Apex. Raw data stays in Salesforce and masked data flows to your AI provider through your own Named Credential, and each call writes a Security Audit Record.
See masking applied before the model call
Walk through the four masking layers and the Security Audit Record on your own objects and fields.
Explore More
Which LLM Does Agentforce Use?
The default managed mix, the org-level options, and per-agent overrides.
Does Agentforce Require Data Cloud?
What needs Data 360, what does not, and where the Trust Layer depends on it.
Data Masking
Field-level rules, regex, blocklists and Apex applied before the model call.
Audit Trails and Governance
Security Audit Records for every generative AI interaction.
What Is Data Masking for Salesforce AI?
The concepts, the techniques, and where each one fits.
Bring Your Own Model in Salesforce
Any model through your own Named Credential, inside your org.