How to secure customer data when using Salesforce AI tools

A workshop asks the agent for the discount on a live opportunity. The reply comes back empty. Someone sets the object to public read, adds View All Records to the pilot user, and asks again. The agent names the discount. The room treats that as progress.

The next week a seller asks about their own pipeline. The agent describes an opportunity owned by another team, including a field the page layout has hidden from that seller for two years. The reply has already been given. Moving the conversation to a queue does not take it back.

The agent sees the customer the running user can see. That user is the person in the chair, or a named integration user created for the job. Sharing rules, field-level security, and the permission set on that user decide the rows and the fields in the reply. A sentence in the instructions is a request made to something built to be helpful. The wall is the platform.

#Trusted data is the data you already store

Salesforce says these agents generate responses "using trusted business data, including Salesforce CRM data, external data from Data 360, and more." The sentence names the stores a reply can be drawn from. It does not open a sharing rule. It does not sit above field-level security. Trusted, in that line, means the data you already hold under the permissions you already set.

Read it as a scope statement, then stop. CRM data means the records the running user can query. External data from Data 360 means data you have already decided to connect, under the controls that connection already has. "And more" is not an instruction to add a source until the demonstration looks complete. Connecting a new store so the agent has something to say is the same move as widening sharing. You have increased what a reply can contain, and you have done it for the workshop.

If the pilot comes back empty, the access model is doing what it was set to do. An empty answer is a result. Write it down: which user, which question, which objects returned nothing, and whether that nothing was correct. Widening access until a demonstration looks complete replaces that result with a breach you will still be running next month. The records opened for the workshop are the records the agent will use when a real person asks, including a person who should not have seen them.

Write the running user into the design before anyone builds the action. For a seller, that is the seller. The agent then sees that seller's accounts, the opportunities sharing lets them open, and the fields field-level security leaves visible. For a service reply that should see one account's orders and nothing beside them, that is a named integration user with a specialised permission set. The set lists objects it may read, objects it may update, and fields that stay closed. "The service agent" is not a user. A permission set called Service Agent All Access is not a design.

The running user also sits somewhere in the role hierarchy. Access granted by the hierarchy flows upwards. An agent running as a seller sees that seller's book. An agent running as the regional vice president sees every row the hierarchy grants that vice president. Choosing a senior login because it "has the full picture" chooses the height of the tree. If the question is about one customer's orders, the user should be low enough that other customers' orders are absent.

A person owns that integration user. The owner's name goes in the permission set description, in words a new administrator can read. When they leave the organisation, review the permission set the same week you disable their login. An integration user with no owner accumulates grants the way a shared mailbox does. Someone adds a permission for a pilot. The pilot ends. The permission stays. The next pilot adds another.

#Sharing rules now carry the page

A page layout hides a field from someone looking at a screen. It does not hide the field from an agent, a report, a list view, or an API call. Field-level security does. If the discount sits on the layout for managers and off the layout for sellers, a seller's agent can still return it when the field is readable on that user. The layout was a display choice. The agent does not look at the layout. Dynamic forms and compact layouts change the page a person sees. They do not change the query.

Org-wide defaults set the starting position for every row. Private means a user sees records they own, records shared to them, and records the role hierarchy opens. Public read means every user who can see the object can see every row. Public read/write means they can edit them too. Controlled by parent means the child follows the parent: open the account, and the contacts and opportunities under it follow. A default left on public read during an implementation nobody present still remembers will feed every agent you point at that object. Make the decision again, object by object, for the objects the agent will read.

Sharing rules and the role hierarchy then open rows for the people who need them. Owner-based rules share one group's records with another group. Criteria-based rules share every record that matches a filter, such as every account in a region. A criteria-based rule written as "billing country is not blank" is public read with extra steps. A line in the instructions that says "only use this customer's own records" does not tighten that rule. When the model can see the neighbouring account, helpfulness is the failure mode. It will use what it can see, and the reply will sound careful while it does it.

View All Records and Modify All Records are not a Friday-afternoon setting. They ignore sharing on that object. A user with View All on Opportunity sees every opportunity object security allows, regardless of owner. View All Data and Modify All Data do it across objects. If you would not give that permission set to a contractor starting on Monday, do not give it to the agent so a workshop can finish. A field closed by field-level security and then opened just for the agent is open for that user everywhere that user can query.

