When Meridian's agent uses MCP to send a referral case summary to the specialty hospital's external triage model, that summary would normally include the pet owner's phone number and home address. Which capability ensures that PII is masked before it leaves Salesforce's boundary in that exchange?
Select an answer to reveal the explanation.
Short Explanation
Trust Layer masking rides along with the agent's context wherever it goes - it's less like a lock on one door and more like the owner's phone number simply never getting written on the outgoing package in the first place.
Full Explanation
The Einstein Trust Layer applies masking to sensitive data within the context an agent processes before that context reaches an underlying model or is shared onward, and it does so independent of which transport carries the exchange. That makes it the right governing mechanism whether the case summary travels through an MCP exchange, a prompt template, or any other agent context path.
A custom Apex trigger on save is the closest-looking trap: it could technically scrub a stored field, but it fires on record persistence, not on the in-flight context an agent assembles and sends through MCP, so it does not reliably protect data at the moment it crosses the org boundary. The MCP server's own logging configuration governs what the receiving system records, not what Salesforce chooses to mask before sending - it is the wrong side of the exchange to rely on for owner-side data protection. The agent-to-agent protocol is unrelated here: this scenario has an external triage model, not a second Agentforce agent, so A2A encryption (even if relevant) would not be the applicable control.
Exam takeaway: Trust Layer protections travel with the agent's context regardless of which interoperability mechanism carries it.