The Trust Layer sits between your org and the model provider. It masks certain sensitive data on the way out, holds a zero-retention agreement with the provider, scores responses for toxicity, and writes an audit record of what happened. That is genuinely useful, and it is a narrow set of guarantees. It does not decide what an action may touch, and it does not stop an agent quoting a record the user should never have seen.
What it does
Masking. Before a prompt leaves the platform, recognised patterns are replaced with placeholders. Names, emails, phone numbers, payment card numbers and similar. The model sees a placeholder, and the response is demasked on the way back so the user sees the real value. Pattern detection is exactly as good as pattern detection ever is, which is to say good at card numbers and unreliable at free text that happens to contain a person’s details.
Zero retention. The contractual position with the model provider is that prompts and responses are not retained and not used for training. This is a commercial and contractual control, not a technical one, and it is the answer to a specific question your security team will ask.
Toxicity scoring. Responses are scored, and the score is recorded. Whether a high score blocks a response or merely gets logged depends on the feature and the configuration, so check the current documentation for your case rather than assuming it is a filter.
Audit trail. Generative interactions are logged: the prompt, the response, the masking that occurred, the scores. Retention is configurable within limits. This is the part most teams underuse and later wish they had queried.
What it does not do
It does not decide what an action may touch. If an agent action runs in system context and queries every opportunity in the org, the Trust Layer records that faithfully and masks a few names in the output. The access decision was made by your permission model, and that is the control that matters.
It does not stop prompt injection. Text in a case description that instructs the model is data the layer will happily pass through. Masking is not sanitisation of instructions, and nothing in the layer is looking for them.
It does not guarantee accuracy. Nothing in it checks whether the answer is true. Toxicity is not correctness, and a confidently wrong response scores fine.
It does not cover everything with “AI” in the name. It governs Salesforce’s own generative features. An external client reaching your org through an API or an MCP server is a different path with different controls, and assuming the Trust Layer is in front of it is a mistake worth avoiding explicitly.
It does not decide which fields you merged into the prompt. If your template merges a margin field, the margin goes out. Masking looks for personal data patterns, not for commercially sensitive numbers.
What to check in your own org
- Which entity types are masked, and whether the ones that matter to you are in that list. Check the current documentation, because the set grows.
- Whether masking is on for the features you use. Configuration differs by feature and by release.
- Where the audit records live, how long they are kept, and who can read them. They contain prompts, and prompts contain your data.
- Which fields your templates and actions actually merge in. This is the real exposure, and the Trust Layer has no opinion on it.
- Where processing happens geographically, if that matters to your regulators.
How to describe it to a security review
Say what it is: a set of controls over the model interaction, giving masking of recognised personal data, a no-retention agreement with the provider, response scoring and an audit log.
Then say what it is not, before someone else discovers it. The authorisation boundary is the Salesforce permission model, unchanged. The content of every prompt is determined by your configuration. Nobody upstream is checking whether the answer is correct.
Frequently asked
Can I turn masking off? Some of it is configurable by feature. Before you do, write down why, because it is the first question an auditor will ask.
Does masking break the output? Occasionally. A model reasoning over placeholders can produce odd phrasing, and demasking restores values but not sense. Test with realistic records.
Does it apply to my own model? Bring-your-own-model arrangements sit in a different position, and the guarantees are not automatically the same. Check the terms for the specific arrangement.
Is it enough for a regulated industry? It is one control among several. The access model, the data retention policy and the human review step are the rest, and none of them are provided by the Trust Layer.
