PII and data governance: masking, retention, and the audit trail
The moment an AI system reaches a model, customer data leaves your boundary and lands inside a third-party provider. Governance is the discipline that bounds what that exposure costs you: data masking so the PII never reaches the provider in the clear, a zero-retention guarantee so what does reach it isn't kept, and an audit trail so you can prove after the fact what happened. The Einstein Trust Layer gives you all three by construction for an agent in Agentforce — named-entity masking, zero-retention agreements with the LLM providers, toxicity scoring, and a timestamped audit record of the original prompt, the safety scores, and the original response. Off-platform you assemble the same three controls yourself: mask before the call, sign a zero-retention provider agreement, write your own audit log. No 'vs' — the same governance job, by construction in Agentforce or assembled by hand off-platform. And a real per-feature nuance: not every API feature is zero-retention-eligible (Anthropic's Message Batches API is not), so the guarantee is checked per feature, not assumed for the provider. The audit trail is what an auditor reads, and it's the same runtime record observability captures.
The moment an AI system calls a model, your customer's data crosses a boundary. The prompt — which may carry a name, an email, an account number, a support-case body — leaves your infrastructure and lands inside a third-party LLM provider's. That is not a bug to be fixed; it is how a hosted model works, and it is true the instant you ship. Data governance is the discipline that bounds what that crossing costs you. It answers three questions an auditor, a regulator, or a customer's data-subject request will eventually ask: did the sensitive data have to reach the provider at all, is what reached it being kept, and can you prove after the fact what was sent and what came back. This page is the answer to each — and, as everywhere in this catalog, the answer is the same job done two ways: by construction in Agentforce, or assembled by hand off-platform.
This is a reference for the governance discipline across platforms. The in-platform layer is Salesforce's Einstein Trust Layer, which does masking, zero-retention, toxicity scoring, and the audit trail by construction for an agent built in Agentforce. Off-platform, on a Claude API stack, you build the equivalent three controls yourself. They compose by where the system runs — the governance job is identical, and the platform decides whether you inherit the controls or assemble them. This operationalizes principle 11, trace everything, on the data side: the audit trail is the record an auditor reads.
The problem: sensitive data leaves your boundary
Hold the shape of the problem before the controls, because the controls only make sense against it. When your agent sends a prompt to a model it does not host, three distinct risks open at once, and each needs a different control:
- Exposure. The PII in the prompt is now visible to the provider's system. Even a trustworthy provider is one more place your customer's data exists, one more boundary to defend, one more line item in a data-processing inventory.
- Retention. Whatever reached the provider might be kept — logged, cached, or, in the worst case, used to train a future model. Data you cannot delete is data you cannot honor a deletion request against.
- Non-repudiation. When something goes wrong — a wrong answer acted on, a complaint, an audit — the first question is "what was actually sent and what came back," and you can only answer it if you recorded it at the time. No record, no defense.
Masking attacks the first. A zero-retention guarantee attacks the second. An audit trail attacks the third. A governed AI system needs all three, and a system that has only one or two has a gap an auditor will find.
What the Einstein Trust Layer gives you by construction
When the agent lives in Agentforce, those three controls — plus toxicity scoring — are not features you remember to add. They are properties of the platform, applied to every generation as it flows through the Einstein Trust Layer, the governance layer Salesforce runs between Agentforce and the model. Here is what each capability does:
| Capability | What it does |
|---|---|
| Data masking | Named-entity detection scans the prompt for sensitive data (names, emails, account numbers, social security numbers) and replaces each with a placeholder before the prompt reaches the model provider. The model reasons over masked text; the values are restored in the response on the way back. The provider never sees the PII in the clear. |
| Zero data retention | Salesforce holds zero-retention agreements with the LLM providers, so the provider does not retain your prompts or the generated responses and does not use them to train its models. What crosses the boundary is not kept on the other side. |
| Toxicity scoring | Each generated response is scored for toxicity, attaching a signal you can gate on before the output reaches a person — the output-safety control covered in guardrails and safety, here as one column of the same layer. |
| Audit trail | The interaction is logged with a timestamp: the original prompt, the safety and toxicity scores, and the generated response. This is the record that proves what happened — the precondition for owning what the agent did (principle 9). |
The audit trail is the row that ties this page to the rest of production. It is timestamped and it captures the original prompt, the scores, and the original output — which is exactly the artifact an auditor reads when they ask "show me what this system did on this date." (The same Trust Layer controls, listed at the altitude of an Agentforce build, are in Agentforce agents; the masking and zero-retention rows there are the same rows here, framed for assembling an agent rather than governing its data.)
Off-platform: you assemble the same three controls
This is not a competing approach — it is the same governance job, done by hand where the agent runs off-platform. On a Claude API stack, the three controls of the table become three things you build:
- Mask before the call. Run named-entity detection over the prompt yourself and replace PII with placeholders before the request leaves your infrastructure, restoring the values in the response when it returns. The same masking the Trust Layer applies by construction, applied by your code instead. The model reasons over masked text either way; the only difference is who owns the masking step.
- A zero-retention provider agreement. The provider must contractually not retain your prompts and outputs. This is a real, configurable property of an API relationship — but it is the one with the sharpest edge, which the next section is about.
- Your own audit log. Record the prompt, the scores, and the output for every call, timestamped, in storage you control. This is the off-platform version of the Trust Layer's audit row — and it is the same log your observability layer already wants, which is why it costs less than it looks.
The throughline of the whole catalog holds here too: the discipline is identical across surfaces, and the platform only decides whether the control is yours to inherit or yours to assemble. A team running an agent inside Agentforce inherits the four; a team on an external stack builds the three; a team running both does each where it makes sense.
The nuance: zero-retention is per-feature, not per-provider
Here is the edge that catches teams, and it is the one fact on this page most worth carrying away: a zero-retention agreement is not a blanket property of a provider — it is a property of the specific API features you use, and not every feature qualifies. You sign the agreement, you assume your calls are covered, and a feature you reached for to save cost quietly is not.
The concrete instance: Anthropic's Message Batches API — the asynchronous, bulk-processing path that runs requests together at roughly half the per-token cost — is not eligible for Zero Data Retention. In Anthropic's own words, "This feature is not eligible for Zero Data Retention (ZDR). Data is retained according to the feature's standard retention policy." So a pipeline that masks correctly, runs under a zero-retention agreement, and then routes its bulk evaluation jobs through the Batches API to save money has — without anyone deciding to — moved that data off the zero-retention path. The cost optimization quietly broke the governance guarantee.
The discipline that prevents it is small and absolute: check zero-retention eligibility per feature, not per provider. Before a feature goes into a governed pipeline, confirm it is on the zero-retention path; if it is not, either the data must be masked hard enough that retention is acceptable, or that feature is off the table for that data. The same care applies on the Salesforce side — the Trust Layer governs the platform's LLM path, and any data route that does not flow through it does not inherit its guarantees. Governance is only as good as its narrowest covered path, and the uncovered path is usually the one someone added for performance.
Compliance: the audit trail is what the auditor reads
All three controls exist for a reason that lives outside engineering: compliance. When a regulator examines an AI system, or a customer files a data-subject request, or counsel needs to demonstrate that PII was handled correctly, the thing they read is the audit trail. Masking and zero-retention are the controls that limit exposure; the audit trail is the control that proves you limited it. A system that masks perfectly but logs nothing can do the right thing and cannot show it did — and "trust us" is not an answer to an auditor.
This is the same artifact, read by a different reader, that observability captures for debugging. The trace your runtime records to let you replay a bad run — inputs, retrieved context, tool calls, output — is, with the safety scores attached, the audit record a compliance reviewer reads. One log serves both: tracing and monitoring is that runtime record, built for the engineer chasing a silent degrade; the audit trail is the same record, read by the auditor asking what happened. Build it once, to the stricter of the two bars, and it answers both questions. The audit trail is where governance and observability turn out to be the same instrument pointed at two readers.
The throughline
The instant an AI system calls a hosted model, customer data leaves your boundary, and governance is the discipline that bounds the cost: masking so the PII never reaches the provider in the clear, a zero-retention guarantee so what does reach it isn't kept, and an audit trail so you can prove after the fact what happened. The Einstein Trust Layer gives an Agentforce agent all three by construction — named-entity masking, zero-retention agreements with the providers, toxicity scoring, and a timestamped record of the prompt, the scores, and the output. Off-platform you assemble the same three by hand: mask before the call, sign a zero-retention agreement, write your own audit log. Same governance job, inherited or assembled — no "vs." The edge that catches teams is that zero-retention is per-feature, not per-provider: Anthropic's Batches API is not zero-retention-eligible, so a cost optimization can silently move data off the covered path, and the rule is to check eligibility per feature. And the audit trail is the seam to the rest of production — it is what a compliance auditor reads, and it is the same runtime record observability captures, built once for both. Governance is not a property of the model. It is the masking, the retention guarantee, and the record you put around it.
Related
- What is production readiness — the bar a shipped AI clears; governance is one of its columns
- Production gotchas — the failure modes a shipped system inherits, including a governance gap nobody owned
- Cost and latency — where the Batches API tempts you to save money and quietly leaves the zero-retention path
- Guardrails and safety — the toxicity-scoring and output-screening side of the same Trust Layer
- Human in the loop and accountability — the audit trail is the record the accountable human answers from (principle 9)
- Deploying to production — getting the governed system live and operable
- Production Style Guide — the bar a production AI clears before it ships
- Tracing and monitoring — the runtime record observability captures is the same log the auditor reads
- Agentforce agents — the Trust Layer controls listed at the altitude of an Agentforce build
- Tools and actions — the Trust Layer governs the language path; an Action's blast radius is governed separately (principle 5)
- AI Engineering principles — trace everything (11), a human is accountable (9), every tool is a blast radius (5)
- Einstein for Marketing Cloud — the Trust Layer framed for the Marketing Cloud surface
- Data 360 data architecture — the governed data the platform masks and grounds on lives in the unified model
Reference: