A specialist notices the service agent can casually mention another owner's outstanding invoice balance when discussing an unrelated topic, because its Agent User was set up by cloning a System Administrator profile "to save time." What is the correct remediation?
Select an answer to reveal the explanation.
Short Explanation
Cloning the admin profile "to save time" is like giving the front-desk intern the master key because cutting a new one felt slow. The fix isn't a sign on the door asking them not to open certain rooms, it's taking the master key back.
Full Explanation
The root cause here is over-provisioned access: an Agent User built from a System Administrator clone can see essentially everything in the org, including unrelated owners' financial data, and no amount of conversational steering fixes that because the model can technically retrieve and reference data it should never have been able to see. The correct remediation is to rebuild the Agent User's permission set from least privilege, granting exactly the objects, fields, and record access the agent's configured actions require and nothing more, which is the same discipline applied to any integration user. A guardrail instructing the agent not to mention other owners' balances is an instruction-level patch on top of a data-access-level failure; it may reduce but cannot reliably eliminate the leakage, since guardrails shape language, not access. The Einstein Trust Layer masks sensitive values it is configured to mask in prompts and responses, but it is not a substitute for correct object and field permissions, and relying on it here treats a symptom while leaving the underlying over-access in place. Scoping the problem to a single topic's instructions misdiagnoses it as a topic-configuration issue when it is actually an Agent User permission-set issue that affects every topic and action equally.