Redacting PII and NPI from Salesforce MCP Server Responses Before They Reach the LLM

Where Salesforce MCP responses expose PII and NPI

An MCP tool call against Salesforce typically returns JSON built from CRM objects. Contact details, account attributes, financial attributes and custom fields can all appear in the result, depending on what the tool queries. Free-text fields such as case comments and notes are a separate problem. They have no fixed schema, and people type names, phone numbers, account identifiers and other personal details into them.

The response is the exposure point. Source-side permissions control who may run a query. They do not inspect which values in a permitted response are then placed in the model's context. Once a value is in context, the model, its provider, downstream tools and any stored conversation history can all receive it.

Direct identifiers are only part of the risk. The U.S. Government definition of PII, cited by NIST SP 800-188, covers information that can distinguish or trace an individual's identity alone or combined with other linked or linkable information. A response with no single obvious identifier can still identify someone when fields are combined. Error messages and metadata also deserve inspection, since NIST SP 800-228 identifies response codes and error information as common side channels.

Comparing redaction placement options

Each placement can work. They differ in what they cover, how they fail and what evidence they leave behind.

• Source-side field restrictions: Coverage: known fields that are restricted before the MCP server returns them. Failure modes: free text inside permitted fields is untouched, new custom fields can be missed, and over-restriction can break the tool. Evidence: shows configuration, not what any single response contained.
• Application-layer filtering: Coverage: whatever the application developer implements for that client. Failure modes: behavior varies between clients, and a client that skips the filter receives raw data. Evidence: depends on each application's own records.
• Policy enforcement in the execution path: Coverage: every response that passes through, for structured and unstructured content. Failure modes: detection false negatives, and any client that connects around the path. Evidence: a decision record can be produced for each tool call.

Define redaction policy for structured and unstructured content

Start with actions. Define allow, redact, mask and block, and make them settable per tool, object and field. A tool that needs an account's status may allow it. The same response may redact a contact's phone number and block entirely if a financial attribute appears where it should not.

For structured JSON, field-name rules are deterministic and easy to test. For free text, detection must be layered. NIST IR 8505 notes that regular expressions, paired with keywords and validators, can be precise for pattern-based identifiers. It also notes that their effectiveness depends heavily on keyword proximity, and that they can produce false positives and considerable noise if unmanaged. Machine learning can complement them by learning from data patterns. Neither approach removes the need to measure false negatives on your own case notes.

Decide how redacted values are represented. Consistent placeholders let the LLM tell that two mentions refer to the same person across a multi-step task. If a reversible mapping is kept, store it separately from the redacted data, as NIST IR 8053 describes for reversible de-identification. Be cautious with wording in governance documents. NIST SP 800-188 states that redaction alone is generally not sufficient to provide formal privacy guarantees and may reduce the usefulness of the remaining data. Redaction reduces exposure. It is not de-identification.

Produce evidence that redaction was enforced

A configuration screenshot shows intent. Audit-ready evidence shows what happened on a specific call. Design a record for each tool call that can be exported to your audit and logging systems without holding the raw sensitive values.

A practical record includes the timestamp, the tool and MCP server called, the calling user or agent identity, the policy version applied, the action taken (allow, redact, mask or block), the categories of data detected, the fields or text spans affected, and a hash or count in place of the original values. Record the detection methods in use, since NIST AI 600-1 supports documenting how PII and sensitive data are detected in AI systems. That text addresses generated output, so applying it to tool-call responses is an extension, and your compliance team should map the record to the specific frameworks you answer to.

Keep the evidence store under the same access controls as other sensitive systems, and set retention deliberately. A record that quietly copies the raw data would recreate the exposure it was meant to document.

How Trussed enforces policy on MCP responses

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For a Salesforce MCP server, that means each tool-call response is evaluated at runtime, not reviewed after the fact, and the policy can allow, redact or block it. Trussed can also rate limit or escalate for human approval, and its scope is individual interactions and tool calls.

Enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, so evidence can stay where a regulated enterprise requires it. Trussed has run continuously in production in a regulated enterprise for more than 18 months.

The design steps above apply with or without Trussed. What matters is that the control sits in the path, covers both structured fields and free text, and leaves a record per call.