Salesforce Einstein Audit Logs: Build a Decision Evidence Package

Salesforce describes its Einstein Trust Layer audit trail in operational terms: it securely logs prompts and outputs plus interactions and feedback data. Salesforce also says audit and feedback data from AI prompts and responses is stored in Data 360, where teams can report on it or create Flow alerts. That is a substantial platform record. I want to focus on the harder audit task: proving one AI decision with retrievable evidence and clear ownership, backed by a correlation path.

TL;DR

• The Einstein Trust Layer records prompts and outputs plus interactions and feedback data for Salesforce-mediated generative AI activity.
• Salesforce says audit and feedback data is stored in Data 360 for reporting and automated Flow alerts.
• An audit test still needs to verify access and retention alongside export, timestamps, user attribution, and correlation for one chosen interaction.
• An independent HTTP decision record adds the model route and prompt classification plus the versioned policy, outcome, and relay identity when traffic is customer-routed through that boundary.

The Trust Layer record has a defined job

Salesforce announced the audit trail alongside zero data retention and encrypted communications, with data access checks and a feedback store. The Trust Layer sits between Salesforce applications and model providers. Its audit function records the interaction while the feedback function captures signals such as acceptance and rejection, plus modification and usefulness of a generated response.

Those records support two different activities. Product and operations teams can examine quality and adoption patterns, including feedback. Security and compliance teams can investigate what entered and came back through the managed AI path. The distinction should survive schema design and access control. A product analyst who needs aggregate acceptance rates has a different purpose than an investigator retrieving the content of one customer-service interaction.

Salesforce's current description of Agentforce Assistant says audit and feedback data collected from prompts and responses is stored in Data 360 and can feed reports or automated Flow alerts. That makes Data 360 part of the evidence path, rather than a passive archive named only in architecture slides.

Retrieval is the first audit test

Start with one known interaction generated by a named test user. Give it a unique synthetic marker, record the UTC start time, and capture the Salesforce record or case that supplied grounding context. Then ask an administrator to retrieve the corresponding audit data through the supported Data 360 path.

The returned evidence should identify the user and prompt as well as the response, interaction time, and relevant feedback. Salesforce's public product descriptions establish those categories. The test should also document which permission set allowed the administrator to query the data, which fields were visible, and which fields were masked in the review interface or export.

I have a strong view on this: a dashboard screenshot is weak audit evidence. It proves that a chart rendered. A repeatable query and saved result, backed by an access record and schema version, show how the team can retrieve the same event during an investigation. Put the exported row next to the Salesforce case on a monitor and confirm that the identifiers and timestamps line up.

Retention and access need explicit answers

A statement that data is stored in Data 360 leaves several customer-specific questions open. Which retention policy applies to the audit data? Who can read prompt and response content? Can an administrator export records in a stable format? What happens to linked evidence when a Salesforce user, case, or grounding record is deleted? Which alert detects a failed ingestion or delayed data stream?

These questions should be answered from the customer's configured Salesforce environment and current contract, because product announcements do not establish an individual tenant's retention period or permissions. Record the settings and owners in the control package. Then test them.

Least-privilege design matters because the audit trail may contain the same sensitive CRM context the Trust Layer handled. Giving every analyst raw prompt access creates a second exposure path. Use separate roles for operational metrics and content-level investigation. Require a case reference for privileged retrieval and preserve an access log showing who opened the evidence.

User attribution and relay identity differ

Salesforce can associate an interaction with a Salesforce user. That is useful identity evidence. Automated flows and agents add another principal to the chain: the application, Flow, Apex process, or agent that relayed the request. An assessor needs both when an action was initiated by a person and executed through automation.

The chain should read clearly: named user and Salesforce relay; selected model route and grounding source; prompt and Trust Layer handling; model response and feedback; resulting business action. Omitting the relay makes autonomous and user-directed behavior look identical. Omitting the user makes a shared integration identity stand in for the person who initiated the work.

The general form is covered in the AI agent post-authentication gap. Authentication can succeed at each hop while the final record loses the delegation chain. A correlation identifier carried across the Salesforce interaction and customer-controlled gateway, continuing into downstream provider telemetry, is the practical fix where the architecture exposes those hops.

Policy decisions belong beside content logs

A prompt and response show what moved. A policy record shows the decision that permitted it. For each sampled interaction, the evidence package should identify the applicable data class and model authorization, the purpose or operation, the versioned policy, and the final outcome. A later reviewer can then reconstruct the control state that existed at the time.

Salesforce's Trust Layer includes data access checks that restrict grounding to data the end user is allowed to access. That is an important platform decision. The enterprise may also carry policies outside Salesforce, such as a rule barring a particular class of customer data from a specific external model. If that rule is evaluated on a customer-controlled HTTP route, its decision record belongs beside the Salesforce audit entry.

Signed audit logs for AI requests explains the integrity requirement. The application under review should not have sole custody of every record used to judge its own behavior. Write-path independence gives the assessor corroborating evidence rather than a second export from the same administrative plane.

A six-item sampling procedure

Choose successful and blocked interactions plus modified and failed interactions across at least two user roles. For every sample, preserve six evidence groups:

• Identity: the Salesforce user plus any agent, Flow, Apex, or application relay.
• Content: the prompt and output available through the supported Trust Layer audit path.
• Context: grounding records and case or object references, plus the model route.
• Control: data access result and classification, with the policy version and decision outcome.
• Time: UTC timestamps and a correlation identifier across available systems.
• Custody: export method and reviewer identity, storage location, retention rule, and integrity check.

The AI audit log schema gives a field-level model for the independent request record. Salesforce data can remain in its native schema. The evidence package maps fields across systems instead of forcing every source into one lossy format.

Repeat the sample after a permission change and after the retention threshold the team claims to support. A review completed on September 7, 2026 should still be reproducible on the date written in the policy. That is the difference between logging enabled and evidence available.

Platform scope and HTTP scope

The Einstein Trust Layer record covers Salesforce-mediated activity. The July 2023 Salesforce announcement specifically places prompts and responses inside the Trust Layer flow and says third-party LLM providers do not store them or use them for model training under that arrangement. That claim applies to the described Salesforce service path.

DeepInspect can add an independent policy and audit point only where a customer controls an HTTP route to an LLM endpoint and sends it through the gateway. Opaque Salesforce-managed internal calls fall outside that enforcement boundary. So do local execution and CRM permission administration as well as user provisioning and retention configuration.

This article's treatment is deliberately narrower than DLP. DLP asks what sensitive content should pass or be redacted. Audit asks which evidence proves what happened and who authorized it, then identifies which policy ran and how the reviewer can retrieve the record months later.

DeepInspect

This is the gap DeepInspect closes on customer-routed HTTP model traffic. DeepInspect evaluates application-supplied user and agent identity plus prompt classification, model route, and a versioned enterprise policy before a permitted request reaches the endpoint.

Every routed decision produces a signed, tamper-evident record with a correlation ID. Salesforce's Data 360 audit data remains the platform record for the Einstein interaction. DeepInspect adds an independent policy-decision record that an assessor can reconcile with that evidence. Book a technical deep dive at deepinspect.ai.