Is the Einstein Trust Layer insecure?

No. Within its scope it applies masking, toxicity scoring, and detailed logging, and it is a capable control for Salesforce-mediated AI. The point is scope, not security: it audits traffic that flows through Salesforce's LLM Gateway and cannot record AI traffic that never enters it. The limitation is architectural coverage, not a flaw in how the Trust Layer handles the traffic it does see.

What does "routes around" the Trust Layer mean?

It means AI usage that does not go through Salesforce: employees using public chat assistants, coding tools calling models directly, internal services hitting a provider API, and any other LLM traffic outside the Salesforce platform. Because the Trust Layer's audit trail is populated by its own gateway, these interactions produce no entry in it, so they are unaudited by that record even though they are part of your AI footprint.

Can I make the Einstein Trust Layer cover non-Salesforce AI?

The Trust Layer is designed for AI orchestrated through Salesforce. Governing and auditing AI that runs outside Salesforce requires a layer positioned where that traffic actually flows, the HTTP request boundary common to every model call. A platform-scoped audit and a boundary-scoped audit answer different questions, and only the latter spans providers.

How does this map to EU AI Act Article 12?

Article 12 requires automatic, per-request recording detailed enough to reconstruct what a high-risk system did, across the system's use. If your high-risk AI use spans more than Salesforce, an audit trail scoped to one platform leaves the rest of that use unrecorded. Satisfying Article 12 across a multi-provider footprint means a per-decision record at the boundary all that traffic crosses, written independent of the platforms generating it.

The Einstein Trust Layer Audit Gap: What Its Log Covers and What Routes Around It

Salesforce's Einstein Trust Layer keeps a detailed record. For every Agentforce or Einstein interaction that passes through its secure LLM Gateway, it logs the original prompt, the masked prompt, the completion, every masked entity, the toxicity score, the grounding source, the user, and the timestamp, and writes all of it to an audit log in Data Cloud. If you are debugging an Agentforce conversation and asking what the model actually saw, that audit trail is the source of truth. Within its scope, it is a strong record. The word doing the work in that sentence is "scope," because the Trust Layer only audits what flows through Salesforce. I want to walk through what it captures, and then the traffic that never reaches it.

What the Einstein Trust Layer records

Credit where it is due: the Trust Layer's audit trail is more detailed than what most enterprises produce for their AI traffic. It identifies sensitive data with pattern-based detection and machine-learning models, masks it with placeholders before the prompt crosses to the model, and stores the mapping between the original values and the placeholders so the response can be demasked on the way back. Along that path it records the prompt, the masked prompt, the completion, the toxicity scores, the grounding sources, and, when the model returns a token that was not in the mask map, the anomaly.

That is a per-interaction record with identity and timestamps, retained in Data Cloud under a configurable retention window. For Salesforce-mediated AI, it is a defensible audit artifact.

The coverage boundary

Here is the gap. The Trust Layer sees AI traffic that flows through Salesforce's LLM Gateway. It does not see AI traffic that does not.

The same employees whose Agentforce prompts land in the Einstein audit log also use ChatGPT in the browser, Claude in a desktop app, Copilot in their IDE, and direct API calls from internal services to api.openai.com. None of that traffic passes through Salesforce, so none of it appears in the Trust Layer's record. A customer record pasted into a public model, a contract summarized by a coding assistant, a support transcript sent to a directly-integrated LLM, each of these routes around the Trust Layer entirely, and the audit trail that Salesforce keeps is silent on all of them because they never entered its gateway.

This is not a defect in the Trust Layer's logging. It is a scope boundary. The Trust Layer is an audit trail for Salesforce's AI surface, and most enterprises run AI far beyond that surface. Recall that 78% of employees use unauthorized AI tools at work (Cloud Radix, 2026); those interactions are, by definition, outside any single vendor's gateway. The shadow AI problem is exactly the traffic a platform-scoped audit cannot see.

The self-attestation angle

There is a second consideration for the traffic the Trust Layer does cover. The system generating the AI interaction, Salesforce, is also the system writing the audit record of that interaction. For operational debugging that arrangement is fine. For a regulator who expects the audited system and the auditing system to be separable, a record written by the same platform that produced the decision carries the self-attestation question that applies to any application-controlled log: the platform both acts and records its own action. An independent record, written by a layer the acting system does not control, is what removes that question. The general form of this argument is in why an AI audit log needs write-path independence.

What enterprise-wide audit requires

A regulator asking about your AI use, whether under EU AI Act Article 12 or a sector rule, does not scope the question to one vendor. The requirement is a per-decision record across all AI traffic: who sent what, to which model, under which policy, at what moment, regardless of whether the call went through Salesforce, OpenAI, Anthropic, Bedrock, or a self-hosted endpoint.

Producing that record means moving the audit point off any single platform and onto the HTTP boundary that all AI traffic crosses. A layer at that boundary sees every model call regardless of provider, and writes the record independent of the application that made it. This is the difference between auditing one AI surface and auditing your AI use. The mechanics of enforcing and recording at that boundary are in AI policy enforcement at the HTTP layer.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline as a stateless proxy on the AI request path, in front of any HTTP-based LLM endpoint, not just one vendor's. For every request, from an Agentforce agent, a browser session, an internal service, or a coding assistant routed through it, DeepInspect evaluates identity, data classification, and policy, makes a pass, block, or redact decision, and commits a signed per-decision audit record independent of the calling application.

The Einstein Trust Layer gives you a strong record of your Salesforce AI. DeepInspect gives you one record across every model your organization touches, written by a layer none of those platforms control. If your audit trail today stops at the edge of one vendor, let's talk today.