Permission sets stack. The running user gets the union of every set assigned, plus what the profile still grants. A tight set written for the pilot does nothing if an older set on the same user already has View All. Read the user's effective access, not the set you created this week. Profiles are still part of that picture. This is ordinary access design. It is not a retirement programme, and it is not solved by moving the user to Lightning.

Test as the user. Run a report as them and list the records they can open. Run the agent as that same user and list the records it will name. Anything on the second list that is missing from the first is a hole. The usual holes are a field readable at field-level security and hidden on the layout, a sharing rule wider than the team that works the row, a manual share nobody removed, and a running user that is an administrator because the sandbox login was convenient. Fix the hole in sharing, in field-level security, or in the choice of running user. Do not fix it by adding a paragraph of instructions.

Do the same test for an update, not only a read. If the agent can change a field the user should not change, the permission set is wrong. Read and edit are separate decisions. A service integration user that may read the order and must not edit the price needs both lines written down. "It can see it, so it might as well maintain it" is how a helpful action overwrites a billing field during a conversation about a delivery date.

Sandbox copies lie in a specific way. Teams loosen sharing in a sandbox so testers can see each other's data, then judge the agent there. A pass in a loosened sandbox is a pass against the wrong wall. Run the three-user test in an org whose defaults match production, or the test will congratulate you for a hole you have not copied yet. If the setup audit trail shows a public-read change on the afternoon of the demo, that change is the finding.

#Escalation does not close the hole

Salesforce says that when agents face issues beyond their scope, "they can escalate the matter to human agents, ensuring that queries are resolved efficiently and accurately." That is a handoff to a queue. The person who receives the case sees what their own user can see. They do not inherit a temporary widening you applied to the agent. Escalation does not restore a sharing rule removed so the demo could find the account. It does not pull back a field the agent has already put in a reply.

If the record is sensitive, it has to be unreachable before the first response. Sensitive here is operational. A discount another team has not published. A complaint that names an employee. A note about a person's health or a card number sitting in a free-text field because there was nowhere else to type it. Those values do not belong in fields an agent can read. If they are already there, the work is field-level security and a cleanup of the text, done before the pilot. A prompt that says "do not mention sensitive fields" is the instructions pattern again. The field has to be absent from the query.

The handoff itself is a write. Which queue receives it. Which fields the case carries. Whether the transcript includes the record data the agent retrieved. A transcript that pastes an account the receiving user cannot open has moved the data out of the sharing model and into a case comment. Everyone who can see the case can now see the comment. Treat that write the way you would treat a person pasting the same text into the case. If field-level security would block them, the agent's escalation should not be the path that succeeds.

#What to settle before the pilot leaves the sandbox

Before the pilot leaves the sandbox, pick three users. A seller. Someone who works cases. The most restricted user you actually have, not a hypothetical one. For each, write five records they must reach and five they must not. Include a record they own, a record shared by a rule, a record owned by someone outside their role, and a field that is on one layout and off another. Diff the agent against a report run as that user. Change the access until the lists match. Then leave the instructions alone. They are not the control.

The cost of reversing a widened default shows up in the third column's absence. Once public read has been in production, reports, integrations, and agents quietly depend on it. Tightening the default later breaks those dependencies one by one, and the break is discovered by the team that can no longer see its own records. That is why the decision sits before the pilot, while the empty answer is still available as evidence.

#Where this goes wrong

The demo user is an administrator. The sandbox login could see everything, so the pilot could too. Production copies the permission set because it worked. It worked because the user was the wrong height, with the wrong system permissions.

Instructions used as a control. The prompt says to stay on this customer's records. The sharing model says public read. The prompt loses, and the reply still sounds restrained, which is why the miss survives the first review.

A field closed on the layout and open to the query. The business believes the discount is manager-only because that is what the screen shows. The agent reads the field because field-level security allows it. The complaint arrives after the number is already in a chat log.

The refusal to widen access has to be usable in the week of the workshop, against a senior request to make the demo answer. That refusal is the job of a centre that can say no before the demo ships. A quarterly review after the permission set is in production is a reconstruction.

Name the running user and the owner of the permission set before the first question is asked. Write the ten records, run the report against the agent, close the holes, then run one escalation and read the case as the person who receives it. If the fix on the table is to open access so the story lands, stop the pilot. The permission set will not un-ship itself.