The Salesforce AI Trust Layer: What It Does and Doesn't Protect

What the Trust Layer Actually Is

The Einstein Trust Layer is Salesforce's collective term for the set of security and safety controls that sit between Salesforce data and the external large language models used by Einstein and Agentforce features. It is not a single technical component — it is a suite of controls: a data de-identification pipeline, a toxicity filter, an audit logging system, and a set of contractual and architectural commitments about how Salesforce manages the LLM vendors it partners with.

The core claim of the Trust Layer is that your Salesforce data is never used to train the LLMs that Einstein and Agentforce use. When your data is sent to an external LLM provider for inference, Salesforce contractually prohibits that provider from using the data to retrain or fine-tune their model. This is the "zero data retention" commitment. It addresses the concern that activating Einstein features would cause proprietary customer data to leak into the LLM's training corpus and potentially surface in other customers' outputs.

Understanding what this commitment actually covers — and, critically, what it does not — is the prerequisite for evaluating whether the Trust Layer is sufficient for your organisation's security and compliance requirements.

Data De-identification and Tokenisation

Before a prompt is sent from Salesforce to the external LLM, the Trust Layer applies a de-identification scan. The scanner identifies field values that match configured sensitive data patterns — names, email addresses, phone numbers, national identification numbers, financial account references — and replaces them with opaque tokens. The LLM receives the tokenised version of the prompt; it never processes the actual sensitive values.

When the LLM returns a response, the Trust Layer intercepts it before it reaches the Salesforce application and re-hydrates the tokens with the original values. From the user's perspective, the output contains the actual customer names and contact details; the LLM only ever processed tokens. This architecture means that even if the LLM provider had a data exposure incident, the exposed data would be a set of tokens rather than your customers' actual PII.

The scope of de-identification is configured, not automatic: The Trust Layer de-identifies fields that match the patterns in its PII detection configuration. It does not automatically understand that your custom field "Contract_Value__c" contains commercially sensitive pricing information, or that your "Internal_Account_Code__c" field maps to a specific high-value customer in a way that should be protected. De-identification coverage is bounded by the PII pattern configuration — fields that are sensitive but do not match standard PII patterns will not be de-identified unless you explicitly extend the configuration.

Toxicity Filtering and Content Policy

The Trust Layer applies a content filter to LLM outputs before they are returned to the Salesforce application. The filter screens for responses that contain harmful, hateful, sexually explicit, or otherwise policy-violating content. If the filter identifies a policy violation in the output, the response is blocked and the user receives an error message rather than the harmful content.

The toxicity filter is applied to the LLM's response, not to the user's input. This is an important asymmetry: the filter prevents the platform from surfacing harmful outputs to users, but it does not prevent users from attempting to elicit those outputs through adversarial prompts. If a user submits a prompt designed to manipulate the LLM into producing harmful content, the Trust Layer will attempt to block the output — but the attempt was still made, and the attempt itself may warrant investigation.

The filter is calibrated for general enterprise content — it is not domain-specific. For highly regulated industries (healthcare, financial services, legal), the Trust Layer's general content policy may not align precisely with your sector's specific prohibited content definitions. A financial services firm whose compliance policy prohibits the LLM from making any statement that could be construed as investment advice will find that the Trust Layer's general filter does not enforce that specific prohibition. Domain-specific content restrictions require additional guardrail design at the prompt template and agent instruction level.

Audit Logging and the Accountability Chain

The Trust Layer logs every LLM interaction — every prompt sent and every response received — in the Einstein audit trail. The log captures the timestamp, the user identity, the feature invoked, and metadata about the interaction. For Agentforce agents, the log also captures the sequence of actions the agent took and the data it accessed during the session.

This audit capability is genuinely useful for compliance and incident investigation. If a data subject submits a GDPR access request asking what AI features processed their data, the Einstein audit trail provides a queryable record. If an Agentforce agent takes an unexpected action, the audit log provides the reconstructable sequence of what the agent did and why.

The limitation of the audit log is that it captures what happened, not whether what happened was appropriate. The log records that the agent updated a record; it does not flag whether that update was outside the agent's intended scope. Identifying anomalies requires either automated monitoring rules against the audit log, or periodic manual review — neither of which the Trust Layer provides out of the box. The audit log is evidence; the governance programme provides the interpretation.

What the Trust Layer Does Not Protect Against

The Trust Layer is designed around a specific threat model: data leakage into LLM training corpora, harmful content generation, and the absence of an accountability record. It addresses those threats meaningfully. It does not address the following threat vectors, which architects must compensate for explicitly.

Prompt injection: An adversarial user who crafts an input designed to override the agent's instructions or extract information beyond their access rights is not blocked by the Trust Layer. The Trust Layer filters outputs for toxicity; it does not validate that the LLM is honouring its instruction boundaries. Prompt injection resistance must be designed into the agent's system instructions and validated through adversarial testing before production deployment.

Excessive data exposure via grounding: The Trust Layer de-identifies specific sensitive values, but it does not limit how much data Atlas retrieves from the org to include in the grounding context. An agent whose Actions allow it to query broad record sets and include them in the LLM context is exposing that data to the LLM — de-identified at the field level, but still potentially revealing through the aggregate. The grounding scope must be designed with the principle of minimum necessary data, not maximum available context.

Business logic violations: An agent that invokes a valid Action in an inappropriate business context is not caught by the Trust Layer. If an agent approves a discount request it should have escalated to a manager, or sends an outreach email to a customer who has opted out, the Trust Layer's controls do not prevent this. Business logic guardrails must live in the Action definitions themselves and in the agent's Topic instructions — they cannot be delegated to the Trust Layer.

Sharing model bypass through agentic context: When an Agentforce agent runs a session, it accesses data using the running user's sharing permissions. But the agent may request data across multiple records in ways that a human user would not typically query — effectively combining information from multiple records into a single context that the human user could technically access individually but would rarely assemble in practice. This is not a Trust Layer bypass; it is a valid use of existing permissions. But it is a data minimisation concern that the Trust Layer is not designed to address.

Designing for the Gaps

Filling the Trust Layer's gaps requires deliberate architectural decisions at the design phase — not compensating controls bolted on after deployment. Three principles guide this design.

Minimum necessary grounding: Every merge field in a prompt template and every record query in an agent Action should be justified by a specific output quality requirement. If including a field does not demonstrably improve the quality of the LLM output, it should not be included. This principle limits the exposure surface without degrading output quality.

Action-level business rule enforcement: Business logic that must never be violated — cannot-contact flags, manager approval requirements, regulatory disclosures — should be enforced in the Flow or Apex that implements the Action, not in the LLM's instructions. The LLM can be instructed not to approve discounts above 20%; the Flow that executes the discount approval should enforce the 20% ceiling regardless of what the LLM decided. Defence in depth at the execution layer compensates for instruction drift at the reasoning layer.

Adversarial testing before production: Every agent and every high-volume generative feature should undergo structured adversarial testing before production deployment. This means attempting to elicit out-of-scope behaviour through carefully crafted inputs, testing boundary conditions on field access, and verifying that business rule enforcement at the Action level works correctly when the LLM attempts to invoke the Action with unexpected parameters. The Trust Layer protects against known harmful patterns; adversarial testing identifies the unknown ones specific to your deployment.