# How to secure customer data when using Salesforce AI tools The agent sees what the running user can see. Open sharing so a demo returns an answer, and you have opened those records for real. **Published:** 2025-10-16 **Canonical:** https://synconai.com/secure-customer-data-salesforce-ai **Author:** SynconAI Architecture Team ## In short A Salesforce AI agent sees the records its running user can see, or the records a named integration user can see. That user is the control. Widening sharing or permission sets so a demo returns an answer is the breach. Sharing rules and field-level security carry the load. A handoff to a person does not close an access gap opened for the pilot. ## Sources - **Agentforce: What is an AI agent?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > These agents generate responses that are consistent with your company’s brand voice and guidelines using trusted business data, including Salesforce CRM data, external data from Data 360, and more. - **Agentforce: What is an AI agent?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > When faced with complex issues beyond their scope, they can escalate the matter to human agents, ensuring that queries are resolved efficiently and accurately. ## What to take away - The agent sees what the running user, or a named integration user, is allowed to see. - Widening sharing so a demo returns an answer is the breach. The empty result was the control. - Page layouts hide fields on a screen. Field-level security and sharing rules are what the agent actually hits. - Escalation to a person is a queue handoff. It does not restore a sharing rule you removed. ## The guide 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. :::warn The empty result was the control. Opening sharing, a permission set, or View All so a demo returns an answer is the breach. The records opened for the workshop are the records a real question will use, and a later handoff does not unsend the reply. ::: 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. :::note A report run as the receiving user is the check on the handoff. If the case comment contains a field that report cannot show, the escalation design is copying data the platform had already refused. ::: ## 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. | Check | How you run it | A pass looks like | | --- | --- | --- | | Running user | Named on the design, with an owner | Not the sandbox administrator | | Rows | Report as that user, then the agent | The agent names only records on the report | | Fields | Field-level security, not the layout | Hidden fields stay out of the reply | | Hierarchy | Same question as a seller and as their manager | The manager sees more only where the role tree says so | | Updates | Object and field permissions | The agent cannot edit what the user cannot edit | | Handoff | The case the queue user opens | The comment carries no forbidden field | | Departure | The integration user's owner leaves | The permission set is reviewed the same week | 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](/salesforce-center-of-excellence). 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. ## Questions ### Does the agent see records the user cannot open? It sees what the running user, or the named integration user, is allowed to see. Sharing rules, the role hierarchy, and field-level security are the wall. A page layout that hides a field does not hide it from the agent, a report, or an API call. If the agent can describe a record or a field that user cannot open, the access is wrong. Compare the agent with a report run as that same user, and fix the difference in the platform. An administrator used as the pilot user will make this test pass for the wrong reason. ### Is a line in the instructions enough to keep customer data private? No. Instructions ask the agent to be careful, and they do not remove rows from the query. Sharing rules and field-level security decide which rows and fields come back. A prompt that says to stay on this customer's records loses to public read, and the reply can still sound careful. Test the wall with a user who must not see the record, and confirm the platform returns nothing. Then leave the instructions alone, because they are not the control. ### What is wrong with widening access so the pilot looks complete? The wider access is what you will still be running next month. An empty answer was the control working. It told you the running user could not see that record, which is what you wanted if the record was not theirs. Opening sharing, a profile, or a permission set so a demo returns an answer makes that record available to every later question asked as that user. View All Records is the same move, and it ignores sharing on the object. Treat the empty result as a finding, and write down which user it belonged to. ### Does escalating to a human repair an access mistake? Salesforce describes escalation as a handoff when an issue is beyond the agent's scope. The person who picks up the case sees what their user can see. The handoff does not restore a sharing rule you removed, and it does not unsay a reply already sent. A transcript that pastes a forbidden field into a case comment has moved that field out of the sharing model. If the record is sensitive, it has to be unreachable before the first response. Design the queue, and the fields the case is allowed to carry, before you turn the handoff on. ### Who should own the integration user? A named person, with a permission set written for the job: objects it may read, objects it may update, and fields that stay closed. Put that name in the permission set description so the next administrator can find them. When they leave the organisation, review the permission set the same week you disable their login. View All Records is not a temporary pilot setting. An integration user with no owner collects grants from every workshop that needed the demo to finish. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).