Salesforce Einstein Security: Map the Trust Layer Boundaries

Salesforce's Einstein Trust Layer applies several controls to one managed AI path. Salesforce lists zero data retention with third-party model providers and TLS for prompts and responses. It also lists data access checks for grounding and feedback storage. The list includes an audit trail. Its 2024 Agentforce announcement adds toxicity detection and secure retrieval. It also adds dynamic grounding. Those functions deserve separate tests. I want to map each one to the exact security question it answers, then mark the boundaries where CRM configuration is responsible. Application authorization or an external HTTP policy point may be responsible elsewhere.

TL;DR

• Salesforce data access checks restrict prompt grounding to records the end user is permitted to access.
• The cited Trust Layer material covers TLS and zero data retention arrangements; toxicity detection and grounding; secure retrieval and audit data.
• CRM permissions and agent action design remain separate control planes. External integrations, endpoint security, and customer retention settings do too.
• DeepInspect applies only to HTTP LLM traffic a customer can route through it; Salesforce-managed internal model calls cannot be assumed to cross that gateway.

Data access checks govern grounding

A grounded Einstein prompt can include CRM data relevant to a case, account, opportunity, or service interaction. Salesforce says Data Access Checks restrict the grounding data added to the prompt to information allowed by the end user's permissions. That is the first security control to test because it binds model context to Salesforce authorization.

Create two synthetic users with different object and record access, plus different field access. Run the same prompt against the same customer scenario, then compare the grounding sources and outputs. The restricted user should receive a response built only from authorized records. Preserve permission assignments and timestamps. Preserve the resulting audit entries too.

This test also exposes configuration drift. A broad permission set assigned for convenience can make the Trust Layer behave exactly as designed while still supplying data the security team expected to remain restricted. Salesforce checks the permissions that exist. IAM governance has to ensure those permissions express the intended business boundary.

The same principle applies to agents. An autonomous action executing under a configured identity inherits the authority represented by that identity and the action design.

Data handling controls protect the provider path

Salesforce says the Trust Layer prevents customer prompts and responses from being stored by third-party LLM providers or used to train their models under its zero data retention arrangement. It also documents encrypted communications over TLS between Salesforce and the model provider. These controls address provider retention and transport confidentiality.

Salesforce's AI Cloud architecture announcement describes several arrangements. Third-party services can run within Salesforce infrastructure, and Salesforce supplies its own LLMs. Bring-your-own-model connections pass through the Trust Layer. A review should identify which arrangement is used for each production capability. Contract language and endpoint ownership can differ across them. Keys, network route, and retention terms can also differ.

Use a data-flow diagram with named systems instead of one box labeled Einstein. Mark the Salesforce application and Trust Layer. Mark the Data 360 grounding source and model endpoint. Include any customer-controlled integration. Then attach evidence for TLS and the applicable retention commitment. Attach evidence for the route actually used. A polished trust-center page cannot replace a tenant-specific diagram.

Content handling and toxicity scoring serve different risks

Salesforce's 2024 Agentforce announcement lists zero data retention and toxicity detection. It also lists secure retrieval and dynamic grounding, plus audit controls. Each mechanism answers a different question. Secure retrieval shapes the context supplied to the model, while toxicity detection evaluates generated content.

Test the documented controls independently. Use a safe evaluation set for toxicity detection and document thresholds and actions. Document review ownership separately. Exercise retrieval with synthetic records that carry distinct access permissions, then inspect the supported audit data. A score that feeds a dashboard has forensic value. A block or escalation before output reaches a user has preventive value.

I would stop a review that combines retrieval and toxicity with authorization in one control row called AI safety. Each mechanism has its own input and execution point. It also has its own failure consequence. Separate control statements make gaps visible and remediation assignable.

Agent actions extend past model output

Einstein and Agentforce can do more than generate text. Salesforce describes agents and assistants that use standard or customized actions and Flow. They also use Apex and APIs to update records and execute business processes. Agentforce's general-availability announcement says agents can be triggered by data changes and business rules, or by automations and API signals, then use configured topics and actions.

The model request is one decision. The business action is another. A permitted prompt should not automatically authorize a fee reversal, customer record update, refund, or outbound message. Action-level authorization and transaction limits belong in Salesforce and the connected business system. Human approval and rollback belong there too.

Run one test where the model proposes an allowed action and a second where the same action exceeds the test user's authority. Preserve the supported audit data and action invocation. Preserve the Salesforce authorization result and resulting record change. Preserve any human approval. DeepInspect can evaluate routed HTTP AI traffic. It has no control over a local Flow transaction that never crosses that boundary.

External routes need their own policy point

The Salesforce Trust Layer protects Salesforce-mediated AI interactions. An enterprise may also run direct model integrations and MuleSoft flows. It may run custom Apex callouts and external applications, along with developer tools. Each route needs an inventory and an owner. A model call outside the documented Trust Layer path should never inherit its controls by association.

For customer-controlled HTTP LLM traffic, AI policy enforcement at the HTTP layer can evaluate the principal and relay before forwarding. It can also evaluate prompt classification and destination. Purpose and requested operation complete the decision context. This closes the post-authentication gap for the routed request. A valid Salesforce integration credential establishes the caller at one hop. Per-request policy decides if that caller may send this content to this model now.

Opaque Salesforce-managed model traffic presents a different architecture. If the customer cannot route the HTTP hop through an external gateway, the Trust Layer and Salesforce controls own that path. The review should state the boundary rather than draw a proxy into a diagram where no integration point exists.

A control map for the security review

Build the review around evidence pairs: one configured control and one executed test.

• Grounding authorization: Salesforce permissions plus two-user data access test.
• Provider retention: applicable zero data retention terms plus endpoint and model inventory.
• Transport: TLS configuration evidence plus connection-path validation.
• Retrieval: access configuration plus a synthetic two-user result.
• Output handling: toxicity threshold and action plus an evaluation result.
• Agent action: Flow, Apex, or API authorization plus an over-limit attempt.
• External model route: gateway policy plus an allow and block decision.
• Audit: audit-trail retrieval plus correlation to the originating user, prompt, output, and action.

The zero-trust LLM architecture article provides the broader request model. Every row should name the enforcement point and owner. It should also name the evidence source and failure behavior, plus the review date. A control with no executed test is an assertion.

Scope distinct from DLP

DLP focuses on classifying sensitive content and deciding if it may leave through a prompt or return in a response. Salesforce Einstein security is broader. It includes CRM permission hygiene and grounding behavior. It covers provider retention commitments and transport. Masking configuration and output scoring also fall within its scope. Agent action authorization, audit access, and external integration ownership complete the scope.

That separation matters during remediation. A masking miss belongs with the Trust Layer configuration owner. The Salesforce IAM team handles excessive CRM access. An unauthorized Flow action belongs to the application owner. The HTTP route owner investigates a direct external model request that bypasses enterprise policy. One generic AI security ticket guarantees that the hardest boundary stays unassigned.

DeepInspect

This is the gap DeepInspect closes for customer-controlled HTTP model routes. DeepInspect sits inline as a stateless proxy and evaluates application-supplied user or agent identity. It evaluates prompt classification and destination. It also evaluates the requested operation and versioned policy, then allows or blocks before the LLM receives the request.

Salesforce's Trust Layer is responsible for the managed controls on Salesforce-mediated interactions. CRM administrators own permissions and data configuration. Application teams own Flow and Apex. They also own business-action authorization. DeepInspect adds an independent per-request policy decision and signed record on the HTTP traffic routed through it. Book a technical deep dive at deepinspect.ai.